Strange issue with PNG files

  • I am working with a PNG file and noticed something odd with it that I am hoping someone can explain since I am not familiar enough with the PNG file format at this time.

    Basically, when I use:

    fileImage = [[[NSImage alloc] initWithContentsOfFile:filePath] autorelease];
    NSSize imageSize = [fileImage size];
    NSLog( @"Have Image of size - %@", NSStringFromSize( imageSize ) );

    to read the image and then take a look at the result of [fileImage size], I am told the image is {5.76086, 5}.

    Now, the odd thing is that I know the image is 16x14. I can confirm this by opening the image with GraphicConverter.

    However, when I open the image with GraphicConverter, it opens the image up at ~36% of it's normal size. Now, ~36% of the normal size is {5.76086, 5} - at least I am assuming this isn't a coincidence.

    So, the question is, does anyone know what is going on here? How can I get NSImage to read the image in at the normal size instead of the smaller one?
  • It's apparently not a 72ppi picture. Even though the image is 16x14 pixels,
    at ~200ppi something 14 pixels high is only 5 points high.

    You are getting the full image, and I bet if you took the NSImageRep and
    asked *it* for -pixelsHigh or -pixelsWide you'd get the 14 and 16.

    If you want to draw it pixel for pixel despite the high ppi, use
    -pixelsHigh/-pixelsWide, create an NSSize of that size, and draw it
    "scaled".

    Avi

    On Thu, Mar 4, 2010 at 1:58 PM, Eric Gorr <mailist...> wrote:

    > I am working with a PNG file and noticed something odd with it that I am
    > hoping someone can explain since I am not familiar enough with the PNG file
    > format at this time.
    >
    > Basically, when I use:
    >
    > fileImage = [[[NSImage alloc] initWithContentsOfFile:filePath]
    > autorelease];
    > NSSize imageSize = [fileImage size];
    > NSLog( @"Have Image of size - %@", NSStringFromSize( imageSize ) );
    >
    > to read the image and then take a look at the result of [fileImage size], I
    > am told the image is {5.76086, 5}.
    >
    > Now, the odd thing is that I know the image is 16x14. I can confirm this by
    > opening the image with GraphicConverter.
    >
    > However, when I open the image with GraphicConverter, it opens the image up
    > at ~36% of it's normal size. Now, ~36% of the normal size is {5.76086, 5} -
    > at least I am assuming this isn't a coincidence.
    >
    > So, the question is, does anyone know what is going on here? How can I get
    > NSImage to read the image in at the normal size instead of the smaller one?
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
  • On Mar 4, 2010, at 2:06 PM, Avi Drissman wrote:

    > It's apparently not a 72ppi picture. Even though the image is 16x14 pixels, at ~200ppi something 14 pixels high is only 5 points high.
    >
    > You are getting the full image, and I bet if you took the NSImageRep and asked it for -pixelsHigh or -pixelsWide you'd get the 14 and 16.

    Yes, that is true.

    > If you want to draw it pixel for pixel despite the high ppi, use -pixelsHigh/-pixelsWide, create an NSSize of that size, and draw it "scaled".

    So, the only/recommended way to determine when an image is in this state is to compare what [image size] returns vs. pixelsHeight & pixelsWide?
  • If by "state" you mean at ppi != 72, yes.

    Images come in all resolutions (assuming they have resolution at all (e.g.
    pdf)). You can draw it at its natural size, at a size that makes it come out
    pixel-for-pixel (build the NSSize, etc.) or anything in-between.

    BTW, don't forget that an NSImage can have multiple representations, each
    with a different pixel size (load an ICNS to see that). In that case, your
    concept of "this state" isn't even meaningful.

    Images are much more than a bag of pixels.

    Avi

    On Thu, Mar 4, 2010 at 2:23 PM, Eric Gorr <mailist...> wrote:

    > On Mar 4, 2010, at 2:06 PM, Avi Drissman wrote:
    >
    >> It's apparently not a 72ppi picture. Even though the image is 16x14
    > pixels, at ~200ppi something 14 pixels high is only 5 points high.
    >>
    >> You are getting the full image, and I bet if you took the NSImageRep and
    > asked it for -pixelsHigh or -pixelsWide you'd get the 14 and 16.
    >
    > Yes, that is true.
    >
    >> If you want to draw it pixel for pixel despite the high ppi, use
    > -pixelsHigh/-pixelsWide, create an NSSize of that size, and draw it
    > "scaled".
    >
    > So, the only/recommended way to determine when an image is in this state is
    > to compare what [image size] returns vs. pixelsHeight & pixelsWide?
    >
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
  • Am 04.03.2010 um 20:23 schrieb Eric Gorr:

    >> If you want to draw it pixel for pixel despite the high ppi, use -
    >> pixelsHigh/-pixelsWide, create an NSSize of that size, and draw it
    >> "scaled".
    >
    > So, the only/recommended way to determine when an image is in this
    > state is to compare what [image size] returns vs. pixelsHeight &
    > pixelsWide?

    IIRC, the recommended way is to not care about the number of pixels
    of an image, but to draw it by size. Resolution independent display
    technologies aren't that far away. With these, image pixels won't
    match display pixels even when drawn at 72 dpi (1 pixel = 1 image
    size unit).

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • Yea, because many of the images that flow through are pipeline are
    much higher DPI (storyboards tend to be 200DPI, for example), we have
    always had to deal with this. comparing size and pixels is a good
    thing to do...

    On Mar 5, 2010, at 12:53 PM, Markus Hitter wrote:

    >
    > Am 04.03.2010 um 20:23 schrieb Eric Gorr:
    >
    >>> If you want to draw it pixel for pixel despite the high ppi, use -
    >>> pixelsHigh/-pixelsWide, create an NSSize of that size, and draw it
    >>> "scaled".
    >>
    >> So, the only/recommended way to determine when an image is in this
    >> state is to compare what [image size] returns vs. pixelsHeight &
    >> pixelsWide?
    >
    > IIRC, the recommended way is to not care about the number of pixels
    > of an image, but to draw it by size. Resolution independent display
    > technologies aren't that far away. With these, image pixels won't
    > match display pixels even when drawn at 72 dpi (1 pixel = 1 image
    > size unit).
    >
    >
    > Markus
    >
    > - - - - - - - - - - - - - - - - - - -
    > Dipl. Ing. Markus Hitter
    > http://www.jump-ing.de/
    >
    >
    >
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • At 12:00 -0800 06/03/10, <macosx-dev-request...> wrote:
    > Date: Fri, 5 Mar 2010 21:53:33 +0100
    > From: Markus Hitter <mah...>
    > To: Eric Gorr <mailist...>
    > Message-ID: <A9A49D60-FA0A-4431-A6D6-5A0BAC363D3F...>
    >
    > Am 04.03.2010 um 20:23 schrieb Eric Gorr:
    >
    >>> If you want to draw it pixel for pixel despite the high ppi, use -
    >>> pixelsHigh/-pixelsWide, create an NSSize of that size, and draw it
    >>> "scaled".
    >>
    >> So, the only/recommended way to determine when an image is in this
    >> state is to compare what [image size] returns vs. pixelsHeight &
    >> pixelsWide?
    >
    > IIRC, the recommended way is to not care about the number of pixels
    > of an image, but to draw it by size. Resolution independent display
    > technologies aren't that far away. With these, image pixels won't
    > match display pixels even when drawn at 72 dpi (1 pixel = 1 image
    > size unit).

    If you're "drawing by size", be aware of a longstanding issue with the PNG format, in that resolution in the 'pHYs' chunk can only be specified in meters, meaning there's no exact equivalent for 72 dpi.
    http://www.w3.org/TR/PNG/#11pHYs

    I have rdar://5532687 open since 10/10/2007 (!) about this. Basically, if the 'pHYs' chunk in a PNG specifies meters, the nearest equivalent is 72.009. This can distort larger PNGs if you try to draw them as 72 dpi, or at some exact ratio. The bug relates to Preview 4.0(467) and up generating PNG files at 72.009 dpi - older versions set the 'pHYs' chunk to "unknown unit", which defaults the image to exact 72 dpi when read by Mac OS X.

    Easily verified: open a .icns file in Preview, save as .png, open the file in (say) Photoshop, you'll see the dpi set to 72.009.

    I've just tested this again in 10.6.2 (Preview 5.0.1). This now seems to round 72.009 down to 72, so that all appears to be well, but it's not! Preview 4.x showed 72.01.

    Anyway, be sure to double-check your PNG files. I just filed this on OpenRadar: http://openradar.appspot.com/radar?id9405
    --
    Rainer Brockerhoff  <rainer...>
    Belo Horizonte, Brazil
    "In the affairs of others even fools are wise
    In their own business even sages err."
    Weblog: http://www.brockerhoff.net/bb/viewtopic.php
previous month march 2010 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today