SkiaSharp: SkEncodedOrigin wrong for one JPEG but not another - why?
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.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 26 (14 by maintainers)
Commits related to this issue
- Add support for reading the Exif SubIFD Fixes #1517 — committed to mono/SkiaSharp by mattleibow 4 years ago
- Add support for reading the Exif SubIFD (#1518) Fixes #1517 — committed to mono/SkiaSharp by mattleibow 4 years ago
Awesome! I’ll merge them and try get a release out asap!
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!
I have the fix building, and I have also reported it to Google: https://bugs.chromium.org/p/skia/issues/detail?id=10799
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.
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.