This is the first time I’ve seen HDR used to refer to wider color spaces and not extended brightness and contrast ratios.
A new PNG spec
461–470 of 622 posts
Re: A new PNG spec
#462> Officially supports Exif data Probably the best news here. While you already can write custom data into a header, having Exif is good. BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.
There is an acceleration field (Exif.Photo.Acceleration) and (Exif.Photo.CameraElevationAngle) for elevation but oddly not 3 axes. Similarly there are fields for ambient environmental conditions, but only whatever specific things the spec-writers considered.
You could store this in Exif.Photo.MakerNote: "A tag for manufacturers of Exif writers to record any desired information. The contents are up to the manufacturer." I think it can be pretty big, certainly more than enough for 9 DoF position data.
Re: A new PNG spec
#463Earlier quoted context omitted.
The stupid thing is that any device with an orientation sensor is still writing images the wrong way and then setting a flag, expecting every viewing application to rotate the image. The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.
> The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF. The hardware likely is optimized for the common case, so I would think that can be a lot slower. It wouldn’t surprise me, for example, if there are image sensors out there that can only be read out in top to bottom, left to right order. Also, wit…
At this point I expect any camera ASICs to be able to incorporate this logic for plenty-fast processing. Or to do it when writing out the image file, after acquiring it to a buffer.
Your raw-image idea is interesting. I'm curious as to how photosites' arrangement would play into this.
Re: A new PNG spec
#464Earlier quoted context omitted.
TIL, and hard agree (on face value). I’ve been struck by this with arbitrary rotation of images depending on application, very annoying. What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.
> What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary. Performance. Rotation during rendering is often free, whereas the camera would need an intermediate buffer + copy if it's unable to change the way it samples from the sensor itself.
Given that rotation sensors have been standard equipment on most cameras (AKA phones) for many years now, I would expect pixel-reordering to be built into supporting ASICs and to impose negligible performance penalties.
Re: A new PNG spec
#465Earlier 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.
Image sensors don't "output images in a lossy format" as far as I know.
Re: A new PNG spec
#466> I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files. It'll be like USB-C but for images.
Worry not! (Well, worry a little.) The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?" Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option. Here's the worry-a-little part: Ever…
My strong vote is to just not touch it. Stability is a feature.
Re: A new PNG spec
#467A fun fact about PNG, the correct pronunciation is defined in the specification > PNG is pronounced “ping” See the end of Section 1 [0] 0: https://www.w3.org/TR/REC-png.pdf
Pronouncing it like that would invite confusion as the word ping is often used in messaging.
let's propose PENJ to avoid the confusion.
Re: A new PNG spec
#468Time is ripe for audio-included animated PNG files.
Re: A new PNG spec
#469Earlier quoted context omitted.
Strangely, I was familiar with AIFF and RIFF files but never made the connection that they're both IFF. I hadn't known about IFF before your post. Thank you :) W3C requires that we do not break old, conformant specs. Meaning if the next PNG spec would invalidate prior specs, they won't approve it. By extension, an old, conformant program will not suddenly become non-conformant. I could see a group of people formalizi…
They pretty much say the same thing halfway through. Don't change PNG but adapt IFF to work with PNG's flavour of IFF.
Right. Sorry, that was supposed to be a "yes, and..." to provide some additional context.
Re: A new PNG spec
#470This is the first time I’ve seen HDR used to refer to wider color spaces and not extended brightness and contrast ratios.
Yeah. I mentioned this elsewhere but repeating here:
I designed the article to be accessible and understandable for the average person. So I took some liberties like showing only HDR primaries and not deep diving into HDR transfer functions. People understand the primaries intuitively.
But you are right that a wide color image could also use those same primaries without being HDR.
My goal was to be as truthful as possible while still being digestible at a glance.
In the article, I linked to Chris Lilley's post which explains it more thoroughly for the technical people.