[bug #34740] gnustep has problems with PNGs that have a sRGB colorspace

[Eric Wasylishen]

Follow-up Comment #6, bug #34740 (project gnustep):

hey, i have a few comments which hopefully help:

regarding backends, you should probably use cairo as it is the best
supported.
fonts should still display using xlib, though.

1.) loading PNGs with NSImage results in images that are 1 pixel smaller in
both dimensions in some cases.

this is a nasty thing which is sort of my fault, and comes from the resolution
independence of NSImage. first, the return value of -[NSImage size] is in
points (1 point = 1/72 inch), not pixels. it is calculated from the pixel size
of the png using the pHYs chunk, which specifies a relationship between the
pixel size and physical units (centimetres). the source of the -[NSImage size]
being smaller than the real pixel size comes from the fact that the PNG pHYs
chunk can't express 72 DPI exactly, because it stores resolution as 'pixels
per meter' in an unsigned integer.

so there are a few alternatives:
-we could put in a hack in the png loading code which check for a resolution
close to 72dpi and rounds it to exactly 72dpi (thinking about it now, we
should probably do this)
- you could remove the dpi metadata from the png's, and GNUstep will assume
they are 72dpi (1 pixel = 1 point). you can remove it with imagemagick, and
probably gimp.
-the simple answer is your code should probably use -[NSBitmapImageRep
pixelsWide] and -pixelsHigh.

2) not sure.. see if cairo fixes it.

a final few comments, calling -[bitmap initWithFocusedViewRect:] and then
accessing the pixel data with -bitmapData is a dangerous idea unless you are
prepared to check the bitmap format carefully and be ready to bail out if it
isn't what you expect.

oh, calculating rowsize yourself is wrong becasue the framework is allowed to
pad rows so they are longer than necessary, to make them a multiple of the
word size in length (presumably this makes accessing the memory faster). you
should use -[bitmapRep bytesPerRow].


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34740>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/