Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output density inconsistent #2455

Closed
juliangruber opened this issue Nov 24, 2020 · 5 comments
Closed

Output density inconsistent #2455

juliangruber opened this issue Nov 24, 2020 · 5 comments
Labels

Comments

@juliangruber
Copy link

I'm debugging an issue where png output density isn't 72, and noticed that the expected densities are all over the place:

$ find test/fixtures/expected/*.{png,jpg} | xargs identify -format "%x x %y\n" | sort | uniq
10 x 10
118.10999999999999943 x 118.10999999999999943
25.399999999999998579 x 25.399999999999998579
28.339999999999999858 x 28.339999999999999858
28.350000000000001421 x 28.350000000000001421
3628.3499999999999091 x 3628.3499999999999091
37.799999999999997158 x 37.799999999999997158
472.43999999999999773 x 472.43999999999999773
5.6699999999999999289 x 5.6699999999999999289
72 x 72

Maybe these files weren't generated with sharp, so I did a simple check:

const sharp = require('.')

sharp(`${__dirname}/test/fixtures/expected/16-bit-grey-alpha-identity.png`)
  .toFile(`${__dirname}/out.png`)
$ node example.js && identify -format "%x x %y\n" out.png 
28.350000000000001421 x 28.350000000000001421

If you change the output format to jpg, it's basically 72x72:

$ node example.js && identify -format "%x x %y\n" out.jpg 
72.009000000000000341 x 72.009000000000000341

I wonder where these numbers are coming from. This is on git master.

@juliangruber
Copy link
Author

For context, I discovered this converting files to PDFs, where pixel density is an important value to read

@lovell
Copy link
Owner

lovell commented Nov 24, 2020

The test files are from all over the place so it doesn't surprise me that the density metadata is too :)

PNG images use the rather unusual pixels per metre as their integer units for this, hence the rounding errors when converting to DPI - see https://www.cocoanetics.com/2013/02/72-009-dpi/

Please see #967 for a future possible enhancement to allow setting the xres and yres.

@juliangruber
Copy link
Author

juliangruber commented Nov 25, 2020

Thank you for the quick answer!

Why is it though that png outputs as 28.35 DPI and JPG as 72.009 DPI? Shouldn't both be 72 DPI (or as close as JPG is)? This could also be an imagemagick issue of course.

If all file formats reliably output 72 DPI (or as close as JPG is) that would solve this for me for now. I saw the linked issue as well, and would be happy to contribute once we need to output custom DPI :)

@lovell
Copy link
Owner

lovell commented Apr 25, 2022

Been a while but I did a quick check and the ImageMagick identity tool outputs PNG density as pixels/cm, so when it says 28.35 that's equivalent to 28.35 * 2.54 = 72.009 DPI, which I think is what you were expecting. Is this still a problem?

@juliangruber
Copy link
Author

perfect, no that works. Thank you for explaining!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants