Repository navigation
Replies: 2 comments 2 replies
|
I would suggest keeping this as-is. libvips defaults to That said, there are also cases where stripping the gain map is appropriate (besides the file size overhead). For example, I came across this Reddit post: |
|
Thanks, Kleis. I agree that intentionally producing SDR is a valid use case, and my proposal would retain an explicit option to discard gain maps. My concern is that a user intending to strip metadata for privacy isn’t necessarily choosing to strip gain maps or convert to SDR. A caller using keep=none may unintentionally remove the gain map too, changing the image’s appearance. That loss can easily go unnoticed when testing on an SDR display. The logo example raises a broader question: removing gain maps does not necessarily eliminate HDR. Images can encode HDR directly without a gain map (PNG, AVIF, JXL, HEIF, and even JPEG with the right HDR ICC profile). Those cases require an appropriate HDR-to-SDR conversion, generally including tone mapping. My proposal keeps intentional gain-map removal available, while separating it from metadata stripping for privacy. I recognize that this changes the behavior of keep=none; the question is whether removing private metadata should also imply discarding rendering information. |
|
I think those Keeping gain maps could also be a "security issue" since an image can be made to look very different in SDR and HDR. That's one reason websites often only allow a few "safe" image formats (e.g. only JPEG/PNG/GIF) and don't allow formats like SVG or PDF, because you don't always know how they will render. For example, someone could create a purchase contract that shows €11,000 in HDR but €111,000 in SDR. You approve it on an HDR screen, but when it is printed, the SDR version is used. This could be abused to trick you into signing a price you never agreed to. |
|
I agree that file size and avoiding alternate SDR/HDR renderings are valid reasons to discard a gain map. The proposal here preserves that choice. The concern is callers using the same setting for privacy or reducing file size without realizing it also changes the image’s HDR appearance. Your ICC point is relevant: metadata can include information needed to render the image correctly, as well as private or descriptive information. That distinction is what I’m trying to make clearer. I recognize that the existing flags allow selective retention, but callers need to know that gain maps exist and affect rendering before they can avoid accidentally removing them. I believe preserving gain maps and removing metadata which does not impact image rendering should be choices callers can make independently. |
Uh oh!
There was an error while loading. Please reload this page.
Would libvips be open to separating controls for gain-map retention from those for ancillary metadata? There are likely accidental or unwanted results under the current design. For example, a downstream user using
keep=nonefor privacy may be unaware this removes gain-map HDR rendering from supported SDR-base JPEGs. This impact may be unintended and go undetected in routine testing (depending on source images and whether the developer has a system supporting HDR display).When processing an image, there are likely related choices for downstream users for fidelity, privacy, file size, and potentially forced conversion to SDR. The current controls overlap for these independent considerations.
Separating controls for private / descriptive metadata from controls for gain maps may help simplify and clarify choices to ensure expected results.
Proposal for consideration:
There are likely several potential ways to consider improvements here. Here is one possible approach which would offer more control, but might require some downstream updates if current metadata controls were used to intentionally strip gain maps.
Add a "preserve_gainmap" option which explicitly controls whether a gain map and the metadata required to use it are retained. The option would default to
true. Discarding the gain map would require an explicit request. Thegainmapflag in keep would remain valid syntax but would no longer affect retention.This is a behavioral compatibility change:
keep=noneand other retention masks that exclude gainmap would no longer remove it. Callers that intentionally discard gain maps would need to setpreserve_gainmap=false.preserve_gainmap=falseremoves the map and dependent HDR signaling, even withkeep=all.Example:
keep=noneor a selective mask withoutgainmapstrip=truepreserve_gainmap=false, keep=allpreserve_gainmap=false, keep=gainmapWould the maintainers consider this direction, and what migration would be preferred?
All reactions