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

>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>

Received on Tuesday, 22 April 2025 18:15:42 UTC