Re: backwards compatible half-float PNG test app source+examples

Here's how the half float pixel values are losslessly recovered from
16-bit/component HDR PNG images in the "hdrpng" example code. This is the
entire decoding procedure.

This code extracts the low and high bytes from the stored PNG's 16-bpp
pixels, remaps the high byte through the lookup table read from the "hdRa"
ancillary chunk (below), shifts right the 16-bit value from [0,15] bits
(this is typically 0, but for darker images it may be a small # of bits),
and then rotates the sign bit back into the MSB from the LSB of the 16-bit
value. This standard half float value can then be processed in an HDR
pipeline.

The lossless encoder that takes half-floats and outputs 16-bit PNG values
is more complex, but not by much. It has to determine the shift amount by
examining all the half floats in the image and a high byte histogram, and
then compute a 256 entry lookup table using some sort of tone mapping
algorithm. The table must be computed in a way that results in no loss.
[image: image.png]

[image: image.png]

On Fri, Nov 10, 2023 at 4:48 AM Richard Geldreich <rich@binomial.info>
wrote:

> If you want to see these example HDR .PNG's, unpacked to HDR .EXR files,
> using an in-browser HDR viewer, I've unpacked them (using the example
> hdrpng tool) to github here:
> https://github.com/richgel999/png16/tree/main/bin/unpacked
>
> The EXR viewer app (it's pretty good - I use it for testing on SDR
> monitors):
> https://viewer.openhdr.org/
>
>
> On Fri, Nov 10, 2023 at 4:34 AM Richard Geldreich <rich@binomial.info>
> wrote:
>
>> I've found a lossless and trivally invertible transform that takes
>> half-float HDR values (typically read from .HDR or .EXR images) and packs
>> them to 16-bit unsigned pixels that are completely compatible with existing
>> non-HDR aware PNG software. It uses a simple invertible and lossless global
>> tone mapping operator that operates directly on the half-float values. Old
>> readers view and see these PNG's as 16-bit PNG's (so usually 48bpp per
>> pixel for RGB).
>>
>> The high bytes are tone mapped so the 16bpp images appear passable to
>> existing readers. New readers can parse a small ~257 byte ancillary chunk
>> which contains a byte remapping table used to remap the high bytes of the
>> 16-bit components in the PNG image back to half-floats. (It's a little bit
>> more complex than this to deal with signed floats and very low values, but
>> that's the gist of it.) It's lossless for all valid half-float values
>> (normals, denormals, signed). I filter out any NaN's/Inf"s in this test.
>>
>> You can see a bunch of example 48-bpp PNG's packed from .EXR images in
>> this way here:
>> https://github.com/richgel999/png16/tree/main/bin
>>
>> The C++ source to the example "hdrpng" tool is here. The example app
>> excluding image reading/writing is only ~450 lines of code. (It currently
>> compiles with VS 2022 under Windows - I'll add a Linux cmake file next.)
>> https://github.com/richgel999/png16/
>>
>> It uses the popular open source lodepng library, unmodified, to write and
>> read 16-bit PNG files and manipulate the ancillary "hdRa" chunk.
>> hdrpng supports packing and tone mapping .EXR images to .PNG, unpacking HDR
>> .PNG to .EXR, and an .EXR file comparison mode to verify that the half
>> float values can be 100% recovered from the PNG file with no loss. The tone
>> mapping in this example is automatic.
>>
>> I've tested the resulting 48bpp PNG files with pngcheck, Windows
>> Explorer, Chrome, Paint Shop Pro, several tools, and the Windows Photo
>> viewer app. So far, so good - they all look fine.
>>
>> Here are a couple example 48bpp PNG files. (Not sure what gmail will do
>> to them, but this is what they look like.) These are how existing PNG
>> readers view these HDR files. The half-float data is 100% preserved in
>> these .PNG files, so HDR capable viewers are able to retrieve the original
>> half-float pixels and do their own tone mapping or HDR processing.
>>
>> [image: Kapaa.png]
>> [image: memorial.png]
>>
>> These PNG's validate successfully using pngcheck, because they are
>> completely standard PNG files that any reader can load:
>>
>> [image: image.png]
>>
>