Possible review? libgd libultrahdr support (and then php's)

[pierrejoye]

I added a PR to add libultrahdr support for libgd:

libgd/libgd#898

It seems to work well. It supports the current APIs and is fully decoupled from the gd's other JPEG codecs. I require 1.4.0 for the time being.

I wonder if it would be possible to review if I did not do something obviously wrong or similar.

It will take some time to reach php too (next 8.x maybe), but I plan to release gd 2.4.0 soon with HDR support.

And I take this opportunity to thank the team behind this library! very good understandable APIs, once the concept of gain map etc is behind me :)

[pierrejoye]

For those interested, or needs to build it on windows, I added it to our CI:
https://github.com/libgd/libgd/blob/feature/ultrahdr/.github/workflows/ci_windows.yml

mac and ubuntu already in place as well.

As windows build, surprise ;-), makefiles are incomplete, manual copy over required. Maybe it could be pushed to vcpkg at some point (libjpeg-turbo is there already).

[kmilos]

As windows build, surprise ;-), makefiles are incomplete, manual copy over required. Maybe it could be pushed to vcpkg at some point (libjpeg-turbo is there already).

FWIW, it's been available in MSYS2 for a while (no manual copying needed)...

[pierrejoye]

@nico thanks, that's pretty clear. Not the same build path at all. nor the same needed for prod builds on windows:)

[gregbenz]

@pierrejoye Thank you for the updates and effort here. I am now able to build on MacOS.

When I try the following, the output shows significant changes in all the gain map metadata (different values, changes from single channel map to 3-channel). The headroom jumps from 4 stops to a generic 5.6224, resulting in the image being darker on HDR displays and is the most significant concern, it causes a significant change. The change in the gain map range from min to max from a net 6.8 to 19 stops causes significant quantization error (visible as banding in the colored gradients). There is more artifact than I would expect (for a result which is larger than the cleaner output from wasm-vips).

IN="ISO JPG - P3 - transcoding test - Greg Benz.jpg"
OUT="output-50-uhdr.jpg"

read W H <<< "$(sips -g pixelWidth -g pixelHeight "$IN" 2>/dev/null | awk '/pixelWidth/{w=$2} /pixelHeight/{h=$2} END{print int(w/2), int(h/2)}')"

./uhdr \
  "$IN" "$OUT" \
  --resize "${W}x${H}" \
  --quality 90

The single pixel test near bottom left also shows solid red via GD in the base image instead of the expected yellow/purple blend.

When I run the same image through wasm-vips, the metadata is not changed (same image is built into https://gregbenzphotography.com/test/wasm-vips-hdr-demo/) and base image is a good match.

It does produce a valid gain map at 50% size, but the quality is not consistent with what libultra can achieve. The most significant concern is the change in map metadata, it should be unchanged (unless there is an explicit request to make a change such as reducing map from 3 channels to 1 - though I think it's probably best / simplest to avoid such changes as they are of modest benefit in most cases).

Please let me know if anything else would be helpful to review.

[gregbenz]

One more thought, if GD cannot keep a single channel map with its existing encoding (I'm assuming GD is processing the image base on what I see but didn't dive deeply into the code), it would be fine to create a 3-channel map with the same grey values. In this case, the 3-channel metadata would show identical values for each channel. It should compress well and would be visually the same as a true 1-channel map. But otherwise, the metadata should be an exact or near exact match for all metadata values to preserve the fidelity to the source.

[pierrejoye]

Thanks for testing:) the only time changes happen is if caller modify the image in gd itself. GD uses 31bits argb, so there is a de facto lost here. gd cannot (and no library does) create new map for hdr. current implementation, if only using libuhdr features and caller does not go through gd at all, then GD does nothing at all about map or sdr. Everything is done in uhdr. if something changed or is wrong, I would need an input and output references to test, if possible only using the libultrahdr cli app, as I can't valid what a wasm does or what vips does. possible? that would help to debug, maybe I am calling hdr wrong, but it is 1 to 1 arguments mapping, no change or similar to the options. Pierre

[pierrejoye]

update, I think I made a possible mistake with the quality. It is applied on re-encoding, that could cause what you describe. I am adding no-op test to ensure in and out are exactly the same, minus possible FP rounding related deltas for some values.

update 2: I will still add the quality fix (no quality change on re-encoding. but as of now, with an epsilon of 1e-6, I get the same values than using ultrahdr_app on no-op.

The tests result on mac can be seen here https://github.com/libgd/libgd/actions/runs/26703381274/job/78700170397

The added no-op test being https://github.com/libgd/libgd/blob/master/tests/uhdr/uhdr_cli_parity_quality_noop.c