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

EXIF orientation info in PNGs isn't used for image-orientation: from-image

bugzilla.mozilla.org

Post reply on HN
Print view View original

71–80 of 91 posts

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#71

Post by taeric »

LeifCarrotson wrote: post #70
taeric wrote: post #63

Earlier quoted context omitted.

Isn't it a touch on the required side, though? I'm assuming the orientation is a common metadata element of phone produced images, in particular. I'd assume same for decent cameras. Would love to see a good rundown of when you should rely on different approaches? Another thread pointed out that you should also use the color space metadata.

Some systems seem to produce images where the pixel arrangement matches the sensor layout, which moves when you rotate the device, and they'll add EXIF metadata to indicate the orientation. Other cameras and phones and apps produce images where the device adjusts the aspect ratio and order of the array of pixels in the image regardless of the way the sensor was pointed, such that the EXIF orientation is always the de…

The advantage of the EXIF approach is you don't have to do nearly as much post processing of the data? In particular, I don't expect my camera application to need to change memory layout just because I have rotated my camera. So, if you want it to change the rows/columns on saving the image, that has to be post capture from the sensor. Right?

I think this is what you meant by "some systems" there. But, I would expect that of every sensor system? I legit never would have considered that they would try the transpose on saving the image off the sensor.

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#73

Post by moron4hire »

Avamander wrote: post #10
moron4hire wrote: post #4

Earlier quoted context omitted.

I firmly believe every product team needs to be split in two: one half works on the issue of highest importance, the other works on the easiest issues. If only to avoid the embarrassment of easy to fix bugs that were passed over for eons just because they weren't priority-high.

I don't this makes business sense in general. I do however think that there are quite a few bugs that might be triaged as "easy" but if worked on would reveal much more serious problems. Which is why some random selection of "easy" issues should make it to work queues.

The business sense! Would someone please think of the business!

I've yet to find a business that really, truly knows what it wants. Whatever is "good for the business case" today could change overnight after the President reads some cockamamie article in Harvard Business Review, and again in two weeks after the CEO spends a weekend in Jackson Hole.

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#74

Post by tehjoker »

rkagerer wrote: post #54

Orientation in EXIF was an ugly hack and we're living with its fallout today. Cameras should have just rotated the actual image pixels when saving, instead of cheating. If that's too slow, implement it in hardware, or schedule a deferred process and don't let the images be exported until that's done.

Eh, the coordinate frame can really be anything. It's important to disambiguate what is really meant. The convention in images is that images are +X-Y, but for certain applications, the PNG may represent data that is +X+Y, or mirrored -X+Y, landscape, or portrait. Is the coordinate system the camera coordinates or the world coordinates?

It's true that automatic handling of all input images is difficult, but imo it's important to document.

An example I recently encountered is that in neurological imaging, the axes are patient's right, anterior, superior whereas in radiology they are patient's left, anterior superior. Tricky to get right...

http://www.grahamwideman.com/gw/brain/orientation/orientterm...

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#75

Post by drittich »

Linkd wrote: post #28
mzur wrote: post #26

Browsers starting to rotate images based on EXIF is such a pain. I maintain an image annotation tool and all of a sudden images were shown differently to users depending on the browser they used. Then you have to jump through all sorts of hoops to ignore the EXIF orientation again. In some cases you are not allowed to see if the orientation was changed for security reasons. And then the only way to control this is th…

The amount of time I've spent dealing with this over the years is just incredible.. It's gotten to the point where during ingestion we auto-rotate everything just in case and strip out exif orientation metadata and never have to deal with it again.

Yes, came to the same conclusion - it's a pain, but solves the problem permanently.

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#76

Post by viraptor »

qwertyuiop12 wrote: post #72

I don’t know “why”. Why the format defines a way to set the orientation instead of set a pixels matrix as it is.

It's setting one bit vs transforming each block with potential further loss of precision.

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#77

Post by gpvos »

donatj wrote: post #6

Interesting. I was not aware that was a thing. Orientation info seems way less useful in a lossless format like PNG. It makes sense in JPEG for instance because rotating and re-encoding would be lossy and slightly degrade the image.

JPEGs can be rotated losslessly as long as their size is a multiple of eight (or to be pedantic, the block size, which is usually eight).

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#78

Post by lxgr »

OptionOfT wrote: post #65
rkagerer wrote: post #54

Orientation in EXIF was an ugly hack and we're living with its fallout today. Cameras should have just rotated the actual image pixels when saving, instead of cheating. If that's too slow, implement it in hardware, or schedule a deferred process and don't let the images be exported until that's done.

> Cameras should have just rotated the actual image pixels when saving, instead of cheating. If that's too slow, implement it in hardware, or schedule a deferred process and don't let the images be exported until that's done. What if I want to rotate an image by 90 degrees because my camera didn't correctly detect up & down? To my understanding rotation is lossless, where as moving the data will incur quality loss (e…

JPEG rotation can be lossless for certain image dimensions (multiples of 8 or 16 pixels respectively, depending on chroma subsampling).

I suppose it's no coincidence that the native output format of many sensors (or ISPs, to be precise) is divisible by 16 in both width and height.

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#79

Post by lxgr »

tehjoker wrote: post #74
rkagerer wrote: post #54

Orientation in EXIF was an ugly hack and we're living with its fallout today. Cameras should have just rotated the actual image pixels when saving, instead of cheating. If that's too slow, implement it in hardware, or schedule a deferred process and don't let the images be exported until that's done.

Eh, the coordinate frame can really be anything. It's important to disambiguate what is really meant. The convention in images is that images are +X-Y, but for certain applications, the PNG may represent data that is +X+Y, or mirrored -X+Y, landscape, or portrait. Is the coordinate system the camera coordinates or the world coordinates? It's true that automatic handling of all input images is difficult, but imo it's…

> Eh, the coordinate frame can really be anything.

Well, in JPEG, there's exactly one coordinate frame in the absence of EXIF metadata: Left to right, top to bottom. So there's really only one.

Re: EXIF orientation info in PNGs isn't used for image-orientation: from-image

#80

Post by aidenn0 »

ziml77 wrote: post #59
postalcoder wrote: post #14

As a former metadata completionist, my mind starts to dissociate when I think about my battles with EXIF metadata, vendor-specific metadata, and the way different software supports, or refuses to support, any of it. It gets even worse when ingesting images into Apple Photos, where you have to confront papercut bugs that you know will never be fixed. I love ExifTool. It’s one of the great utilities. It works for almos…

I've been trying to create clean metadata for a collection of Blu-ray rips recently. The MKV format has a bunch of defined metadata fields but handling of it is inconsistent between players. VLC seems to be the worst in that it doesn't even bother displaying important pieces of the metadata. You can work around that by effectively duplicating the important parts in the track name, but then other software ends up doub…

> And I'm being driven crazy on how I should use the subtitle track flags that indicate if a track is Forced or Default, because it seems like the auto-selection behavior based on those flags arbitrary from player to player.

Oh, this seems to be more or less completely ignored when selecting subtitles, though some players will at least list "English (forced)" or "English (default)" &c. when selecting a subtitle. Quite a pain with dubbed foreign-films when the subtitles are used for translating on-screen text; you really want the forced subtitle in that case!

Post reply on HN