Saved screenshot in Clipboard History are giant TIFFs, not PNGs as they should be

[gandalfsaxe]

If I take a screenshot to the clipboard (e.g. using ⇧⌘4, then taking a screenshot to the clipboard by holding control), then:

1. Paste it normally —> PNG of reasonable file size.

2. Paste it via Alfred's Clipboard History —> TIFF of giant file size.

 

Why can't it just be the PNG as when you paste it directly?

 

It's easy to reproduce by pasting via the two methods into a note in Apple Notes and then seeing the files:

[Andrew]

Alfred using tiff is for historic compatibility reasons (as this is raw image data which is given to Alfred in the clipboard).

 

I'll add an internal ticket to investigate if improvements can be made in this area

[sepulchra]

having just messaged someone a 16MB tiff of a screenshot, I would welcome a tweak here as well.

 

[Andrew]

I internally implemented prioritising png data over tiff if it is available in the clipboard, and this turns out to be unreliable across a range of apps. In my testing, which the macOS screenshot to clipboard worked flawlessly, some design apps copied bizarre and large png representations when the "tried and tested" tiff was exactly what was expected.

 

I am now investigating adding an option in the clipboard preferences to convert history images to png on pasting from Alfred's clipboard history.

[gandalfsaxe]

On 2/17/2023 at 3:01 PM, Andrew said:

I internally implemented prioritising png data over tiff if it is available in the clipboard, and this turns out to be unreliable across a range of apps. In my testing, which the macOS screenshot to clipboard worked flawlessly, some design apps copied bizarre and large png representations when the "tried and tested" tiff was exactly what was expected.

 

I am now investigating adding an option in the clipboard preferences to convert history images to png on pasting from Alfred's clipboard history.

 

Why is a conversion needed at all? The original screen capture is png if you paste it directly from the clipboard. Why can't Alfred just access and use this? And just store these in the history?

[Andrew]

As I said, some apps provide "bad" png data. Alfred is only storing one representation of data, and the tiff is the "tried and tested" real data.

 

From a technical point of view, taking the raw tiff data (at the point of copy) is also the lightest weight on the system. PNG data is usually provided as a "promise", and when that data is read from the pasteboard, the conversion to png takes place. I want to avoid this promise turning into a potentially CPU intensive action on every copy of an image where the PNG data is promised by the source app.

[gandalfsaxe]

Can you elaborate on what this means versus just pasting the screenshot directly with ⌘V not using Alfred? Can you give one or two application or contexts where it doesn't work as examples?

 

What doesn't make sense about this to me is that PNG has long been the default file format for screen captures in macOS; why is this not an issue for the standard screen capture (via ⇧⌘4+control) if it's an issue for Alfred?

 

Not saying I don't believe you btw!  Just that I don't understand why this is a problem for Alfred and not for Screenshot.app if the format of PNG is the issue and the system default is PNG and have been so for years 🤔

Edited February 20, 2023 by gandalfsaxe

[Andrew]

Before I provide a bit more info, please trust that in creating Alfred, I have an intimate understanding of macOS performance, and the focus areas to prevent load on your system. There is only so much of this I can impart casually on a forum.

 

1 hour ago, gandalfsaxe said:

Can you elaborate on what this means versus just pasting the screenshot directly with ⌘V not using Alfred?

 

In asking this, I request you re-read my paragraph on raw vs promised data.

 

Internally, the Screenshot app will be dealing with raw TIFF data. It provides TIFF data and PNG data types in the clipboard, but to prevent load on your system, the PNG type will be promised. This means that the conversion to PNG happens when an app requests to USE the data, not at the point of capturing. This deferment is a magical feature of macOS which helps with the snappy nature and lower load.

 

When you paste the screenshot into e.g. Messages, messages will prefer the PNG data (as that's better to send over a network), so it asks the pasteboard for the PNG promised data, and internally, this conversion happens at that point in time.

 

If Alfred were to ask for every PNG promise when it sees it in the clipboard (from any app), then this conversion to PNG is forced for every single image copied to the clipboard, essentially undoing the magic work Apple put in place with promised data in the first place, and ultimately leading to a higher load on your system.

 

TLDR: By making Alfred work with the raw TIFF data, this is zero load on your system. Adding the option to convert to PNG on use means you'll get the conversion happening at the point of use, just like the Screenshot app will be doing.

 

Cheers,

Andrew

[Ed B]

Just found this discussion after people have let me know they cannot view the images I am sending them.  They look fine to me but the people I send them to cannot view them as they don't have a TIFF viewer.  This has happened on iMessage and Slack.

 

+1 to the option to use PNG and not TIFF for image paste. 

 

Unfortunately as it stands today I need to be careful not to copy/paste images using alfred as it is unreliable because of the TIFF issue.   

[Ed B]

A followup to my own post, I found this really nifty workflow ClipSaver.  Allows images in the clipboard history to be easily saved as PNG so they can then be shared without worrying about recipients needing a TIFF viewer.

 

 

 

Edited February 23, 2023 by Ed B

[gandalfsaxe]

On 2/20/2023 at 4:19 PM, Andrew said:

Before I provide a bit more info, please trust that in creating Alfred, I have an intimate understanding of macOS performance, and the focus areas to prevent load on your system. There is only so much of this I can impart casually on a forum.

 

 

In asking this, I request you re-read my paragraph on raw vs promised data.

 

Internally, the Screenshot app will be dealing with raw TIFF data. It provides TIFF data and PNG data types in the clipboard, but to prevent load on your system, the PNG type will be promised. This means that the conversion to PNG happens when an app requests to USE the data, not at the point of capturing. This deferment is a magical feature of macOS which helps with the snappy nature and lower load.

 

When you paste the screenshot into e.g. Messages, messages will prefer the PNG data (as that's better to send over a network), so it asks the pasteboard for the PNG promised data, and internally, this conversion happens at that point in time.

 

If Alfred were to ask for every PNG promise when it sees it in the clipboard (from any app), then this conversion to PNG is forced for every single image copied to the clipboard, essentially undoing the magic work Apple put in place with promised data in the first place, and ultimately leading to a higher load on your system.

 

TLDR: By making Alfred work with the raw TIFF data, this is zero load on your system. Adding the option to convert to PNG on use means you'll get the conversion happening at the point of use, just like the Screenshot app will be doing.

 

Cheers,

Andrew

 

Hey Andrew, thanks for the detailed explanation. Now it makes much more sense to me.

 

I hope you can explore some PNG conversion feature for those of us who prefer *always* PNG (and then can revert to native copy-paste function in those rare instances where a PNG is not accepted by the application). With the advent of the Apple Silicon chips in Mac, I would not be worried about the extra system load by doing image conversion of screenshots. I truly appreciate your concern for system load and performance in general, as this is surely one of the reason why Alfred is so snappy in general. That's a very good attitude! In this case I'd just vastly prefer Alfred to be converting the screenshots to PNG immediately upon saving them rather than send huge image files everywhere. I've begun to use the Alfred clipboard less for images since this discovery as it literally means the difference between an image loading in 1 second or 5 seconds in Slack in many cases etc.

 

In any case, it was good to understand the technical background for this issue. 

[dserodio]

On 2/26/2023 at 7:25 PM, gandalfsaxe said:

I hope you can explore some PNG conversion feature for those of us who prefer *always* PNG (and then can revert to native copy-paste function in those rare instances where a PNG is not accepted by the application). With the advent of the Apple Silicon chips in Mac, I would not be worried about the extra system load by doing image conversion of screenshots. I truly appreciate your concern for system load and performance in general, as this is surely one of the reason why Alfred is so snappy in general. That's a very good attitude! In this case I'd just vastly prefer Alfred to be converting the screenshots to PNG immediately upon saving them rather than send huge image files everywhere. I've begun to use the Alfred clipboard less for images since this discovery as it literally means the difference between an image loading in 1 second or 5 seconds in Slack in many cases etc.

 

There are still many users (like myself) on Intel Macs, and an app like Alfred should absolutely not waste resources.

[gandalfsaxe]

21 minutes ago, dserodio said:

 

There are still many users (like myself) on Intel Macs, and an app like Alfred should absolutely not waste resources.

Sure. It should be an option, and I don't have all the information to decide which should be the default (it could be the conservative option of keeping it as TIFF). Intuitively I just think it's inconveniencing more users at this point to be sending huge TIFFs around than the relatively small energy footprint of doing TIFF to PNG conversion (even on Intel macs).

Edited March 8, 2023 by gandalfsaxe

[vitor]

On 2/26/2023 at 10:25 PM, gandalfsaxe said:

I'd just vastly prefer Alfred to be converting the screenshots to PNG immediately upon saving them rather than send huge image files everywhere.

3 hours ago, gandalfsaxe said:

Intuitively I just think it's inconveniencing more users at this point to be sending huge TIFFs around than the relatively small energy footprint of doing TIFF to PNG conversion

 

It seems you have misunderstood the solution @Andrew is investigating of doing the conversion to PNG on paste. So you wouldn’t send the TIFF, that would be used as the source of truth for the image.

 

It’s not just about energy usage: stability, accuracy, predictability, performance, and the specifics of macOS’ inner workings also matter. As explained above, a conversion is always necessary and converting images on copy is worse on every one of those metrics than converting it on paste. Either solution addresses your request, since pasting is where it matters. So if both options solve the issue and one of them is superior is most regards, that’s the one to pursue.

[gandalfsaxe]

17 minutes ago, vitor said:

 

It seems you have misunderstood the solution @Andrew is investigating of doing the conversion to PNG on paste. So you wouldn’t send the TIFF, that would be used as the source of truth for the image.

 

It’s not just about energy usage: stability, accuracy, predictability, performance, and the specifics of macOS’ inner workings also matter. As explained above, a conversion is always necessary and converting images on copy is worse on every one of those metrics than converting it on paste. Either solution addresses your request, since pasting is where it matters. So if both options solve the issue and one of them is superior is most regards, that’s the one to pursue.

 

That's good. That would be an even more attractive solution, provided that the conversion is low-latency enough.