Tobias Wood wrote: >> Tobias, >> >> I would like to apply your patch, but the test in >> examples/tests/pngsuite fails. If you can submit a new patch where this >> test passes, and, even better, if a small example 12-bit PNG of yours is >> added to the test, I will apply it. >> >> Apart from that, I would echo Eric's thanks for the patch and >> explanation. >> >> -Andrew > > Hi Andrew and Eric, > Thanks for the responses. I was unaware of the png test suite. I have > attached a new diff that passes this test correctly. It originally > failed because I was not handling greyscale images with an alpha > channel, but it also brought to light several other issues with my code > that I have fixed. I have changed the structure of the code > significantly - the if/else struct has gone and a single loop returns > the different image matrices. Although this is more concise, it no > longer informs the user if it hits an unsupported image type. > > Unfortunately I do not have a small test image available, all of ours > are a minimum of 512x620. However the pngsuite page, > http://libpng.org/pub/png/pngsuite.html, does have a set of suitable > images labelled cs*n*.png. These have thrown up an interesting issue - > to what maximum value should n-bit images be scaled when n is between 8 > and 16? The png spec and test images suggest it should be (2^n - 1). > This means that higher bit depths give higher precision over the same > intensity range and the same maximum value. However for my particular > camera and software this would be wrong, as the CCD has a fixed 12-bit > dynamic range and the lower png bit depths are only used to save file > space. Hence at the moment I have set my software to scale to (2^16 - 1) > for 8 < n < 16, but it follows the png spec for n < 8, so there are two > contradictory behaviours and I am unsure which is the best approach. > Personally I would prefer matplotlib to return raw integer values, not > floats scaled between 0 and 1 and then I can apply the scaling myself, > but I am aware that this is not particularly user friendly for anyone > else. imshow() seems to handle integer values fine and correctly scales > for display, provided that no alpha channel is present. > > Should I post another message to the developer list about this to see > what people think? I'd very much like to discuss this with someone who > has a lot more experience of pngs than me.
Tobias, I went ahead and applied your patch to the svn trunk and the 0.98.5 maintenance branch -- the aspect of having grayscale images come in as 2d arrays brings the functionality inline with the docstring to imread(), so it qualifies as a bug fix. The rest is a nice feature addition (the ability to read high dynamic range PNGs) that I think is unlikely to break anything. As for your questions, I think they can be addressed later. (I hope you maintain your interest in this subject.) In particular, it would be good to get Michael Droetboom's responses on this -- he's the resident PNG expert. In terms of the 8 < n < 16 bit PNG issue, if they are to be stored as integers, they will have to be stored in 16 bits, thus there are two reasonable ways to do it -- left shifted and right shifted. There are arguments for both. Thus, my opinion is that adding keyword arguments to imread() that would modify the current behavior appropriately would be the best solution. In other words, something like return_as_integer=False, integer_shift='left' would be the defaults. Next time you submit patches, I do think it would be best to submit to the mpl-dev email list. Anyhow, thanks for the patch! -Andrew ------------------------------------------------------------------------------ _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
