Proposal: gain maps for PNG

[svgeesus]

Proposal: gain maps for PNG

This proposal has no official standing in PNG WG and is presented for discussion only. Do not implement.

3 Terms, definitions, and abbreviated terms

Insert:

HDR headroom
the ratio of nominal peak white luminance to reference media white luminance.

4 Concepts

Insert, in a new section after 4.3 Colour spaces:

Baseline and alternate HDR images

Given a baseline image - typically SDR - (which will be the PNG reference image) and an HDR alternate image, a gain map is a space-efficient way to store the information needed to reconstruct the HDR alternate image from the baseline image and gain map, without actually storing the entire HDR alternate image. [ISO_21496-1].

In addition, a gain map provides greater display flexibility. Depending on the available HDR headroom, which varies with display brightness and with viewing conditions, a suitable display image can be computed by scaling the application of the gain map (effectively, interpolating the baseline and alternate images) to produce a result with "some HDR".

Gain maps consist of two parts: per-pixel data, and per-image metadata. These are stored in the gDAT and gMAP chunks, respectively.

5.6 Chunk ordering

To Table 6, add:

Name	Multiple	Ordering Constraints
`gMAP`	No	After IDAT
`gDAT`	Yes	After IDAT

11.3.2.9 gMAP Gain map metadata

The four-byte chunk type field contains the hexadecimal values

67 4D 41 50

If present, the gMAP chunk holds gain map metadata.
If gDAT is also present, an HDR alternate image may be reconstructed.

The gMAP chunk contains:

Width	4 bytes
Height	4 bytes
Bit depth	1 byte
Compression method	1 byte
Filter method	1 byte
Components	1 byte
Colour Primaries	1 byte
Application colorspace	1 byte
Baseline HDR Headroom	4 bytes
Alternate HDR Headroom	4 bytes
Version	1 byte
Gain min values	4 × _Components_ bytes
Gain max values	4 × _Components_ bytes
Baseline offset	4 × _Components_ bytes
Alternate offset	4 × _Components_ bytes
Gamma	4 × _Components_ bytes

Width and height give the image dimensions in pixels. They are PNG four-byte unsigned integers. Zero is an invalid value. Width and Height must have the same aspect ratio as Width and Height in IHDR. They should be the same dimensions, but may be sampled down by a factor of 2 or more.

Note: If the Width and Height are not identical to the reference alternate image, the reconstructed alternate image is not lossless.

Bit depth is a single-byte integer giving the number of bits per sample. Valid values are 8 and 16.

Note: If Bit depth is less than the bit depth of the reference alternate image, the reconstructed alternate image is not lossless.

Compression method is a single-byte integer that indicates the method used to compress the image data. Only compression method 0 (deflate compression with a sliding window of at most 32768 bytes) is defined in this specification.

Filter method is a single-byte integer that indicates the preprocessing method applied to the image data before compression. Only filter method 0 (adaptive filtering with five basic filter types) is defined in this specification.

Components is a single-byte integer that indicates the number of gain map components. It must be either 3 (seperate, per-channel gain maps) or 1 (a single gain map is applied to all three channels).

Note: If Components is 1, the reconstructed alternate image is not lossless.

Colour Primaries is a single-byte integer containing an enumerated value from [ITU-T-H.273] which identifies the color space primaries and white point of the reference alternate image.

Application colorspace is a single-byte integer which indicates whether the gain map is applied in the color space of the baseline image or of the alternate image. The value is 0 if the gain map is applied in a (linear-light version of) the alternate image colorspace, and 1 if it is applied in a (linear-light version of) the baseline image colorspace.

Baseline HDR Headroom is a four-byte floating point value IEEE 754 in network byte order, which indicates H_Baseline, the HDR headroom of the baseline image. It is encoded as a log base 2 number. For an SDR baseline image, baseline HDR headroom will be zero.

Alternate HDR Headroom is a four-byte floating point value IEEE 754 in network byte order, which indicates H_Alternate, the HDR headroom of the alternate image. It is encoded as a log base 2 number.

Example: If the reference media white is 203 cd/m² and the nominal peak white of the HDR alternate image is 1000 cd/m² the alternate HDR headroom would be log2 (1000/203) = 2.3004

Version is a single-byte integer containing the gain map version.

Gain min values is either one or three (depending on the value of Components) four-byte floating point value IEEE 754 in network byte order, which indicates min(G), the minimum values for each component of the gain map. It is encoded as a log base 2 number. It is used to normalize and unnormalize the gain map, see [ISO_21496-1] A3.1 and 6.2.2

Gain max values is either one or three (depending on the value of Components) four-byte single-precision floating point values IEEE 754 in network byte order, which indicates max(G), the maximum value for each component of the gain map. It is encoded as a log base 2 number. It is used to normalize and unnormalize the gain map, see [ISO_21496-1] A3.1 and 6.2.2

Baseline offset is either one or three (depending on the value of Components) four-byte single-precision floating point values IEEE 754 in network byte order, which indicates the baseline offset for each component of the gain map, k_baseline. It is used to avoid numerical issues when computing the gain map, see [ISO_21496-1] A2 and 6.3

Alternate offset is either one or three (depending on the value of Components) four-byte single-precision floating point values IEEE 754 in network byte order, which indicates the alternate offset for each component of the gain map, k_alternate. It is used to avoid numerical issues when computing the gain map, see [ISO_21496-1] A2 and 6.3

Gamma is either one or three (depending on the value of Components) four-byte single-precision floating point values IEEE 754 in network byte order, which indicates the per-component gamma values applied to each component of the gain as a pre-compression step, see [ISO_21496-1] A3.2 and 6.2.2

11.3.2.9 gDAT Gain map image data

The four-byte chunk type field contains the hexadecimal values

67 44 41 54

The gDAT chunk serves the same purpose for HDR alternate images as the `IDAT`` chunk does for baseline images; it contains the per-pixel gain map data. It holds the compressed gain map data. Each chunk contains:

Sequence	4 bytes
Map data	_n_ bytes

The compressed datastream is then the concatenation of the contents of the data fields of all the gdAT chunks, (noting that data fields may be of zero length). When decompressed, the datastream is the complete per-pixel data as a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the IDAT chunks.

The computed gain map data (see [ISO_21496-1] A.2), after any preprocessing (see [ISO_21496-1]A.3), prior to chunking, filtering and compression, is held as a PNG image with colour type 0 (Greyscale) and bit depth 16, for a one-component gain map; or colour type 2 (Truecolour) and bit depth 16, for a three-component gain map. The 16-bit values are two-byte half-precision float16 values [IEEE 754-2008].

there is an open question on required precision and quantisation, the ISO draft is unclear

[svgeesus]

Explanation of Proposal: gain maps for PNG

gMAP

This is ancillary, as the baseline image can always be displayed.
It is public, and unsafe to copy because the contents depend on the image data
Like the animation chunks, it goes after IDAT as it does not affect display of the baseline image.

The items in this chunk correspond to the items in [ISO_21496-1] 5.2 Gain map metadata and 5.3 Colorimetry metadata.

The first five items are same as IHDR and use the same data types and introductory wording.

For resampled gain maps, a factor of 2 is mentioned in the ISO spec, but seems to be illustrative so other samplings are possible. A.3.3 mentions optional down sampling by a factor of "two or more".

The "same aspect ratio" constraint also implements the "must have same orientation" constraint from the ISO specification, 4.5 Orientation.

(No Colour Type or Interlace method, not needed, omitted)

As with `IHDR``, Compression method and Filter method take only a single value and are reserved for later expansion. But if that expansion ever happens it would need to apply here too.

Colour Primaries are the same as the corresponding field in cICP However, there is no equivalent to the cICP Transfer Function, Matrix Coefficients or Video Full Range Flag, because of the way the gain map is computed.

The headroom, min/max, offset and gamma values are encoded as
one or three (depending on the value of Components) 32-bit IEEE floating point values in network byte order (big-endian, like all PNG multi-byte numerical values). Because they are variable sized, they are grouped together at the end of the data block so the fixed-size fields can have constant offsets.

Intended use of the Version field is unclear, but the ISO spec in section 5.2.11 requires it. Need to find out if the initial version is 0 or 1 :)

Proposal will need to update 4. Concepts. For now, just HDR Headroom was defined.

gDAT

This is the per-pixel gain map. Like IDAT and fdAT, this holds a png compressed image stored as either a Grayscale image or an RGB image depending on the value of Components.

This is ancillary, as the baseline image can always be displayed.
It is public, and unsafe to copy because the contents depend on the image data
Like the animation chunks, it goes after IDAT as it does not affect display of the baseline image. (Ideally it should be after gMAP, but chunk ordering rules of ancillary chunks preclude this. So they can be in either order).

The utility of PNG filtering on an array of half-float data would need to be investigated.

Required precision of the stored gain map, and any quantization, is unspecified. If stored as an array of float or half-float then (assuming the baseline and alternate images are quantized) the size savings need to be demonstrated as does the bit-identical round-tripping of the alternate image (with no down-sampling, and a three-component gain map). This proposal assumes a PNG colour type 0 or 2 image at 16bits, containing FP16 gain map data.

Interaction between the alternate image and mDCv and cLLi is yet to be specified.

[palemieux]

What problem is this solving since PNG already supports native HDR imagery?

[svgeesus]

What problem is this solving since PNG already supports native HDR imagery?

Good question. PNG supports a single HDR image, yes. This solves (or, their spec claims to solve):

• holding an SDR and an HDR image in one image file
• enabling the degree of HDRness to be adjusted depending on HDR headroom at the display
• being more efficient than storing two complete images

I have not seen any data regarding the third claim.

[leo-barnes]

Here's a question for the PNG WG:
We need to define roughly the same metadata in HEIF (latest proposal in WD here). It would be very nice if it would be possible to do lossless metadata round-tripping between HEIF and PNG. Would it make sense for TC42 to define a binary metadata payload that could be used by both HEIF and PNG (and maybe other formats)? HEIF and PNG specs could then simply define the appropriate wrapping boxes/chunks and refer to the gain map spec on the contents.

[fintelia]

I haven't read the actual spec, so I can't comment on whether gain maps are a good idea for PNG. But I can give some feedback on the gMAP chunk itself:

Many of the fields are highly constrained, if not outright redundant. Compression method and filter method both have only a single valid value and even if more were added in the future, I don't see why defining the gain map to use the same filtering and compression as specified in the IHDR would actually cause any issue. That's what APNG does after all. The height field in the gMAP chunk is similarly redundant: given the dimensions in the IHDR and the width, there's only one valid value it could hold for the aspect ratios to match. Further, the components and bit depth fields are 8-bit values that each only have two valid values.

Several of the other fields seem like they might be expected to match metadata elsewhere in the image, but without spec access I can't say whether mismatching values could make sense. Regardless, care should be taken that the meaning of metadata here exactly matches elsewhere in the PNG spec. Even using fixed precision in the gAMA chunk and floating point here probably isn't ideal.

Another point that's worth noting but probably not a huge deal at this point is that AFAIK this would be the first PNG chunk with a floating point value in it.

[ProgramMax]

My initial thought (I haven't finished reading--will update as I do) is that this is similar to other non-RGB channels.
That brings up new color type list vs new chunk.

And if we go the new chunk route, it makes me wonder if each new non-RGB channel should have a unique chunk (gMAP & gDAT) or if there should be some shared chunk.

(Also, the rules for different resolutions sound great. That could apply to YUV-type images some day.)

[ProgramMax]

Is there time pressure to get an answer back to ISO quickly?

[svgeesus]

I haven't read the actual spec, so I can't comment on whether gain maps are a good idea for PNG.

I have asked that the ISO draft spec be made public to facilitate discussion, but so far there has been no reply.

[svgeesus]

Many of the fields are highly constrained, if not outright redundant. Compression method and filter method both have only a single valid value and even if more were added in the future, I don't see why defining the gain map to use the same filtering and compression as specified in the IHDR would actually cause any issue. That's what APNG does after all. The height field in the gMAP chunk is similarly redundant: given the dimensions in the IHDR and the width, there's only one valid value it could hold for the aspect ratios to match. Further, the components and bit depth fields are 8-bit values that each only have two valid values.

These are all good points and I was trying in this first draft to not close off any extensibility points and to follow the ISO specification literally. "Same as IHDR" could certainly work, and "must have same dimensions as IHDR would be a defensible position for a lossless format.

[svgeesus]

Another point that's worth noting but probably not a huge deal at this point is that AFAIK this would be the first PNG chunk with a floating point value in it.

Yes, I am aware. There have been attempts to use float data before, and IIRC they used human readable strings like "3.14" which seems like an interop nightmare.

[svgeesus]

Several of the other fields seem like they might be expected to match metadata elsewhere in the image, but without spec access I can't say whether mismatching values could make sense. Regardless, care should be taken that the meaning of metadata here exactly matches elsewhere in the PNG spec. Even using fixed precision in the gAMA chunk and floating point here probably isn't ideal.

None of them are matching data elsewhere in the image. The gamma value is a gamma applied to the gain map data, not the image gamma, for instance. Again, hard to tell without the actual specification I know; I wish I was allowed to share it.

[svgeesus]

Is there time pressure to get an answer back to ISO quickly?

There is a joint meeting in Tokyo in February 2024 where HDR in general and HDR gain maps at ISO, in particular, will be discussed. I have been asked to report on all W3C HDR-related work at that meeting.

[ProgramMax]

I just noticed this, published 2024-01-05:
https://developer.android.com/media/platform/hdr-image-format

[leo-barnes]

I just noticed this, published 2024-01-05: https://developer.android.com/media/platform/hdr-image-format

The UltraHDR format is basically identical to Adobe's white-paper. I think it got released mid-2023.

Just as a FYI, there is a proposed update to the 21496-1 draft that outlines what things an image format needs to specify to correctly store a 21496-1 gain map, as well as a recommended binary payload containing the required metadata. The metadata payload is not enough since the image container needs to specify things like which image is the base, what the base and alternate color spaces are and similar.

[svgeesus]

Just as a FYI, there is a proposed update to the 21496-1 draft that outlines what things an image format needs to specify to correctly store a 21496-1 gain map, as well as a recommended binary payload containing the required metadata. The metadata payload is not enough since the image container needs to specify things like which image is the base, what the base and alternate color spaces are and similar.

It would be really useful to get a copy of that update so I can read it ahead of the Tokyo meeting.

[ProgramMax]

I just realized that ordering might be an issue. Or it might not.

If gainmap information comes after IDATs, a browser might display an SDR image during download and then have an update pass which applies the gainmap as it is downloaded. This is unlike RGB channels, which are interleaved.

If gainmap information comes before IDATs, it would not cause that update pass. But it would delay coloring in pixels, which is an indicator to users that progress is happening.

This problem applies to all channels which will be displayed.
For future expansion, there could be channels which aren't displayed or which aren't initially displayed. Those can come after IDAT. And those might be flexible. Perhaps Project A deems channel X as non-initial. But Project B deems channel X as initial and channel Y as non-initial.

Additionally, progressive enhancement could apply, furthering the complication on interleaving.

PNG is built around treating image data as bytes and not pixels. This has a handful of downsides. But one potential upside is it allows adding new interleaved channels.

[fintelia]

I didn't notice it before, but you bring up a good point. Regardless of whether gDAT comes before or after the IDAT chunks, I think that gMAP should be required to come before the IDATs. The existence of a gain map is metadata and so having that requirement would align it with the other metadata chunks. It would also prevent decoders from having to seek past all the IDATs to know whether the image has a gain map

[ProgramMax]

We might be able to interleave gDAT and IDAT chunks.

I need to double check this against existing decoders and the spec. But right now, I think it would work.
Due to the chunk overhead, a decoder cannot simply memcpy from first IDAT to last IDAT into zlib, as an example. It needs to copy one IDAT's body at a time. Which means it is already parsing the IDAT. And since it needs to check for IEND, I don't think the decoder is blindly ignoring the next chunk type, assuming it will be IDAT.

But I could imagine a scenario where either the spec or the decoder say it will be a stream of IDATs until an IEND is reached.

I think interleaving gDAT and IDAT is our best bet for adding more visible channels beyond RGB. The downside is we aren't interleaving channels on a per-pixel level like RGB data already does. But it is interleaving as much as possible in a backward- & forward-compatible way.

[gregbenz]

For my own education, can someone share why this might be preferred over another image format which supports gain maps and alpha. Both AVIF and JXL could support those needs, and at much smaller file sizes than PNG. Is there some other important use case I'm overlooking?

I could see an argument for backwards compatibility here. However general AVIF support is now in all major browsers, so that's probably going to be fairly niche by the time we'd have support for PNG gain map rendering. Certainly is editing software and such and perhaps the interest in legacy support is higher than I might guess. Just not sure if I'm overlooking some other gap this might address.

[ProgramMax]

Fundamentally, because competition is good.

You mentioned backwards compatibility. And you mentioned that perhaps it should be given more weight. I might be able to provide some examples to justify more weight. For example, the US Library of Congress lists PNG as a preferred format and will not accept AVIF and JXL. That has knock-on effects for organizations working with the government.
There is also all sorts of hardware & software throughout the world of broadcast and satellite imaging...

There is also forward compatibility. PNG is VERY forward compatible, in ways almost no file format is. But to be fair, almost no tooling uses this. I should make a ranty blog post about that :)

I think more to your point, AVIF and JXL can produce smaller files currently. For PNG Third Edition, we aren't planning any improvements to compression. But there is a good chance that Fourth Edition will. At which point you could perhaps ask your same question to AVIF & JXL. (This goes back to my "competition is good" point.)

When we talk about compression, we're really talking about 3 separate things. Only one of them is compression. The others are tuning the data for the observer (IE jpeg's chroma subsampling & mp3s dropping sounds we likely wouldn't perceive) and tuning the data to the compressor (IE png's filtering or just general quantization).

PNG is based on Huffman coding, which is proven to be the most efficient type of symbol compression. If we treat "compression" as those 3 distinct steps, we can provide optimal file sizes, too. The problem right now is PNG doesn't get chroma subsampling, for example.

So it would be a shame for humanity to abandon PNG (or Huffman in general).

Hope this helps :)

[gregbenz]

@ProgramMax Thank you for the extra context and info!

[fintelia]

Interleaving gDAT and IDAT chunks wouldn't be backwards compatible. The version 1.2 spec says:

There can be multiple IDAT chunks; if so, they must appear consecutively with no other intervening chunks.

[ProgramMax]

Shoot.
Good find. Thank you.

[ccameron-chromium]

I'd like to know people's thoughts on alternate image metadata.

Both the base image (the normal image) and the alternate image (the image that results from fully applying the gain map) can have the full complement of 22028-5 metadata. This would include the color space (as sRGB, iCCP, or cICP), along with mDCv, cLLI, and potentially others (22028-5 include ccv, ndwt, and reve).

What would be the best way to represent these in a PNG?

Option A:

• Have gMAP start as it does in the proposal, up to Colour Primaries
• Then have the ISO 21496-1 binary blob "sub-chunk"
• Then have a bunch of "sub-chunks" that can be sRGB, iCCP, cICP, mDCv, cLLI, or any others

Option B:

• Have gMAP for the base image just be the "version only" ISO 21495-1 blob (as is done in JPEG)
• Have gDAT be a full separate PNG file (including all chunks)
• Have gMAP in the gainmap image be the full parameter set (as is done in JPEG)

Option C:

• A better idea I'm not thinking of here

Of note is that for JPEG, the image is stored using MPF (CIPA DC-007), which requires that the gainmap image be stored contiguously and entirely-after the base image. This is more like "Option B".

(Also, FWIW, I'm trying to get the liaison thing pushed forward).

[ProgramMax]

IIUC for Options A & B you're considering nesting chunks, right?
I think most PNG decoders would need some work to support nesting. And we would need to specify nesting errors.
I'm not opposed to the idea. Just making sure I understand and thinking out loud.

If I could start over from scratch, I think I would make channels more dynamic. Rather than hard coding RGB/grayscale and then adding an additional channel for gainmaps, I think I would allow channels to be tagged with the data they support. So gainmaps would be just another channel. Decoders support the channels they choose. Then metadata could specify what channels they apply to.
(This mentality would also take significant work for existing decoders. Also, maybe channel groups so "RGB" can still be bundled for a faster code path.)

Currently, all chunks are assumed to apply to all channels. If we do end up allowing additional channels, perhaps we could add a chunk that clarifies "the following chunk applies to these channels: 0,1,2" or something similar. That would let us avoid nesting, if we decide that is a good thing. But it does so by requiring additional state be tracked across chunks. Given that things like color space already are state tracked across chunks, I think that would be okay.

[palemieux]

Remind me why gain map metadata is useful in the context of PNG, which is a lossless image format? What use case(s) is this targeting?

[gregbenz]

The gain map metadata is key to adapting the image to the display. It provides the information necessary to determine how much weight to give the alternate vs base image. It also describes the encoding of the gain map data (which may use different ranges, gammas, and offsets). The gain map on its own isn't a real image nor a complete set of instructions to render the alternate version of the image.

[ProgramMax]

This is not my area of expertise so please correct my knowledge gaps.

My understanding is the SDR base image is itself a good image to use on SDR displays.
And the gain map then allows scaling that SDR image into HDR for HDR displays.

Also as I understand it, the data being separate allows for better tone mapping across various HDR display capabilities. (And since it is per-pixel, maybe even allowing the artist's hand to be involved.)

[gregbenz]

A gain map specifies 2 images. The base is a real image and the alternative is derived by applying per-pixel multiples to the base (which are determined using the gain map and metadata). This is almost like providing two images, but at a significantly smaller total size. At the extremes, the alternate image is handcuffed to the base image to a degree - but with proper encoding it provides tremendous latitude to derive a high quality alternative version of the same scene (this would not generally be a good approach for combining two unrelated images).

At this time, the base image is SDR and the alternate would be an HDR. But we'll see more variation in time. Because the alternate is likely of lower quality than a true image (at least when optimized to reduce file size), it would be ideal to encode the base image as HDR in the future when HDR screens are more common (and gain maps are widely supported, as using an SDR base offers better backwards compatibility with decodes which do not understand gain maps). One could even encode a gain map for two HDR images (such as a +2 stop version and a +6 stop version when we have support for the full 10,000 nit PQ range), in which case an SDR display would have to tone map down from the +2 stop version. So there would be a tradeoff there, but it is a possible use.

Because it is per-pixel, it can be optimized much more than any global tone mapper and can in theory allow significant artistic input to optimize the base image (in practice this depends on the encoding).

Additionally (as long as you encode an SDR as base or alternate), no tone mapping needed. The extreme ends of the display range are explicitly provided and you eliminate variability in how one display might be tone mapped compared to another. So consistency is improved as well.

[gregbenz]

More info on gain maps from an artistic perspective: https://gregbenzphotography.com/hdr-photos/jpg-hdr-gain-maps-in-adobe-camera-raw/

[palemieux]

AFAIK no image editing software will use gain maps as their internal representation, i.e., a gain map representation will be generated during export and this will be a lossy step unless it is possible to make the gain map algorithm lossless. Since this step will be lossy, why use PNG and not JPEG, JPEG XL, J2K, etc. which will all result in a smaller image?

[gregbenz]

The base image (which could be HDR as the more important version) could be encoded as a lossless image with a gain map. So the alternative (SDR in this example) would be visually (but not completely) lossless - and the base HDR image would be truly lossless.

One could of course use another lossless format for archiving as a gain map, assuming PNG is not preferred or the only approved format for a given institution.

[palemieux]

@gregbenz Thanks for confirming. PNG is lossless in people's mind so using in a lossy use case does not seem ideal.

[gregbenz]

@palemieux Just to be clear here - This is just my opinion as an artist / independent developer who has worked quite a bit with currently available gain map concepts. I have not done any validation testing to support or disprove my hypothesis. And I do not have a background in archival processes used by governments, museums, etc.

[fintelia]

The lack of a public spec makes it hard to say with certainty, but based on the use of 16-bit floats the gain map should have under 0.1% maximum error. That's far lower what you'd expect from lossy formats like JPEG, and in fact, is better than any 8-bit format can do

[ProgramMax]

IIUC, I agree with @fintelia. Loss due to quantizing floats to ints from the original edit doesn't cross the lossy/lossless bar in my mind. That has always been true even prior to gain maps.

If the original tool used ints and if the gain map equation can be perfectly mapped 1:1, there would be no loss.

Perhaps the gain map equation isn't 1:1 mappable?

[palemieux]

To be sure, by "lossless", I meant "mathematically lossless".

The point is that PNG is used in applications where mathematically lossless is expected. There are many better image formats for applications where loss is tolerable (whether visually detectable or not). So, I am questioning whether adding support for (lossy) gain maps is worth the effort (and the potential confusion).

[ProgramMax]

If image editing software wanted to save 240.5 into the red channel, it would need to quantize to an int, too. But that seems to be okay for the "lossless" zeitgeist.

[palemieux]

Someone would not save in PNG if they were authoring in floating point. They would instead save as EXR, TIFF, J2K, etc.

[ccameron-chromium]

IIUC for Options A & B you're considering nesting chunks, right? I think most PNG decoders would need some work to support nesting. And we would need to specify nesting errors. I'm not opposed to the idea. Just making sure I understand and thinking out loud.

Yeah, same here (thinking aloud).

There is also another option I hadn't thought of:

Option C

• Introduce "alternate-cICP", "alternate-mDCv" and "alternate-cLLI" chunks

Option D:

• Introduce only "alternate iCCP" chunk
• Assume that ICC profiles will expand to include MDCV, CLLI, etc (as they have already expanded to include CICP)

I'll try to figure out in the ICC meeting if they're thinking to roll more metadatas into profiles (it would be nice to have a "one stop shop" for that stuff).

[leo-barnes]

PNG

For me, the main use-case for PNG is when:

1. I need a portable image format that is supported basically everywhere
2. I need to store non-photographic content
   and/or
   I need to store >8-bit content or alpha

If I need an ultra-portable format for photographic content I would use JPEG. The fact that PNG is lossless has very little to do with whether I choose it or not. (Not saying that this is not important to other use-cases, but it's usually not that important to my use-cases.)

Gain maps

For me the main use-case for 21496-1 gain maps is twofold:

1. Creating backwards compatible HDR images
2. Create HDR images that also look great when rendered in SDR

---

The reason for adding gain maps to PNG is really to address the following:

1. I need a portable image format that is supported basically everywhere
2. I need to store non-photographic content
   and/or
   I need to store >8-bit content or alpha
3. I need to store HDR content that looks good in SDR as well

JPEG-XL is very much not portable. AVIF is more portable but not when compared to the portability of PNG. And AVIF may end up compressing worse than PNG for non-photographic content.

If gain maps can be added to PNG in such a way that they are backwards compatible I think it makes very much sense to do so. If it can't be made backwards compatible it doesn't really make much sense to add it though.

[anforowicz]

gMAP => no acTL?

The proposal here says that there would only be a single gMAP chunk and I assume that there would only be a single sequence of gDAT chunks (i.e. a single gain map image/frame). These assumptions seem desirable and may make it easier to design decoder APIs for exposing gain-map-related information. If those assumptions hold (I hope that they do), then the spec should probably explicitly say that gMAP and acTL chunks are mutually exclusive.