Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new PNG spec

programmax.net

Post reply on HN
Print view View original

611–620 of 622 posts

Re: A new PNG spec

#611

Post by chillingeffect »

pixl97 wrote: post #231
chillingeffect wrote: post #209

Earlier quoted context omitted.

Could it be a lack of resources? Or some missing expertise? Maybe they could find some interns who are familiar with it? Maybe the entire world is so obsessed w AI, we don't even care about image formats anymore.

Honestly this kind of stuff happens all the time in large companies. Interns won't want to work on a dead end like this. Moreso they need to be supervised by someone that doesn't want to get removed by being the lowest X% usefulness in a company. So all these existing tools that aren't primary revenue generators just sit on coast mode.

Thank you for the nice response... in contrast to those I deserved downvoting. You'ee alright.

Re: A new PNG spec

#612

Post by spider-mario »

cormorant wrote: post #365
LegionMammal978 wrote: post #4

Reading the linked blog post on the new cICP chunk type [0], it looks like the "proper HDR support" isn't something that you couldn't already do with an embedded ICC profile, but instead a much-abbreviated form of the colorspace information suitable for small image files. [0] https://svgees.us/blog/cICP.html

"common but not representable RGB spaces like Adobe 1998 RGB or ProPhoto RGB cannot use CICP and have to be identified with ICC profiles instead." cICP is 16 bytes for identifying one out of a "list of known spaces" but they chose not to include a couple of the most common ones. Off to a great start... I wonder if it's some kind of legal issue with Adobe. That would also explain why EXIF / DCF refer to Adobe RGB only…

CICP (H.273) originates from the video world, where Adobe RGB and ProPhoto RGB really aren’t common.

Re: A new PNG spec

#613

Post by illiac786 »

colejohnson66 wrote: post #363
liuliu wrote: post #349

Earlier quoted context omitted.

JPEG XL has the mode that in layman's word, allow bit-by-bit round-trip with JPEG. Original JPEG -> JPEG XL -> Recreated JPEG. Sha256(Original JPEG) == Sha256(Recreated JPEG). That's what people meant by "backward compatible".

That’s not “backwards compatible”, but “round tripable” or “lossless reencode”

exactly, it is absolutely not backward compatible. It is lossless-at-bit-level conversion of JPEG, but that doesn’t help older SW in any way.

Re: A new PNG spec

#614

Post by zirgs »

mrheosuper wrote: post #474
zirgs wrote: post #124

Earlier quoted context omitted.

Yeah - it's a mess. Some devices only charge with a charger that supports PD. Some other devices need a charger WITHOUT PD support.

If those devices follow the spec, they dont need charger without PD support. You don't follow spec, you're on your own.

Yes, but, unfortunately - devices like that exist.

Re: A new PNG spec

#615

Post by spider-mario »

joking wrote: post #166
mavhc wrote: post #108

Earlier quoted context omitted.

Because your non-smartphone camera doesn't have enough ram/speed to do that I assume (when in burst mode) If a smartphone camera is doing it, then bad camera app!

the main reason is probably that the chip is already outputting the image in a lossy format, and if you reorder the pixels you must reencode the image which means degrading the image, so it's much better to just change the exif orientation.

JPEG can be rotated losslessly. `jpegtran` can do it, for example (and comes with a script called `exifautotran` to automatically normalise the orientation of a bunch of JPEG files at once).

Re: A new PNG spec

#616

Post by spider-mario »

dylan604 wrote: post #573
account42 wrote: post #526

Earlier quoted context omitted.

Yes the whole point of lossless re-compression is that you do not need to keep the original JPEGs. Of course you don't need to "purge" backups, just let them rotate out normally. Also backup storage is usually cheaper than something that needs to have fast access speeds.

For people that shoot digital cameras saving as JPEG, it will a very cocky suggestion to tell them to toss out their camera original files! You'll know JPEG-XL if real when camera manufactures allow for XL acquisition instead of legacy JPEG only.

> For people that shoot digital cameras saving as JPEG, it will a very cocky suggestion to tell them to toss out their camera original files!

But they can recover them from the JXL files, so are they really “tossed out”? It’s not really different than any other form of lossless compression.

Re: A new PNG spec

#617

Post by spider-mario »

LegionMammal978 wrote: post #448
ProgramMax wrote: post #424

Earlier quoted context omitted.

PNG previously supported ICC v2. That was updated to ICC v4. However, neither of these are capable of HDR. Maybe iccMAX supports HDR. I'm not sure. In either case, that isn't what PNG supported. So something new was required for HDR.

> However, neither of these are capable of HDR. How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright". Unless HDR support is supposed to be something other than just the primaries, white point, and transfer function. Al…

> How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright".

That’s precisely what makes it unsuitable for HDR. With PQ, (1, 1, 1) means 10 000 cd/m² – if you simply create an ICC profile with the PQ transfer function, an image that looks right on a hypothetical 10 000 cd/m² monitor will look way too dim when naïvely scaled down (as ICC-type colour management would have you do) to the 300 cd/m² of a typical monitor. HLG, meanwhile, has a transfer function that depends on the peak luminance, which is not possible to do with ICC (the profile would have to assume a specific peak luminance), and the reason that it does that is to preserve the subjective perception of the image.

So, sure, you can prepare an HDR image so that it looks right on a monitor with a 1000 cd/m² peak luminance, describe the colorspace in relative terms using an ICC profile, and you will have “done HDR using ICC”, but that’s arguably a very low bar for “supporting HDR”.

Re: A new PNG spec

#618

Post by spider-mario »

Aachen wrote: post #221
qwertfisch wrote: post #202

Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy and lossless compression, animated pictures, HDR, EXIF etc. There is just no need for a PNG update, just adopt JPEG XL.

> advanced compression (finite-state entropy, like ZStandard) I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will nev…

JPEG XL is not “apply zstd to the pixel data”. What the parent comment meant is that JPEG XL, like zstd, happens to use ANS among its set of techniques. It handles gradients just fine.

Re: A new PNG spec

#619

Post by virtualritz »

Mr_Minderbinder wrote: post #483
virtualritz wrote: post #109

Earlier quoted context omitted.

There is nothing in display hardware today that TIFF couldn't handle already. For example 16bit (integer) TIFF files 'with headroom', i.e. where some bits were used to represent data over 1.0 (HDR) was a common approach for VFX work in the 90's. 16bit float TIFF is also thing since 33 years. Adobe DNG is modeled after TIFF. High end offline renderers have traditionally been using TIFF (with mip-maps) to store texture…

> The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics. > And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today. What does it say? That they are naive or have the wrong priorities? Their rationale for this seems quite reasonable to me: https://…

You can't represent additive pixels (i.e. glowing pixels) with non-associated alpha. That's why this is used in exactly zero image processing software, internally.

E.g. an associated pixel with the 8bit/channel RGBA value 255, 0, 0, 0 (glowing red).

Because PNG can only store associated data a reader must associate before displaying. And that will give you a value of 0, 0, 0 after (black instead of additive red). See e.g. [1] why this matters.

Additionally the PNG spec does not specify if the alpha is linear. Some PNG readers/writer assume it is, some assume it has gone through/should go through an sRGB transfer curve instead. It mostly works until it doesn't.

The fact that the spec. doesn't specify which one it should be is another telltale sign that it was written by people unaware of the subtleties of image processing.

I understand that unassociated alpha gives you more precision in 8bit and since people wanted to e.g. store color ramps (with alpga) in PNG at the time (pre-SVG) and most image processing software (i.e. mainly Photoshop then) would not dither gradients for 8bit, this really mattered.

But it's 2025. And when 16bit PNG got introduced this should have definitely had associated (and explicitly linear) alpha.

[1] https://academysoftwarefdn.slack.com/archives/C05782U3806/p1...

Re: A new PNG spec

#620

Post by Mr_Minderbinder »

virtualritz wrote: post #619
Mr_Minderbinder wrote: post #483

Earlier quoted context omitted.

> The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics. > And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today. What does it say? That they are naive or have the wrong priorities? Their rationale for this seems quite reasonable to me: https://…

You can't represent additive pixels (i.e. glowing pixels) with non-associated alpha. That's why this is used in exactly zero image processing software, internally. E.g. an associated pixel with the 8bit/channel RGBA value 255, 0, 0, 0 (glowing red). Because PNG can only store associated data a reader must associate before displaying. And that will give you a value of 0, 0, 0 after (black instead of additive red). See…

> See e.g. [1] why this matters.

Quote the relevant section, Slack requires a log-in.

> Additionally the PNG spec does not specify if the alpha is linear.

Section 12.1 of the PNG spec seems to specify exactly that: “gamma does not apply to alpha samples; alpha is always represented linearly.”

Post reply on HN