Re: More than 16-bit per color channel (bis repetita)

On Wed, Jan 20, 2016 at 9:38 AM, Jehan Pagès <[email protected]>
wrote:

> >From the answers, I got in the last thread, I guess you consider PNG
> mostly as a finale output format, while obviously we want to use its
> feature for "work" data, where high bit depth makes more sense.
> Couldn't PNG happily be used for all use cases? :-)
>
>
Yes, it can; there's no problem doing so with the current 16 bit format.  I
provided a more extensive answer at the end of December last year and the
general approach is documented in the source of the development version
(1.7) starting at (currently) line 1792.

The executive summary is that you encode the PNG data with a gamma of 36.
This gives you .15% precision across a dynamic range of 1:10^14; D14 (a
genuine D14, not the hokum digital camera manufacturers quote) or about 93
stops if I got my math right.

The 36 gamma isn't really required because 0.15% accuracy isn't required;
the accepted figure is 1% but last time I looked for evidence of why this
is the correct number the highest precision I could come up with was 1/60
(in a scientific paper with a real experiment, not Poynton's observations
;-)  Still the dynamic range of 1:10^14 definitely is required to be future
proof

If you do this you need to use your own transform on the original linear
floating point data to the 16 bit form; the code within libpng can't do
that transform with the required accuracy simply because it doesn't support
float as a memory format!  It's always been tempting to add float,
particularly given that it is a simple and obvious add to the simplified
API, but as yet no one has said "I want float" with enough force and
justification.  (Some scientific users have requested it and at least one
app developer has implemented it using the read/write callbacks.)

BTW 32 bit processing doesn't cut it; the dynamic range of 32-bit integer
at 1% precision is 7.6D; about 50 stops.  At best at 1/60 precision it is
7.8D/52 stops.  Ok, that's probably enough for today's image data but it is
not enough for all data (that's the 14D figure.)  This is why some people
use 64-bit integer; it gives over 17D at 1% and 16D at 0.15%, but this is
overkill; 53 bits is enough.

In fact a 32-bit encoding is adequate for RGB+alpha (strictly pixel
coverage alpha); I posted the rationale for this many years ago now and
other people have formats that are slightly less efficient and use 9-bit
mantissa floating point with an 8-bit exponent, but that's D128; ridiculous
overkill!  CPUs support 16-bit float (no shared exponent) because of the
application in image and sound processing, and this support has also been
around for years.

John Bowler

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

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