408622 - pngsuite images with non-square pixels [pHYs] rendered incorrectly

Status: VERIFIED INVALID

(Core :: Graphics: ImageLib, defect)

Description

[Justin Dolske [:Dolske]]

Attachment: cdfn2c08.png (8x32)

The pngsuite tests have 4 images with pHYs chunks altering the size:

cdfn2c08 - physical pixel dimensions, 8x32 flat pixels
cdhn2c08 - physical pixel dimensions, 32x8 high pixels
cdsn2c08 - physical pixel dimensions, 8x8 square pixels
cdun2c08 - physical pixel dimensions, 1000 pixels per 1 meter 

The first three images are not rendered as 32x32, as the test description implies. For example, cdfn2c08 is rendered as a tall & skinny rectangle, 8x32 pixels. cdhn2c08 and cdsn2c08 are similarly rendered with the pHYs chunk apparently ignored. The 4th image, cdun2c08, is 32x32 to begin with, so it's not clear if the test is really doing anything.

pngcheck -v -v cdfn2c08.png
File: cdfn2c08.png (0 bytes)
  chunk IHDR at offset 0x0000c, length 13
    8 x 32 image, 24-bit RGB, non-interlaced
  chunk gAMA at offset 0x00025, length 4: 1.0000
  chunk sBIT at offset 0x00035, length 3: red = 4 green = 4 blue = 4
  chunk pHYs at offset 0x00044, length 9: 1x4 pixels/unit
  chunk IDAT at offset 0x00059, length 295
    zlib:  deflated, 32K window, default compression
    zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      1 4 2 2 4 0 2 2 0 2 4 2 2 2 4 2 2 2 4 4 4 4 4 4 4
      2 2 1 4 2 2 0 (32 out of 32)
  chunk IEND at offset 0x0018c, length 0
No errors detected in cdfn2c08.png (47.4% compression).

[The "1x4" pHYs confuses me a bit. Does that imply rendering to an 8x8 square? 8x128? 32x32?]

Note that these images look fine on http://www.schaik.com/pngsuite/pngsuite_cnk_png.html because the HTML explicitly sets the width/height to 32.

I'm not sure if the PNG decoder should be returning a 32x32 bitmap, or if we should be scaling it per the pHYs.

Comment 1

[Glenn Randers-Pehrson]

(In reply to comment #0)
I'm surprised that "pngcheck -v -v" doesn't display the pHYs "units" field.
Phooey, neither does "pngcrush -n -v".  #:-(
ImageMagick's "identify -verbose" says "Resolution: 1x4 pixels" which isn't too helpful or accurate.
However, here is an extract from "od -c cdfn2c08.png":
0000100  \0  \0  \0  \t   p   H   Y   s  \0  \0  \0 001  \0  \0  \0 004
0000120  \0   2   R   0 223
This decodes to 0001 pixels per x unit and 0004 pixels per y unit.
The 9th byte specifies the unit.  0 means the unit is unspecified, therefore physical pixel size is unspecified and we only know that the aspect ratio is
y/x = 4/1 ("flat pixels" or "wide pixels").  Any square rendering of the image (32x32, 8x8, or something else) would be correct.  The PNG spec does not offer any advice on which to choose and also does not require decoders to obey the ancillary pHYs chunk, so an 8x32 rendering is also correct.

Comment 2

[Glenn Randers-Pehrson]

I should have said an 8x32 rendering is also valid if not strictly "correct".

Comment 3

[Glenn Randers-Pehrson]

There is relevant 10-years-ago discussion about recommending browser handling of the pHYs chunk in the png-list archives,
ftp://ftp.simplesystems.org/pub/png-group/archives/png-list.199711
(search for "weird").  The discussion faded without coming to a conclusion, but the bottom line seems to be that browsers should do nothing with it, and content authors should use the information to set the HTML IMG width and height attributes.

Comment 4

[Justin Dolske [:Dolske]]

Sounds like we're doing the right thing, then, and the test images are just a bit misleading/confusing. That makes this INVALID, although if you were thinking of pursing this more feel free to reopen.

Comment 5

[Glenn Randers-Pehrson]

I think INVALID is OK.  Incidentally, similar arguments apply to the oFFs chunk.  Browsers should not do anything with that one either.