Exif orientation with LoadImage

[wilbert]

It looks like the exif orientation is not handled properly with LoadImage.
I have an image from my digital camera that is taken in portrait orientation, shows fine in OSX Preview but is in landscape orientation when PureBasic loads the image (90 degrees rotated compared to how it should look).

[infratec]

Hi wilbert,

I would not call this a bug.
The image is loaded as it is inside the file.
EXIF is only an addition.

It is not handled. Yes, that's true.
But I would call it a feature request and not a bug.

In IrfanView it is an option, which is disabled as default (if I'm right).

Bernd

[wilbert]

I think PureBasic should respect the Operating System it is working on.
I tried OSX Preview, Acorn image editor, Photoshop Elements, Safari, Chrome, Firefox (all on OSX) and every one of them handles the image orientation correctly. The only one which behaves differently is PureBasic.
The other applications probably all use the jpeg decoder built into OSX itself while PureBasic uses its own decoder.

[Wolfram]

I think Bernd is right.
EXIF is an addition, which you can read and use as you like.
Otherwise PB should read the color profile too, what is not does.

Did you try what's happened if you load it by cocoa?

[wilbert]

I think Bernd is right.
EXIF is an addition, which you can read and use as you like.
Otherwise PB should read the color profile too, what is not does.

Did you try what's happened if you load it by cocoa?

After some more thinking, you both do have a point. Maybe it should be a feature request.
I just was surprised the image didn't load correctly (from my point of view).

If I load it with Cocoa, the orientation is fine. So that's a good alternative.

[freak]

Moved to feature requests.

[AMpos]

LOADIMAGE has a 3rd unused parameter, #flag.

What about using it to auto rotate images?

If 0, load as is, if #PB_Image_Idontknow the loadimage function will autorotate the image using EXIF info.

[kenmo]

+1 as a flag, not the default.


wilbert, I have procedures that will handle this, if you want a workaround for now.

[AMpos]

Cool if you have this! Sent me a link, please.

[kenmo]

I did not realize this thread was 5 years old when I replied

AMpos, save my IncludeFiles RotateImage.pbi and GetExifData.pbi
https://raw.githubusercontent.com/kenmo ... eImage.pbi
https://raw.githubusercontent.com/kenmo ... ifData.pbi

and then try:

Code: Select all

XIncludeFile "RotateImage.pbi"
XIncludeFile "GetExifData.pbi"

LoadImageEXIFRotated(0, MyFile)

[BarryG]

The above includes don't work with this image -> https://www.dropbox.com/s/oe2sf7je8a8d1 ... d.jpg?dl=1

Note: Clicking the link will auto-download the file, because saving it from your browser will remove the EXIF data.

It fails to detect the orientation ("Right top" in EXIF data):

Code: Select all

XIncludeFile "RotateImage.pbi"
XIncludeFile "GetExifData.pbi"
Debug LoadImageEXIFRotated(0, "D:\Keyboard.jpg") ; Returns 0

However, LoadImage() loads it in the correct orientation:

[kenmo]

Hello @BarryG

There are two things going on here:

1. You are correct! My code had a bug in reading Little Endian encoded EXIF orientation. (Most of my test JPEGs are apparently Big Endian.)
I have pushed an update to GetExifData.pbi which should work. Don't forget UseJpegImageDecoder()
https://github.com/kenmo-pb/includes/bl ... ifData.pbi

2. PB's LoadImage() does not process EXIF orientation. What you're showing as "correct" has not been EXIF-rotated.
Try opening Keyboard.jpg in Firefox or Chrome or another pro software, you should see it rotated extra 90 clockwise.
My updated code should detect Keyboard.jpg needing a 90 CW rotation, matching Firefox etc.
I think it's confusing because the un-rotated PB result looks like the expected, natural orientation.