Page 2 of 2

Re: orientation FUJI

PostPosted: Tue Mar 10, 2020 1:57 pm
by TheBrew
Should be fixed now. Try again please.

Re: orientation FUJI

PostPosted: Tue Mar 10, 2020 3:00 pm
by TheBrew
It's not super-duper important since I can reproduce it with the DPReview sample files.

I'm absolutely open to it being my code that needs an extra step that I'm missing (Apple's documentation is not always fully up-to-date so I'm a little excused.. ;)

So far I've been able to make it fail *only* when displayed by Webkit. So any emails or Safari on iOS or a Mac.

No issues in Xee, Pixelmator Pro, Finder's Preview or thumbnails, Firefox, Chrome, and even the little preview you get in the top left-hand corner when sharing in iOS.

My guess is that Webkit has some optimized-super-fast-reading-of-JPEGs that does something smart to avoid expensive reads/searches in the file to determine the orientation and pixel dimensions - and falls down somehow.

It seems crazy to me though. So I'm still trying to distill it down to a simple example that I can file to Apple as a bug-report. Maybe I'll find out that it was me all along but it's beginning to smell a little like Apple's Webkit. I'll post back when I know more.

Update: Well, Webkit reads the orientation and image dimensions correctly. It's the *drawing* that fails. Hm.
Update 2: Same on iOS 10, so I don't think it's a Webkit *bug*. More likely some very strict formatting of the JPEG that is missing or wrong that other apps don't use.

Re: orientation FUJI

PostPosted: Tue Mar 10, 2020 8:35 pm
by TheBrew
Alright. I'm pretty confident now that it's a Webkit bug (it assumes 1-4 orientations are landscape and 5-8 are portrait, which is not necessarily true).

But since a I'm also confident a bug report to Apple will be ignored, I think I've come up with a workaround for the next version of ShutterSnitch. Thanks for reporting this!