Skiasharp: SkEncodedOrigin wrong for one JPEG but not another - why?

[Webreaper]

I have two images (attached) which I'm trying to load, orient correctly, and then resize/crop to make thumbnails. My code to load the codec is super simple (I haven't included the code to resize and rotate, but can do if appropriate):

            SKCodec codec = SKCodec.Create(source.FullName);
            SKImageInfo info = codec.Info;

When I load the code via the Codec, the origin is coming back as 'Default' (TopLeft) for P8211052.JPG, which means that my resized thumbnails are not rotated correctly. However, for PA010741.JPG, the origin is correct, so my rotation code works as expected.

I'm struggling to see what the difference is between the two images; both were taken on an Olympus OMD-EM5 Mk2. If I use other image processing libs to do the same thing (e.g., the AutoOrient method in ImageSharp) it works fine - and the photos display correctly-oriented in MacOS Preview. So I'm wondering if there's either something odd about the photos, or a bug in the Codec (which seems less likely, being JPEG). Any ideas?

I could use ImageSharp - which works - but SkiaSharp can process the thumbnails about 4-6x as fast, which is important as I'm processing hundreds of thousands of images in my app.

P8211052.JPG.zip
PA010741.JPG.zip

[mattleibow]

Very interesting...

I opened both in Windows Photos app, they are upright. But, when I open them in IrfanView, one is on its side.

But what is even more interesting is that they both have the orientation, but it seems a different order...

When I open it with GIMP, the one that is upright has a popup saying that it contains EXIF metadata. But the other one does not.

I'll see what I can do. Hopefully it is just a matter of different EXIF data that maybe skia is struggling to load.

[Webreaper]

Yes, I wondered if it might be a small glitch in the exif code. Let me know what you find and if you want me to test anything!

[mattleibow]

All right. I managed to locate the issue.

What is happening is that the EXIF data is not is the usual location. As a result, there is a special entry in the tags to point to the correct location of the data. However, skia is not actually handling this case. Instead, it stops with the initial set of tags, which is just a pointer to the real data.

I'll get a fix in and then report this to the Google team so that is can reach upstream.

[Webreaper]

That's totally awesome. Thanks for the super quick response!

[mattleibow]

I have the fix building, and I have also reported it to Google: https://bugs.chromium.org/p/skia/issues/detail?id=10799

[mattleibow]

@Webreaper, I have _just_ pushed the PR build to the preview feed. It would be great if you were able to check it out and see if it works for all your images that you can test on. I want to make sure I got all the cases. I think it should be good, but won't hurt to confirm.

Preview feed: https://aka.ms/skiasharp-eap/index.json
Exact version: 2.80.3-pr.1518.1

[Webreaper]

Will certainly give it a go - how do I use the preview feed...?
Edit: never mind, figured it out - will let you know :)

[Webreaper]

Built a new version using 2.80.3-pr.1518.1, and it's working perfectly. I see no images mis-oriented. Thanks for the quick fix!

[mattleibow]

Awesome! I'll merge them and try get a release out asap!

[Ziriax]

Nice!

Would it be possible to apply this patch to 1.68.3 too?

PS: Related, I find it very unfortunate Skia doesn't provide a full blown metadata API, like Windows Imaging Component does.

[mattleibow]

I can try see if CI can build v1 again, but I am not sure if it will actually be good.

Skia is more creation than reading, so I think they decided to not put as much effort into the codecs.

[mattleibow]

I have created a CR that probably will get merged: https://skia-review.googlesource.com/c/skia/+/323217

I'm going to wait for feedback form the experts and then use whatever the final result is as this fix.

[Webreaper]

Any timescales for when a new release with this fix is going to be made?