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

561–570 of 622 posts

Re: A new PNG spec

#561

Post by Andrex »

IvanK_net wrote: post #436
giancarlostoro wrote: post #422

Earlier quoted context omitted.

> Macromedia did this when saving Fireworks files into PNG. I forgot about this.. Fireworks was my favorite image editor, I don't know that I've ever found one I love as much as I loved Fireworks. I'm not a graphics guy, but Fireworks was just fantastic.

BTW. I am the author of https://www.photopea.com , which is the only software that can open Fireworks files today :D If you have any files, try to open theim (it runs instantly in your browser). https://community.adobe.com/t5/fireworks-discussions/open-fi...

Proud paid Photopea user here. I can't understand how you guys overcame my mountain of incredulity but you have saved my ass so much. I was literally looking into dual booting before I found your product.

(Not many things handle .ai so well either!!)

Re: A new PNG spec

#562

Post by kllrnohj »

account42 wrote: post #508
kllrnohj wrote: post #305

Earlier quoted context omitted.

For anything GPU-rendered, applying a rotation matrix to a texture sample and/or frame-buffer write is trivially cheap (see also why Vulkan prerotation exists on Android). Even ignoring GPU-rendering, you always are doing a copy as part of rendering and often have some sort of matrix operation anyway at which point concatenating a rotation matrix often doesn't change much of anything.

The cost is paid in different memory access patterns which may or may not be mitigated by the GPU scheduler. It's an insignificant cost either way though, both for the encoder and the renderer. Also depending on the pixel order in sensor, file or frame buffer "rotated" might actually be the native way and the default is where things get flipped around from source to destination.

Access pattern is mitigated by texture swizzling which will happen regardless of how it's ultimately rendered. So even if drawn with an identity matrix you're still "paying" for it regardless just due to the underlying texture layout. GPUs can sample from linear textures, but often it comes with a significant performance penalty unless you stay on a specific, and undefined, path.

Re: A new PNG spec

#563

Post by georgyo »

allendoerfer wrote: post #496
georgyo wrote: post #188

Earlier quoted context omitted.

File extensions are just a hint about what the file might be and have nothing to do with what the file actually is. If the server sets the MIME type, the browser will use that as the hint. But even beyond that, most file formats have a bit of a header at the start of the file that declares the actual format of the file. Browsers already can understand that and use the correct render for a file without an extension.

What if the user wants to use the file outside the browser, where they do not have access to the HTTP headers?

The same is true, if you rename a .png to .jpg and opening it with an image viewer, it will render.

Re: A new PNG spec

#564

Post by HakanAbbas »

account42 wrote: post #505
HakanAbbas wrote: post #384

Earlier quoted context omitted.

I don't really understand what the new PNG does better. Elements such as speed or compression ratio are not mentioned. Thanks also for your kind thoughts ksec. Apart from the widespread support in codecs, there are 3 important elements: processing speed, compression ratio and memory usage. These are taken into account when making a decision (pareto limit). In other words, the fastest or the best compression maker alo…

> In other words, the fastest or the best compression maker alone does not matter. Strictly true, but e.g. for archival or content delivered to many users compression speed and memory needed for compression is an afterthought compared to compressed size.

Storage is cheaper than it used to be. Bandwidth is also cheaper than it used to be (though not as cheap as storage). So high quality lossy techniques and lossless techniques can be adopted more than low quality lossy compression techniques. Today, processor cores are not getting much faster. And energy is still not cheap. So in all my work, processing speed (energy consumption) is a much higher priority for me.

Re: A new PNG spec

#565

Post by Nopoint2 »

account42 wrote: post #499
Nopoint2 wrote: post #487

Earlier quoted context omitted.

I never realized how limited sRGB is. I guess this is why people liked CRT TVs, and why you could never watch analog TV properly on a PC screen.

It's really not that limited, the problem is only if you reinterpret a larger gamut as sRGB without doing the proper conversion where things look washed out.

That's what I thought too, but the difference is big. You'd think you maybe lose some color lights, or very bright flowers, but no, colors outside sRGB are common.

There was nothing you could do about the TV, the screen couldn't show all the colors that you needed.

Re: A new PNG spec

#566

Post by boogerlad »

HakanAbbas wrote: post #564
account42 wrote: post #505

Earlier quoted context omitted.

> In other words, the fastest or the best compression maker alone does not matter. Strictly true, but e.g. for archival or content delivered to many users compression speed and memory needed for compression is an afterthought compared to compressed size.

Storage is cheaper than it used to be. Bandwidth is also cheaper than it used to be (though not as cheap as storage). So high quality lossy techniques and lossless techniques can be adopted more than low quality lossy compression techniques. Today, processor cores are not getting much faster. And energy is still not cheap. So in all my work, processing speed (energy consumption) is a much higher priority for me.

You're right, but aren't you forgetting that for each image, the encode cost needs to be paid just once, but the decode time must be paid many many times? Therefore, I think it's important to optimize size and decode time.

Re: A new PNG spec

#567

Post by cratermoon »

ProgramMax wrote: post #443
fwip wrote: post #440

Earlier quoted context omitted.

Do you have any examples on hand of PNGs that use the new features of the spec? It would be cool to see a little demo page with animated or HDR images, especially to download to test if our programs support them yet.

Sure! Chris Lilley--one of the original PNG co-authors--has a post with an example HDR image: https://svgees.us/blog/cICP.html It is about half way down, with the birthday cake. Generally, us tech nerds have phones that are capable of displaying it well. So perhaps view the page on your phone. What you should look for is the cake, the pink tips in her hair, and the background being more vivid. For me, the pink in the…

I can see a clear difference between the images in Firefox on MacOS with my M1 macbook. Very nice.

Re: A new PNG spec

#568

Post by naikrovek »

dspillett wrote: post #524
naikrovek wrote: post #228

Earlier quoted context omitted.

When someone makes a baby, you call that person by their real name with the correct pronunciation, don’t you? So why can’t you do that with GIF or PNG? People that create things get to name them.

There is a huge difference between inanimate objects/classes and babies. Don't personify inanimate objects, they hate that! On inanimate objects: Aluminium was first ratified by the IUPAC as aluminium⁰, with the agreement of its discoverer Sir Humphrey Davy¹, yet one huge nation calls it something else… On people: nicknames are a thing, are you saying those are universally wrong? But yes, when a person tells me that…

Let people name their offspring, both biological and technical.

Re: A new PNG spec

#569

Post by spider-mario »

ksec wrote: post #431
illiac786 wrote: post #312

Earlier quoted context omitted.

I would agree we will see less improvements that when comparing modern jpeg implementation and the reference one. When it comes to hardware encoding/decoding, I am not following your point I think. The fact that some are already looking at hardware implementation for JPEG XL means that….? I just know JPEG hardware acceleration is quite common, hence I am trying to understand how that makes JPEG XL different/better/wo…

In terms of PC usage, JPEG, or most image codec decoding are done via software and not hardware. AFAIK even AVIF decoding is done via software on browser. Hardware acceleration for lossless makes more sense for JPEG XL because it is currently very slow. As the author of HALIC posted some results below, JPEG XL is about 20 - 50x slower while requiring lots of memory after memory optimisation. And about 10 - 20 times s…

Lossless JPEG XL encoding is already fast in software and scales very well with the number of cores. With a few cores, it can easily compress 100 megapixels per second or more. (The times you see in the comment with the DPReview samples are single-threaded and for a total of about 400 MP since each image is 101.8MP.)

Re: A new PNG spec

#570

Post by LegionMammal978 »

ProgramMax wrote: post #488
LegionMammal978 wrote: post #478

Earlier quoted context omitted.

That doesn't sound quite right to me. ICCv2's 'curveType' gives the option of a full lookup table instead of a simple gamma function. Maybe it has to do with ICCv2 saying that the reference viewing condition has an illumination level of 500 lx for the perceptual intent? (But how does that apply to non-reflective media?) I don't doubt that there's lots of problems in the chain from RGB samples to display output, but I…

Agreed that it gets confusing. That's a piece of why I'm unable to give you a solid answer. This isn't my area of expertise. Here is what I can tell you confidently: The original plan was to provide an ICC profile that approximates PQ as best as we could. But it wasn't enough. So the proposal was to force the profile name to be a special string. When a PNG decoder saw that name, it would ignore the ICC profile and do…

Thanks for that proposal link. The email thread starting at [0] seems to explain some of the challenges. My understanding:

- In ICC-land, all luminances are relative to the display's (or reflective medium's) black and white points. So for an HDR-capable display, all content, HDR or SDR, would be naturally displayed at the full 10k nits or whatever the actual number is. This is obviously not how things work in practice: OSes and/or displays really want a signal as to whether the full HDR luminance is actually desired. (This reminds me of an earlier HN thread where people complained about HDR video forcing up the brightness on Apple devices.)

- PQ (but not HLG) specifies everything in terms of absolute luminance, but this gets confusing when people want to adjust their display brightness and have everything work relatively in practice.

- Due to lack of support for "overrange" behavior [1], 1D LUTs + matrices are insufficient for representing PQ at all, so you need a 3D LUT just to approximate it. This needs ICCv4, since ICCv2 only supports 3D LUTs for non-display profiles.

- But 3D LUTs are big and fat, and can only give a few bits of accuracy across some parts of the full HDR range. (It seems like there's no form of delta compression?) Most people really hate this. iccMAX can allegedly use 3D parametric formulas, but literally no one implements it since it has a million bells and whistles.

- More importantly, GPUs especially hate big fat LUTs, and everyone uses GPU rendering. In the worst case, some implementations will do everything they can to ignore LUTs in ICC profiles, and instead try to guesstimate some simple-gamma or linear-gamma approximation, which won't end well.

So it does seem to be a combination of "the HDR stack is a mess and needs its own special signaling" and practical concerns about avoiding overly huge profiles.

[0] https://lists.w3.org/Archives/Public/public-colorweb/2017May...

[1] https://lists.w3.org/Archives/Public/public-colorweb/2017May...

Post reply on HN