Ad

Our DNA is written in Swift
Jump

72.009 DPI

When creating image files via CGImageDestination if found something weird. I’m setting the DPIHeight and DPIWidth fields in the meta info to 72. When outputting as PNG format there are some programs that will show the image resolution as 72.009 DPI, whereas TIFF and JPEG for example would display as 72.

Turns out that this is neither a problem of CGImageDestination, libpng nor any specific viewer app. The problem is in the PNG specification.

Consider the following output meta info I created with Pixelmator:

{
    ColorModel = RGB;
    DPIHeight = 72;
    DPIWidth = 72;
    Depth = 8;
    HasAlpha = 1;
    Orientation = 1;
    PixelHeight = 1024;
    PixelWidth = 1024;
    ProfileName = "sRGB IEC61966-2.1";
    "{Exif}" =     {
        ColorSpace = 1;
        PixelXDimension = 1024;
        PixelYDimension = 1024;
    };
    "{PNG}" =     {
        InterlaceType = 0;
        Software = "Pixelmator 2.1.4";
        XPixelsPerMeter = 2835;
        YPixelsPerMeter = 2835;
    };
    "{TIFF}" =     {
        Compression = 5;
        DateTime = "2013:02:01 08:02:89";
        Orientation = 1;
        ResolutionUnit = 1;
        Software = "Pixelmator 2.1.4";
        XResolution = 72;
        YResolution = 72;
    };
}

In addition to the DPIHeight and DPIWidth at the meta dictionary root, there are also two extra resolution fields in the {PNG} tag: XPixelsPerMeter, YPixelsPerMeter.

And indeed this is what causes the problems: In the PNG spec those PixelsPerMeter fields are defined as 4 bytes, unsigned integer. And having this value as an integer means that you cannot evenly represent integer DPI values.

72 DPI = 2834.5656 PPM
2835 PPM = 72.009 DPI
2834 PPM = 71.9836

If you google for “72.009 DPI” you find lots of people discussing this who think their Macs are broken because Photoshop claims that their screenshots have this odd DPI value.

These complaints where dealt with by Adobe, Pixelmator and Apple differently. Tool vendors simply round the DPI value to an integer value in the latest versions of their apps. Apple removed the DPI meta info from PNG screenshots in the latest version of OS X.

This is the meta info attached if you create a PNG screenshot on my iMac running OS X 10.8.2:

{
    ColorModel = RGB;
    Depth = 8;
    PixelHeight = 300;
    PixelWidth = 319;
    ProfileName = iMac;
    "{Exif}" =     {
        PixelXDimension = 319;
        PixelYDimension = 300;
    };
    "{PNG}" =     {
        InterlaceType = 0;
    };
}

All in all it is really a non-issue since the resolution value is only really relevant for print where you need to be able to specify how large in physical size an image is supposed to be printed. Also the 72 DPI value is from olden times, my 27″ iMac has 108.79 pixels per inch, according to this online DPI Calculator. This is probably the reason why Apple opted to remove the DPI info from screenshots, because hard-coding 72 DPI in there would in no way match the actual screen resolution. They would have to add a different value based on the machine this code is running on.

Conclusion

As I see it the PNG specification is to blame. Who in his right mind uses pixels per METER as a resolution measurement? If they had used a smaller metric unit, like Millimeter or Centimeter then we wouldn’t have to deal with this rounding problem.

If you ever encounter this rounding problem yourself you have these options:

  • Ignore it and mumble inaudibly “PNG Spec”, and “Pixels Per METER”.
  • If you are a tool vendor then round the DPI to an integer as well to get rid of the annoying fraction
  • Omit the DPI value from your generated images if you don’t need the output scale value for print

There is nothing wrong with your images.


Categories: Design

1 Comment »

  1. > If they had used a smaller metric unit, like Millimeter or Centimeter then we wouldn’t have to deal with this rounding problem.

    Uh…. If they had used pixels per millimeter or centimeter the problem would have been much worse 🙂