Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liaison letter from ISO TC 42/WG 23 on Gain Maps #366

Open
svgeesus opened this issue Nov 7, 2023 · 7 comments
Open

Liaison letter from ISO TC 42/WG 23 on Gain Maps #366

svgeesus opened this issue Nov 7, 2023 · 7 comments

Comments

@svgeesus
Copy link
Contributor

svgeesus commented Nov 7, 2023

Liaison_Letter_to_the_W3C_from_ISO_TC_42.pdf

@svgeesus
Copy link
Contributor Author

svgeesus commented Nov 7, 2023

(They also sent a draft of the specification, but it has restrictions on public storage. I am asking them to lift that restriction, so we can discuss it)

@svgeesus svgeesus changed the title Liaison letter from ISO TC 42 on Gain Maps Liaison letter from ISO TC 42/WG 23 on Gain Maps Nov 7, 2023
@svgeesus
Copy link
Contributor Author

svgeesus commented Nov 7, 2023

I have been aware of the work since 2021, and have discussed it at a couple of ICC HDR WG meetings; I also saw a demo of this, in Adobe Photoshop and running on an HDR display, at the ICC meeting in London in April this year. However, this is the first time I have seen the actual draft text of the specification, which clears up some questions I had and raises others.

The overall approach is a good one, and it gives excellent results with much less filesize overhead and more flexibility on viewing conditions, compared to storing the two images separately.

The ISO draft spec, in Annex C, has placeholders for gain maps in AVIF, HEIF and JPEG but not for PNG. We should ask that they add one for PNG as well.

@svgeesus
Copy link
Contributor Author

svgeesus commented Nov 7, 2023

TC42-reply-20231107.pdf

@leo-barnes
Copy link

Not speaking for TC42 here, but I'm heavily involved with the HEIF/AVIF side of things.

The way we're doing it there is that we're adding dedicated signaling to the HEIF spec that describes how the required metadata in 21496-1 shall be stored in a HEIF file. I would then imagine that the HEIF/AVIF sections in 21496-1 would simply refer to the relevant section in HEIF rather than spell out exactly how it works.

Concretely, we propose doing this in HEIF by creating a new derived item type that describes how the inputs (base image and gain map) are combined into a reconstructed image. The metadata needed is stored in the box body of that item using a dedicated structure rather than as XMP which is what the current demo files do.

@svgeesus
Copy link
Contributor Author

Yes, I would expect 21496-1 to take the same approach with PNG

@leo-barnes
Copy link

Not sure how you would be planning on storing this in PNG, but if you decide on taking the approach of having a dedicated structure for the metadata rather than relying on XMP, it might be worth syncing up on it. Would be kind of nice if it's at least roughly the same as what we're proposing in HEIF.

@svgeesus
Copy link
Contributor Author

For the purposes of discussion, here is a proposal for storing gain maps in PNG.

There are a number of open issues where the ISO draft spec is unclear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants