Unnecessary PNG metadata generated

[MasterQuestionable]

͏    "PNG-pHYs"
͏    "CICodePoints"
͏    "PrimaryChromaticities"
͏    "Gamma"

͏    No use for most implementations. (outright ignored)

͏    Sort of regression. (per <colorspace>)

͏    See also: ​https://exiftool.org/TagNames/PNG.html
͏    "Extra.txt": ​https://trac.ffmpeg.org/attachment/ticket/11002/Extra.txt

[Balling]

No use for most implementations.

Main implementations: Chrome, Gimp, Firefox support gAMA and cHRM. As for CICP that is a future standard, that is needed for BT.709 transfer support (very different from sRGB) and PQ HDR. Also gAMA needed for 2.2 vs sRGB. Also image magik reads them.

Adobe Photoshop admits it is a bug that they do not read gAMA and cHRM.

Finally even if it was true that no code reads it, the PNG spec requires to write fallback for ICC profiles and sRGB chunk, fallback being gAMA and cHRM.

[MasterQuestionable]

͏    Spec-compliance for non-sense..?

͏    Seriously I have significant doubt on the necessity of these things:
͏    Are their existence justifiable... except unnecessary complexity and bloat?
͏    (also the implied interoperability havoc)

[Balling]

Spec-compliance for non-sense..?

I am a purist in this sense. You should always follow spec, not thinking about HW campatibility, and other issues. But technically this cannot break anything. Because the specifications says that you should skip unknown chunks.

Also see #10000.

As for Adobe Photoshop, well, it is a bug. I am telling you... ​https://community.adobe.com/t5/photoshop-ecosystem-discussions/png-support-for-colour-profiles-incomplete-unpredictable-in-cc-2018/m-p/12810519/page/2

As for GIMP the bugs there were fixed: ​https://gitlab.gnome.org/GNOME/gimp/-/issues/3265

Same for Image Magik.

Are their existence justifiable.

Apple uses gAMA 1.8 back in 2000... You know...

[MasterQuestionable]

͏    That cannot be proved: what difference does it make from mere baseless assertions?
͏    .
͏    Standards established don't necessarily imply being well-designed:
͏    Blindly following without thinking shall regardless trap.

͏    [ Quote MasterInQuestion @ CE 2024-04-13 22:06:50 UTC:
​https://github.com/AOMediaCodec/iamf/issues/764#issuecomment-2053773784
͏    I wonder a question:
͏    How should all those sophisticated design be actually presented: when most devices have only Mono/Stereo speakers?.. ]
<.>    Skyscraper built on air..?

͏    [ Quote MasterQuestionable @ CE 2024-05-08 16:42:06 UTC:
​https://trac.ffmpeg.org/ticket/10891#comment:5
͏    ​https://streams.videolan.org/ffmpeg/incoming/10891/00006.MTS
͏    (~ 21.02 MiB; M2TS: H.264 (AVC) video, 11.044 s, 29.97 FPS, 1920x1080, YUV 4:2:0, ~ 19.57 MiB; A52/AC-3 audio, 11.072 s, 48,000 Hz, 346 KiB; ... ~ 1.11 MiB) ]
<.>    What does that pointless ~ 1.11 MiB do? (> 5% overhead)

͏    Thus why I didn't give it high priority: mostly as optimization.


͏    What about the interoperability havoc?
͏    The very White could never be the very White: exact display is display media dependent.
͏    .
͏    Making things to further differ when viewed with different applications... "counter-fix" perhaps.


͏    Perhaps of some use for those cannot be trivially losslessly re-encoded.
͏    But not the case for PNG.

͏    Note:
͏    Even losslessly captured: much of which are also unwanted noises.
͏    (that would be preferably filtered-out; or whose accuracy really doesn't matter)

[Balling]

That cannot be proved

Of course it can. Internet <archive> remembers everything. From people wanting to remove that chunk: ​https://stackoverflow.com/a/65880175/11173412

People complaing about it back in 2006 ​https://jonathannicol.com/blog/2006/12/01/fixing-png-gamma/

​https://hsivonen.fi/png-gamma/

PNG people providing tests for this: ​http://www.libpng.org/pub/png/colorcube/colorcube-pngs-iCCP.html

​https://pmt.sourceforge.io/gamma_test/index.html

Bugs still not fixed in png library that we do not use thankfully. ​https://github.com/pnggroup/libpng/issues/309

[Balling]

How should all those sophisticated design be actually presented: when most devices have only Mono/Stereo speakers?

By using binaural sound 2 speakers is enough, for wave modulation 4 speakers on a tablet you can create even an illusion that sounds come from the top. It is not hard anymore, what is hard is to have metadata that says how to extract sound and where does this sound move. That is what Dolby Atmos solves. And used everywhere, games, and what not.

[Balling]

What does that pointless ~ 1.11 MiB do?

That is a very hard question, as H.222 specification of TS (transpirt streams) and Blu-ray M2TS spec is very complex. But basically TS has nanosecond resolution, has PTS and DTS (DTS is decoding timestamps), and has to be inflated more to properly support all part of H.222. WE DO NOT SUPPORT THAT 100%, maybe 80%, that is a bug. That means that if you -c copy it using ffmpeg that bloat will decrease because null packets are no longer inserted "suboptimally". But that is a meme already: I always ask Kieran to fix this and he does not want to.

[MasterQuestionable]

͏    I mean the necessity of their existence.
͏    Similar are just post-filters essentially applied on decoding. (comparable to ͏"-vf")

͏    "... , what is hard is to have metadata that says how to extract sound and where does this sound move."
<^>    "how to extract sound": ?
͏    "where does this sound move": probably not metadata, but actual sound data.
͏    .
͏    IAMF much means how to transform sound data for representation under different contexts:
͏    Somewhat similar to the previous "The very White could never be the very White" predicament.


͏    All current container formats are sort of the similar problem:
͏    Unjustifiable complexity and bad primitives.
͏    .
͏    Designers probably did not well understand in advance: what video really is.

͏    See also: ​https://github.com/MasterInQuestion/talk/discussions/3

͏    Note:
͏    Try the ​`exiftool` command in ͏"Extra.txt" on "00006.MTS".
͏    So many so thoughtless things... so thoughtlessly piled-up the whole thing.

[Balling]

"I mean the necessity of their existence."

PNG without any chunks just is assumed to be sRGB... Not hard.

====

Atmos only has 5.1 or 7.1 channels. So when you decode you get 6 tracks in wav file or 8 tracks. Yet that is further decoded into 16 tracks and with ADM metadata that says how the sound moves around. Stegonography.

"probably not metadata, but actual sound data." It is text binary data (like what Android uses for binary xml in manifest.xml) that is just X, Y, Z coordinates and time.

"Unjustifiable complexity and bad primitives."

TS buffers are originally what is needed to move data between satellites. In space.

"Designers probably did not well understand in advance: what video really is"

The problem is not video (though if it is variable frame rate it is a big problem, actually), but audio. E.g. Dolby TrueHD has 1200 fps data. So every second you have 1200 frames.

[MasterQuestionable]

͏    Consider the following case:
͏    Generate a sample PNG using alike command there: ​https://trac.ffmpeg.org/ticket/10989
͏    Process which with `exiftool "-Gamma=200" "0.png" -o "1.png"`.
͏    Run `ffmpeg -hide_banner -nostdin -i "0.png" -i "1.png" -lavfi "ssim; [0][1]psnr" -f null -`. [ See also: #10924 ]
͏    .
͏    Now we have 2 visually distinct images: in fact identical.
͏    And displayed randomly across implementations...


͏    Again the similar aforementioned: "-af" this time.
͏    And the steganographic... Obfuscation?

͏    "originally" and proven unneeded bad design:
͏    Whose influence still propagated... unfortunate.

͏    Further explained in:
͏    ​https://github.com/MasterInQuestion/talk/discussions/3

[Balling]

Now we have 2 visually distinct images: in fact identical.

If you assign 2.0 gamma to image of 2.4 gamma and go outside in the Sun you get the correct image again. Because 2.4 gamma is what you get when you are in dark room, 2.2 when in light office and 2.0 outside uner the sun when you film the videos.

The same happens when you assign a ICC profile using iCCP chunk(s). Even in Photoshop — assign profile. It has Gamma 2.0 ICC too.

[MasterQuestionable]

͏    If we just feign to not see any difference at all everything becomes then correct.
͏    The point is not pointless debates alike but technical advancement.

͏    理不辨不明.
+    Reason cannot be discerned without discerning.

[Balling]

"If we just feign to not see any difference at all everything becomes then correct."

Indeed, bugs in our brain are certainly unfortunate. Probably fixable though, this is brain issue only, gray looks different depending to its surrounds, and thus gamma 2.4 would be equal 2.0 gamma in correct surroundings.

[MasterQuestionable]

͏    Whatever.
͏    I shall note the mentioned Gamma is 200: not 2.0.

[Balling]

Cannot log be approximated by gamma 100? Or do I remember it wrong?

[Balling]

YES! PQ iCCP profile requires the use of gAMA 15000: ​https://w3c.github.io/png-hdr-pq/

ICC profile is here: ​https://github.com/w3c/png-hdr-pq/tree/main/icc

How to read it: either ICC profile Inspector from color.org or part of skia cms from Google Chromium or the new ICCv5 (ICCmax) codebase.

[MasterQuestionable]

͏    `exiftool "-Gamma=200" "0.png" -o "1.png"`
͏    Merely a coined example demonstrating the failure:
͏    "displayed randomly across implementations"

[MasterQuestionable]

͏    Per spec-compliance invalid.
͏    While the validity of the spec itself remains much questionable.

[Balling]

This is already in use by mpv: ​https://github.com/mpv-player/mpv/issues/14377

You cannot do anything here.

[MasterQuestionable]

͏    "HDR PNG does not open"
<^>    Mostly irrelevant.
͏    HDR is metadata-like, I believe.
͏    FFmpeg may ignore and just decode, and just present whatsoever: like most other implementations.

͏    Regardless too many things wrong with the specs. (not only PNG)
͏    Perhaps need a through redesign.

[Balling]

Mostly irrelevant.

They use cICP. But sure.