Re: BGRA, ARGB, etc. suggestion

On Sun, Dec 20, 2015 at 3:17 PM, Glenn Randers-Pehrson <[email protected]>
wrote:

> Supporting 32-bit samples would not be trivial because the spec and
> library would have to be redone to allow values greater than (2^31 - 1) so
> I don't expect that proposal would be accepted.
>

Well, in the same vein as your ABGR comment, libpng does support 32-bit
samples (i.e. bit depth == 32).  The support is there because many
applications use floating point when processing sample values and, in
portable implementations, that means a minimum of 32 bits in practice.

PNG itself doesn't because there is no point; 16-bit samples are able to
represent the full range of intensity of color information with no data
loss using gamma encoding and the result is actually 100% conformant to the
current specification, with the caveat that 1.0 (i.e. 65535) is supernova
bright.

The point is that the *file* encoding need not match the *processing*
encoding or, for that matter, the *display* encoding.  Modern machines are
fast enough to inter-convert from file to display, indeed, on a modern
system expect most of the display time of a new image is going to go in
scaling it to the display resolution; these days images always have to be
scaled.  PNG can represent anything losslessly but the representation can
be very inefficient.  (By which I mean it can double the number of bits,
pre-compression, that the original data required.)

As for 32-bit grayscale, I guess this is coming from some scientific app
that is trying to store non-perceptual information.  It's true the standard
doesn't say, even by implication, that this is not supported and that it
does only give 16 bits to do it in ;-)  The relevant quote is:

"Greyscale samples represent luminance if the transfer curve is indicated
(by gAMA <http://www.libpng.org/pub/png/spec/iso/index-object.html#11gAMA>,
sRGB <http://www.libpng.org/pub/png/spec/iso/index-object.html#11sRGB>, or
iCCP <http://www.libpng.org/pub/png/spec/iso/index-object.html#11iCCP>)
or *device-dependent
greyscale* if not. RGB samples represent calibrated *colour *information if
the colour space is indicated (by gAMA
<http://www.libpng.org/pub/png/spec/iso/index-object.html#11gAMA> and cHRM
<http://www.libpng.org/pub/png/spec/iso/index-object.html#11cHRM>, or sRGB
<http://www.libpng.org/pub/png/spec/iso/index-object.html#11sRGB>, or iCCP
<http://www.libpng.org/pub/png/spec/iso/index-object.html#11iCCP>) or
uncalibrated device-dependent *colour *if not."

I added the *bold*.  That phrase (*device-dependent greyscale*) is totally
devoid of meaning, so, yes, it might mean the output of a scientific
instrument and, therefore, it might conceivably have more than 16 bits of
information per sample.  However this interpretation is not permitted if
gAMA is present, which means that the image cannot be displayed (there is
no mapping to a display device) and so, what's the point?

The correct approach is to store the visualization in the PNG IDAT data and
add an app-specific chunk to store the original, unvisualized, data.

John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

------------------------------------------------------------------------------

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc