HDR PQ images render dark/flat after imgproxy v4 processing

We are seeing HDR PQ images become visibly dark/flat after processing through imgproxy v4.0.3.

This reproduces with public test images from the Wide Gamut HDR test page: https://www.wide-gamut.com/test/image-hdr

Example inputs:

• WideGamut-Dolomiti-DisplayP3-HDR.avif
• WideGamut-Drums-B_W-DisplayP3-HDR.avif
• WideGamut-Neon-DisplayP3-HDR.avif
• WideGamut-Portrait-DisplayP3-HDR.avif

ExifTool reports these as true HDR AVIFs:

• MIMEType: image/avif
• ColorPrimaries: SMPTE EG 432-1 / Display P3
• TransferCharacteristics: SMPTE ST 2084, ITU BT.2100 PQ
• HDRMaxValue: +4.00

When viewed directly in an HDR-capable browser/display, they render correctly. After Imgproxy v4 processing, they render as SDR-looking dark/flat images.

Expected behavior

imgproxy should preserve the HDR color signaling when outputting to an HDR-capable format, or otherwise tone-map to SDR intentionally. It should not output an image that keeps high bit depth but loses/changes the PQ transfer and color-primary metadata in a way that renders incorrectly.

Actual behavior

The output looks dark/flat. In our testing, preserve_hdr keeps high bit depth, but the result no longer appears browser-HDR; the output is tagged like SDR/sRGB/bt709 instead of preserving PQ/P3 or PQ/BT.2020 signaling.

Related JPEG regression

We also reproduced a v3 -> v4 regression with PQ-ICC JPEG inputs. In v3, already-RGB images were not passed through ICC import unless linear processing was active:

if convertToLinear || !img.IsRGB() {
    img.ImportColourProfile()
}

In v4, ImportColourProfile() appears to run more broadly. For JPEGs with a Display P3; SMPTE ST 2084 PQ ICC profile, this sends PQ ICC through lcms and crushes the image dark. Locally, restoring the !img.IsRGB() guard prevents the darkening, though it does not add full HDR output support.