I've been looking into colored noise and edge artifacts introduced during RGB gain-map encoding. The attached photographs demonstrate the issue clearly. The first of each set is a crop using the current gain map calculations. The second uses an alternative approach I have been testing and shows substantially fewer artifacts.
In the first blue-box example (enlarged to 400% to make it easy to review), the mainline result has strong colored noise across the blue area and a pink artifact along the box. This is consistent with noise I have seen when encoding images with blue skies. The proposed change substantially reduces these artifacts.
In this second sky example (also enlarged to 400%), the change reduces colored artifacts around the stonework against the sky. Artifacts like this in skies adjacent to trees, buildings, or other hard edges are common with the current code.
Both mainline and modified JPEGs already use full-resolution Q80 YCbCr 4:4:4 gain maps. Their SDR bases, compression settings, and selected boost ranges are identical. These examples show a problem that can remain without chroma subsampling; they are separate from the proposal to change AVIF/HEIF maps from 4:2:0 to 4:4:4.
The comparison files retain their HDR gain maps and original brightness. The JPEG base and map are cropped without requantization, with unchanged HDR metadata and color profiles. Inspect the selected areas at 400% in an HDR-capable viewer: displaying only the SDR base would hide the differences being demonstrated here.
Underlying issue
A channel that is nearly zero in both the SDR and HDR image can produce large changes in calculated gain from very small changes in its input. Those gains have little effect on that channel, but lossy encoding of an RGB gain map can spread the variation into channels where it matters. Using 4:4:4 avoids chroma subsampling, but it does not remove the errors introduced by lossy YCbCr encoding.
Proposed change
Adding a small, matching offset to the gain calculation and HDR reconstruction makes these near-zero ratios more stable and reduces the resulting artifacts. The candidate uses a 203/255-nit calculation offset and equivalent normalized 1/255 SDR and HDR metadata offsets. It preserves the existing boost-range selection and caller controls.
This builds on the offset approach discussed in #358. Matching the calculation and metadata offsets is an important part of this version. It applies to best-quality multichannel generation with supplied HDR/SDR inputs, including the shared JPEG, AVIF, and HEIF path. Scalar, realtime, and automatic tone-mapping behavior remain unchanged.
Tradeoffs?
The visible improvements above are the main reason to propose the change. There is also a useful size benefit: across 20 HDR/SDR pairs at three sizes and three gamuts, all 180 JPEG files became smaller, saving 12.8% overall (likely because the unwanted noise is harder to compress). The final native implementation reproduced the study output in eight pilot cases; the full 180-case study was not rerun with that implementation.
Two representative final native tests measured 3.6–3.9% longer total JPEG encoding. Quality was not uniformly better: whole-image luminance error decreased in 161 configurations and increased in 19, and some local regions had higher measured error (though I did not notice visual impact). A smaller offset improved the test charts but was slightly worse on the photos in a separate calibration screen. The proposed value is a tested compromise, not a claim of an optimal setting for every image.
Ranges that exclude 0 stops keep the original math to avoid clipping the adjusted gains. When such a range comes from the image itself, the extra pass can be expensive: an earlier optimized synthetic test measured about 56% longer total JPEG encoding. None of the 180 photo-study configurations had that range condition. Explicit caller limits excluding 0 stops bypass the new calculation up front.
A small complete-file AVIF/HEIF screen also showed smaller files and generally improved or similar HDR error with unchanged base pixels and boost controls. That is supporting evidence, not a guarantee across all images or readers.
In the images I've reviewed visually, the results look as good or better overall, with clear improvements in the examples above. Combined with the smaller files, that seems worth the roughly 4% encoding-time increase measured in my tests.
I'd like to propose the matching-offset change as a focused PR. The implementation and tests are prepared locally. Feedback on the default offset and the quality/performance tradeoff would be welcome.
I've been looking into colored noise and edge artifacts introduced during RGB gain-map encoding. The attached photographs demonstrate the issue clearly. The first of each set is a crop using the current gain map calculations. The second uses an alternative approach I have been testing and shows substantially fewer artifacts.
In the first blue-box example (enlarged to 400% to make it easy to review), the mainline result has strong colored noise across the blue area and a pink artifact along the box. This is consistent with noise I have seen when encoding images with blue skies. The proposed change substantially reduces these artifacts.
In this second sky example (also enlarged to 400%), the change reduces colored artifacts around the stonework against the sky. Artifacts like this in skies adjacent to trees, buildings, or other hard edges are common with the current code.
Both mainline and modified JPEGs already use full-resolution Q80 YCbCr 4:4:4 gain maps. Their SDR bases, compression settings, and selected boost ranges are identical. These examples show a problem that can remain without chroma subsampling; they are separate from the proposal to change AVIF/HEIF maps from 4:2:0 to 4:4:4.
The comparison files retain their HDR gain maps and original brightness. The JPEG base and map are cropped without requantization, with unchanged HDR metadata and color profiles. Inspect the selected areas at 400% in an HDR-capable viewer: displaying only the SDR base would hide the differences being demonstrated here.
Underlying issue
A channel that is nearly zero in both the SDR and HDR image can produce large changes in calculated gain from very small changes in its input. Those gains have little effect on that channel, but lossy encoding of an RGB gain map can spread the variation into channels where it matters. Using 4:4:4 avoids chroma subsampling, but it does not remove the errors introduced by lossy YCbCr encoding.
Proposed change
Adding a small, matching offset to the gain calculation and HDR reconstruction makes these near-zero ratios more stable and reduces the resulting artifacts. The candidate uses a
203/255-nit calculation offset and equivalent normalized1/255SDR and HDR metadata offsets. It preserves the existing boost-range selection and caller controls.This builds on the offset approach discussed in #358. Matching the calculation and metadata offsets is an important part of this version. It applies to best-quality multichannel generation with supplied HDR/SDR inputs, including the shared JPEG, AVIF, and HEIF path. Scalar, realtime, and automatic tone-mapping behavior remain unchanged.
Tradeoffs?
The visible improvements above are the main reason to propose the change. There is also a useful size benefit: across 20 HDR/SDR pairs at three sizes and three gamuts, all 180 JPEG files became smaller, saving 12.8% overall (likely because the unwanted noise is harder to compress). The final native implementation reproduced the study output in eight pilot cases; the full 180-case study was not rerun with that implementation.
Two representative final native tests measured 3.6–3.9% longer total JPEG encoding. Quality was not uniformly better: whole-image luminance error decreased in 161 configurations and increased in 19, and some local regions had higher measured error (though I did not notice visual impact). A smaller offset improved the test charts but was slightly worse on the photos in a separate calibration screen. The proposed value is a tested compromise, not a claim of an optimal setting for every image.
Ranges that exclude 0 stops keep the original math to avoid clipping the adjusted gains. When such a range comes from the image itself, the extra pass can be expensive: an earlier optimized synthetic test measured about 56% longer total JPEG encoding. None of the 180 photo-study configurations had that range condition. Explicit caller limits excluding 0 stops bypass the new calculation up front.
A small complete-file AVIF/HEIF screen also showed smaller files and generally improved or similar HDR error with unchanged base pixels and boost controls. That is supporting evidence, not a guarantee across all images or readers.
In the images I've reviewed visually, the results look as good or better overall, with clear improvements in the examples above. Combined with the smaller files, that seems worth the roughly 4% encoding-time increase measured in my tests.
I'd like to propose the matching-offset change as a focused PR. The implementation and tests are prepared locally. Feedback on the default offset and the quality/performance tradeoff would be welcome.