Re: [PNG] Meeting minutes - Apr 14th, 2025

>
> I assume this refers to maps other than
> "gain maps" such as "height" maps (most commonly people seem to call
> these "bump" maps although that term is technically more general).


Correct.

For what it's worth, this was not left out of the meeting minutes. The
information has been available elsewhere for quite a while.
I believe the meeting minutes are a fair representation of everything of
value. A recording of the minutes would not have helped here.



There are many issues coming together here and they come together as a
> generalization of the base APNG format (fdAT with a control chunk) to
> allow arbitrary 2D maps to be stored.
>
> But was this mentioned, discussed, raised, deferred?


It was not mentioned. Hence why it wasn't in the minutes. :)

The relation to APNG is interesting. But there is an important difference
that I think people miss so I want to elaborate on it here. It is unrelated
to your point though.
Prior to the last meeting, I sent an email with this link showing how games
use multiple maps on an object <https://cpetry.github.io/NormalMap-Online/>.
Click any of the 4 buttons above the center image to see that map.
Notice the images can be visualized as RGB, grayscale, grayscale, and
grayscale.
Also notice the images are VERY similar.

Using current APNG rules, each fdAT needs to have the same color type as
the IDAT. We could technically save the grayscale maps as RGB but that is
wasteful. And none of the data is truly RGB or grayscale anyway--that's
just the visualization of it.

Second, the image similarity: RGB PNGs store those 3 channels interleaved
because a change in one channel often relates to a change in another
channel. This is effectively a form of filtering, allowing the data to
compress better. The same is true in this example image. The 6 channels are
all very similar and interleaving their data would result in better
compression than storing 4 separate images.

Okay, that's all for my tangent. Returning to your points.



I'm particularly mystified by the two comments:
>
> >Enough doubt about complication vs. simplicity and if that is worth any
> potential benefit
> >Possibly revisit based on gain maps


There had previously been plenty of comments along the lines of "This seems
like a lot of work. Is it worth it?"
In this meeting I brought up if we want to add generic image-like data to
the docket for Fourth Edition and we agreed not to based on previous
discussions of complexity vs. benefit.

I'm making up an example here to try to recap various previous discussions.
But suppose we add infrared for satellite images. Many satellite images
will contain two separate infrared channels. Do we then allow specifying a
wavelength range? Or perhaps a curve of wavelength sensitivity? Do we
record the lat & long of the satellite? Field of view?
What if it is a satellite orbiting Mars? Have we defined a longitude system
for Mars? I don't know that.
What if the satellite is above X,Y but it is angled? Do we record its
pitch/roll/yaw? What are those relative to, if so?

My point is we need to bring in experts in many different fields to weigh
in on each channel we want to define.
And even then, what if it's just a regular ol' infrared camera I was using
to look at my car's engine to diagnose a hot exhaust port? None of the
above applies any more.

Or maybe we skip all that and let each user/client maintain their own
parameters. But then we aren't providing much value.
Or maybe we can allow a range of values to be user defined and we'll slowly
add channel definitions as we go. This is almost certainly what will have
to happen, if we go down this route. Plus make it future-proof. This is all
do-able. It's just a lot of work.


As far as revisiting based on gain maps: Gain maps might become the
industry standard. Or maybe gain curves. We're waiting for that standard to
finalize (which should be soon) before we move. If they DO arrive on gain
maps, it might be worth adding them as the first channel defined in a
generic image-like data way. Or it might not, if they define a specific
data structure and it would be more compatible for us to use their
structure.


One of my tasks is to make a tool to allow us to experiment with different
ideas. I figure adding support for generic data would be a good fit for the
tool, too. But since it likely won't make it into Fourth Edition, that is a
low priority for me.

On Tue, Apr 22, 2025 at 2:15 PM John Bowler <
john.cunningham.bowler@gmail.com> wrote:

> >That would not have been okay, to be clear:
> https://www.w3.org/policies/process/#meeting-recording
>
> However the following section pretty much says that _discussions_ have
> to be minuted.  Normally this is done either by a dedicated trained
> recorder or by an audio recording which is minuted after the meeting
> by the nominated recorder.  As @programmax observes:
>
> >During the meetings, I have been taking minutes + running the meetings.
> You're right that they're very summarized. It is difficult to juggle it all
> quickly enough to keep the pacing.
>
> Yes.  I'd describe the task as impossible.  Oregon has pretty much
> come down to using audio recordings for all government meetings
> because there is rarely money for a trained recorder; I've only seen
> them in courts.  Even Grand Jury testimony is now recorded by audio.
>
> But I don't see a real problem; given your situation surely the
> meeting members would consent to you recording the meeting solely for
> the minutes?   The group could decide whether to destroy the recording
> after you had produced minutes or to archive it solely for the purpose
> of resolving any dispute over the content of the minutes.
>
> >Is there something you're hoping to learn that wasn't sufficiently
> covered by the summary?
>
> Indeed there is.  It's a separate topic and it comes down to the
> "Generic image data" item.  I assume this refers to maps other than
> "gain maps" such as "height" maps (most commonly people seem to call
> these "bump" maps although that term is technically more general).
>
> APNG already defines a basic approach for storing additional "maps" in
> a single PNG file using sequence numbers and storing interlaced
> control information and IDAT compressed data.  The use of APNG for
> storing PCB layouts where each layer of the layout is a separate APNG
> frame has been raised elsewhere as part of the APNG implementation
> discussion.  The context is for a "plug in" for KiCAD.
>
> Previously @svgeeus had raised the idea of generalising the APNG fcTL
> and fdAT chunks:
>
> https://sourceforge.net/p/png-mng/mailman/message/36044127/
>
> The links in that message can be found by deleting the spurious ">" at
> the end of the URIs (they will show 'page not found' on first click.)
>  The second link in particular refers, in passing, to "layers" but
> that's an established requirement (the KiCAD plug-in) and, despite the
> "can of worms" comment seems to be very simple to implement.
>
> There are many issues coming together here and they come together as a
> generalization of the base APNG format (fdAT with a control chunk) to
> allow arbitrary 2D maps to be stored.
>
> But was this mentioned, discussed, raised, deferred?
>
> I'm particularly mystified by the two comments:
>
> >Enough doubt about complication vs. simplicity and if that is worth any
> potential benefit
> >Possibly revisit based on gain maps
>
> What does that mean?   Certainly gain maps are a whole lot more
> complicated than height maps and way, way more complicated than layers
> or sprites in general.  The solution to gain maps necessarily involves
> a new control chunk which can change the IHDR format fields (colour
> type and bit depth) and, yes, that change is necessary for bump maps
> most of the time but bump maps (in the sense of height maps) _are
> already implemented in PNG_.  Height maps are interchangeable as PNG
> files between different 3D rendering programs; the only issue is how
> to package the height map with the texture map.  What is more adding
> all the other maps commonly used is pretty much a no-brainer because
> FOSS software already does it and has done it for years.   There's a
> massive list of such maps.  I just looked at the UI from a modeller
> for a texture designed for use with NVidia Iray - I counted 45
> different maps I can set.  But this isn't complexity at the PNG level,
> all of those maps are _already_ described in PNG.  They just can't be
> packaged together!
>
> John Bowler <jbowler@acm.org>
>