Re: [PNG] Meeting topics - Nov 13th, 2023

I'm using RGBE images for testing (of a new texture codec), and I've
implemented a couple Radiance .PIC/.HDR format readers/writers over the
years.

Although it's a popular format (I think primarily because it's only 32bpp),
there are a few problems:
http://www.anyhere.com/gward/hdrenc/hdr_encodings.html

1. Only 8-bits of mantissa. There's no implied '1' bit so it really is only
8-bits. Ward points out problems with this in the linked to article: "the
distribution of error is not perceptually uniform with this encoding".
2. 8-bits for exponents seems excessive when half-floats (OpenEXR) only
have 5-bits. Ward states: "Firstly, the dynamic range is much more than
anyone else could ever utilize as a color representation".
3. I don't see how to invertiably and losslessly tone map RGBE so existing
SDR browsers/readers see something passable.
4. RGBE has alpha data, and usually alpha=opacity to existing
browsers/readers. So even less backwards compatibility. Don't see how to
overcome this.

On Fri, Nov 10, 2023 at 2:03 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> RGBE is still pixel storage.  It is still about using RGB, though in a
> more HDR range.  According to
> https://en.wikipedia.org/wiki/RGBE_image_format  Also, according to that
> page, there is no formal standard for RGBE, only a reference to a
> proprietary document (without any licensing information) about an
> implementation in Radiance.  As such, I wouldn’t be in favor of supporting
> it in PNG.
>
>
>
> I haven’t heard any specific use cases and/or users needing YUV, but would
> welcome to hear from some.
>
>
>
> As for other things that aren’t necessary images – like motion vectors –
> it would be worthwhile hearing from specific users who believe that PNG
> (vs. various other existing options) is the right place to store such info.
>
>
>
> Leonard
>
>
>
> *From: *Chris Blume (ProgramMax) <programmax@gmail.com>
> *Date: *Friday, November 10, 2023 at 1:37 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *Richard Geldreich <rich@binomial.info>, public-png@w3.org <
> public-png@w3.org>
> *Subject: *Re: [PNG] Meeting topics - Nov 13th, 2023
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
>
> You are right.
> Rich had mentioned RGBE (rather than RGBA), where the E is a shared
> exponent. This is how the color model / data storage becomes a bit blurred.
>
> There are other *true* color models like YUV that are worth considering.
> And there are also other blurring-the-lines ideas like storing normal maps,
> motion vectors, etc (not really color).
>
>
>
> On Thu, Nov 9, 2023 at 10:47 PM Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
>
> Changing the serialization of the pixel data (e.g. half-floats, or even
> full floats, from integers) is not the same thing as changing color models.
>
>
>
>
> What other color models are we thinking about, Chris?
>
>
>
> Leonard
>
>
>
> *From: *Chris Blume (ProgramMax) <programmax@gmail.com>
> *Date: *Friday, November 10, 2023 at 12:48 AM
> *To: *Richard Geldreich <rich@binomial.info>
> *Cc: *public-png@w3.org <public-png@w3.org>
> *Subject: *Re: [PNG] Meeting topics - Nov 13th, 2023
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
>
> Of course!
> That is part of what I meant for the color models section. You had
> mentioned wanting to discuss it earlier so I wanted to include it.
>
>
>
> On Thu, Nov 9, 2023 at 2:15 PM Richard Geldreich <rich@binomial.info>
> wrote:
>
> Hi Chris - Could we also talk about half float PNG's? I've got some new
> developments that are very interesting.
>
>
>
>
>
> On Thu, Nov 9, 2023 at 1:37 PM Chris Blume (ProgramMax) <
> programmax@gmail.com> wrote:
>
> Hello everyone,
>
> Our next meeting is this coming Monday at 11am Eastern.
>
> Topics:
>
>    - We're going to try a new Zoom link. I'll include both the new link
>    and the old link in the calendar. If the new link doesn't work, try the old
>    link.
>    - How could/should we add additional color models?
>
>
>    - PNG currently has a list of color models. If we want to add more
>       color models, we could add to this list. That was the forward-compatibility
>       intended by the list. It is also what we do with cICP.
>       - But adding to the list would break existing codecs. The key
>       difference between this list and cICP here is without understanding an
>       update to the CICP list (or even the cICP chunk itself), a decoder can
>       still show an approximate representation. But a new item in the color model
>       list does not have an equivalent approximation.
>       - We could have a new chunk signal the new color model. And there
>       can be a fall-back approximate representation provided by the original
>       list. This is effectively what happens now for normal maps, half-floats,
>       etc.
>
>
>    - Marketing subgroup
>
>
>    - Stephanie is spearheading PNG Third Edition marketing. We're
>       thinking of creating a subgroup to discuss how we plan to spread the word.
>       Everyone in the main WG is welcome to join this subgroup. The intention of
>       a subgroup is to not spam the main group.
>
>
>
> Did I miss anything? Are there any other topics you all would like to
> discuss?
>
> See you Monday!
>
>