My colleague, Rasmus, has mentioned this back in August that we needed both all of the pixels, and the dpi setting of the image to be preserved (screenshots on Mac can be set to JPG/PNG/PDF).   They go hand-in-hand.  You're converting the NSImage to get at all of the pixels, but also need to preserve the original dpi.

The original screenshot actually has all of the data correct.  It's Chrome's rewriting of these images that then go out to a PNG that skips the PHYS block that details the DPI.  On JPG, it's JIFF block that has the dpi, but Figma doesn't respond to that yet.

You might be able to make OSX NSImage rewrite the dpi.  Here's a link:
http://stackoverflow.com/questions/8048597/how-to-change-image-resolution-in-objective-c

I'm assuming Firefox doesn't filter, since it sends down the correct original image data unfiltered.

You can use Preview to see the PHYS block on the screenshots.  New from clipboard, and then the inspector shows the dpi as 144 x 144 (2x retina).

In my post that I linked above, I wrote:
"""
I think that the root of the problem lies with the clipboard API, which turns an image in the clipboard into a Blob, which loses metadata such as the desired display size of the image (e.g. is it retina). For example, in Firefox, there's no way to distinguish between a clipboard with a 200x200 non-retina image, and a 100x100 retina image.
"""

Without doing more research, I can't tell how Firefox is correctly interfacing with figma.com. Are you still using the clipboard API?

Yes, all using the clipboard api.   In Firefox, the pasted image is the original PNG (default screenshot on OSX) when we receive it, and it still has the PHYS block set.  From that, we extract the dpi.  From Chrome, we get a PNG out but it's PHYS block is likely set to 72dpi.  It's from re-encoding the source back to a PNG incorrectly.  

If you receive a PNG, then scrub it, but convert it back to a PNG with PHYS block and then pass that on.  If you receive a JPG, then scrub it, and write it out to JPG with JIFF block.  My assumption was that Firefox is not converting anything, and passing on the original data.

I think it's probably fine not to scrub any data when passing it in from the OS, if it's natively supported. AFAIK, Windows doesn't really have any "native" clipboard formats for PNG, JPG etc, as there's no well-known registered format for it. However, OS X and Linux should be able to support those types of formats, and it would make pasting images much more efficient.

It should be pretty straightforward to implement. garykac@, do you think it's worth waiting for navigator.clipboard to implement and expose this to the web?

So I added dpi support to a pre-release of Figma to test out Chrome importing and passing through the PHYS block and it seems to for dropped in images.  It's just the pasted screenshots that are filtered.  Attached is a 2x = 144 dpi circle as a PNG.

Deleted: Ellipse.png 4.0 KB

	Ellipse.png 4.0 KB View Download

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot