jpegrutils: set use_base_cg for Apple gain maps

[pateltejas]

The Apple decode path in getMetadataFromXMP() (added in #385) returns early without setting use_base_cg, so it stays false.

Decoding is unaffected. But re-encoding the decoded base image, gain map, and metadata through uhdr_enc_set_compressed_image + uhdr_enc_set_gainmap_image fails in JpegR::encodeJPEGR:

For gainmap application space to be alternate image space, gainmap image is expected
to contain alternate image color space in the form of ICC. The ICC marker in gainmap
jpeg is missing.

use_base_cg == false tells the encoder the gain map is applied in an alternate color space and must carry its own ICC profile. Apple gain-map images don't have one. Apple applies the gain map in the base image's color space, so use_base_cg should be true, which is what the ISO and Adobe XMP paths already set.

In practice this shows up when an app resizes an Apple HDR JPEG while preserving its gain map (for example ImageMagick's UHDR: coder): the transcode fails instead of producing a smaller Ultra HDR JPEG.

Decoded output doesn't change. Apple gain-map images carry no ICC, so applyGainMap resolves the gain map's gamut to the base's, and both gamut-conversion paths are identity whichever way use_base_cg is set. I confirmed that decoding both Apple fixtures to linear HDR gives byte-identical output with and without this change. Only the encode check is affected.

Test

JpegRTest.decodeApple now also asserts use_base_cg for both Apple fixtures (apple_gainmap_old.jpg, apple_gainmap_new.jpg). It fails on both without this change and passes with it. The full ultrahdr_unit_test suite passes (1093 tests).

Related discussion: #365.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gregbenz]

Thanks for fixing this, looks like a good PR. Did you just close it due to the CLA requirement? Or did you have some other concern?

Would it be worth adding a round-trip test that re-encodes the base image and gain map with the decoded metadata, then checks that the result decodes successfully? That would cover the transcode failure directly. Just a suggestion, not something I’d hold up the fix over.

[pateltejas]

@gregbenz Thanks. Had to use my company account to open PR as that account is already covered by CLA. #484 is the correct pr