[Imatch 2021] Imatch displays jpg:s in portrait orientation as landscape

[Joakimst]

Hi,

I have a problem that when I export my edited raw images, shot in portrait mode, from lightroom, they are displayed with a 90 degrees rotation in Imatch. The original raw file is however displayed correctly. In every other application (that I've tried to open the image in) the jpg is displayed correctly though. If I use the "virtually rotate" function in Imatch the jpg is displayed correctly in Imatch but if I then try to open the image in any other application the image is rotated 90 degrees. And if I then rotate the image in the other application (i.e. windows photo) it is then displayed incorrectly in Imatch again.

This only happens to images shot in portrait orientation. Images shot in landscape orientation are displayed correctly. Is there a setting I'm unaware of or is this a bug?

If it matters my camera is a Nikon Z6i.

[Mario]

IMatch respects the EXIF orientation information in the image.
When you look at the orientation in the Metadata Panel (use the "Browser" layout and search for orientation), what does it show?

Maybe Lr copied the EXIF data unmodified from the RAW, including the original orientation info (which does not match the JPEG anymore?)

[Joakimst]

Thanks for the reply!

I've done some more testing and I need to take back my initial comment because I had identified the wrong problem. I still have a problem though.

It turns out lightroom for some reason is not including the exif orientation tag when exporting images. An explanation is given here, though I don't think I fully understand why though: https://community.adobe.com/t5/lightroom-classic/why-does-lr-classic-not-set-exif-orientation-tag-even-removes-it/m-p/10762929#M166156

If I open the exported jpg in windows photo viewer the image is displayed correctly in portrait orientation. The problem is that when the jpg is imported into Imatch the exif orientation tag ("270 degrees CW") is propagated from the raw file. If I change the exif orientation of the jpg to "Normal (Horizontal)" the raw and jpg files are displayed correctly in Imatch and in other applications. However if I do any changes like adding keywords and writing metadata to the raw file the exif orientation tag is changed back and the image is displayed incorrectly again.

However in the file version settings about what to propagate I haven't checked any boxes about exif data. And it seems like much more is propagated than the orientation tag.

The propagate boxes I have checked are:
Attributes
Bookmarks
Flag
Dot
Pins
Rating
Label
XMP without Camera Raw data
Don't copy XMP Regions
Classic IPTC Data

[JohnZeman]

Assuming you're using file relations for your raw and jpg files (like I am) I've learned to check the box to not copy orientation from my raw masters to my jpg versions.  Before I did that I had the same problem as you, since changing it to not copy orientation everything has been fine.

[thrinn]

If the orientation is indeed set through your File Relation versioning rule, and if this is the reason for the wrong orientation, you might want to check the "Don't copy XMP orientation" option. I do not have your setup, so I can only guess, but it sounds that this option might help in your specific case.

[Stefanjan]

Coincidentally I have just been through rotating a load of portrait .RW2 shots taken on my Panasonic TZ200 (ZS200).

Sounds like this might be related to the original issue in this thread so I have taken a number of test shots.

I copied these in Windows with a folder open in IMatch. Made no changes at all in any applciation. All the portrait shots are incorrectly rotated to the right in IMatch, the EXIF is showing "Rotate 270 CW". The landscape shots are correct "Horizontal Normal".

I have viewed the same folder in FastRawViewer, ON1, Dark Table and DXO Photolab 4. All show the correct rotation for portrait images in the test folder from my Panasonic.

Did the same test with my Canon 80D and the .CR2 files are displayed correctly in IMatch

Incidentally I also noticed that if I rotate one of the incorrectly rotated images to the left and then to the right it ends up upside down rather than the original position.

[Joakimst]

If the orientation is indeed set through your File Relation versioning rule, and if this is the reason for the wrong orientation, you might want to check the "Don't copy XMP orientation" option. I do not have your setup, so I can only guess, but it sounds that this option might help in your specific case.

This worked for new files. Thanks! I guess old files need to be exported and imported again. To refresh relations or any of the rescan options do not solve it at least.

I'm still confused though why Exif data get propagated from the raw file to the jpg file when I write back metadata to the raw file after i.e. adding a keyword. I've attached a screen shot of the exif data in the original jpg and two screen shots of the exif data in the jpg after I've written back metadata to the raw file. Is it me not understanding how versioning is supposed to work or could I have done some settings elsewhere that I'm unaware of? I see that I have set jpg files as buddy files as well as versioning - could that be an explanation?

[JohnZeman]

This worked for new files. Thanks! I guess old files need to be exported and imported again. To refresh relations or any of the rescan options do not solve it at least.

You shouldn't need to re-export your JPGs again, just manually change the orientation of them to Horizontal (normal) with IMatch.

For what it's worth here is what I propagate from my master raws to my JPG versions and it works well for me with both landscape and portrait images.

Categories
Bookmarks
Rating
Label
XMP All Data
Don't Copy XMP Orientation
EXIF Data Without Orientation (you may not want this one checked)

[Mario]

Coincidentally I have just been through rotating a load of portrait .RW2 shots taken on my Panasonic TZ200 (ZS200).

Which WIC codec do you use?
Run a WIC diagnosis from the Help menu. WIC Diagnostics
I assume your camera vendor has not provided you with a WIC codec for your camera and relies on Adobe or Microsoft doing their work?

Switch to IMatch RAW Processing under Edit > Preferences > Application (Prefer photools.com RAW processing).
Select the files in your test, press Shift+Ctrl+F5 and force a reload.
If this solves this, the problem is the WIC codec on your system. It does not interpret the orientation correctly.
You can send me a RAW file ZIPped with a link to this thread and I will check what Windows WIC thinks about your file when I have a free time slot.

[Stefanjan]

Which WIC codec do you use?

It looks like Codec 'Microsoft Raw Image Decoder', see  WIC Diagnostics file attached.

Switch to IMatch RAW Processing under Edit > Preferences > Application (Prefer photools.com RAW processing).
Select the files in your test, press Shift+Ctrl+F5 and force a reload.

I wasn't sure which of the options after SHIFT+Ctrl+F5, tried several, Force Update worked. Portrait now displaying correctly.

You can send me a RAW file ZIPped with a link to this thread and I will check what Windows WIC thinks about your file when I have a free time slot.

Zipped file here https://www.dropbox.com/s/fb5cpvt7h3h3yut/P1004816.zip?dl=0

[jch2103]

Re orientation issues, you may want to look at https://www.photools.com/community/index.php?topic=10995.msg83455#msg83455

I had switched from the FPV codec to Microsoft, but got orientation issues. Changing the default to LibRAW fixed the issue.

[Mario]

The RW2 provided seems to have a embedded preview which is not rotated to neutral, but has the same orientation as the RAW sensor data. This is wrong. Previews should be rotated to the neutral position.
This is a common issue with some cameras and there is unfortunately no way for IMatch to tell. The functions in WIC which extract the preview image don't auto-rotate and neither offer information about a potential non-neutral orientation of the preview.

To deal with this, I have added an option under Edit > Preferences > Application: Rotate embedded preview (WIC) which forces IMatch to use the same orientation for the preview as for the RAW.

Or use LibRaw which does not have this problem, but other problems.

It is really bugging me that neither the camera vendors (who continue to churn out variations of proprietary RAW formats with each new camera model) nor Microsoft seem to really care if their customers can open the files produced with their cameras in software not made by Adobe. Not even all RAW processors process all RAW files, and "older" RAW files seem to vanish from support.

This can will become a nightmare in 10 years from now, when the only software that can open your 2020 RAW files comes from Adobe, and costs an arm and a leg.

Users either don't understand these problems or don't care.
And let camera vendors get away with this.

And when it boils up in IMatch ask me to fix it. I don't care anymore either.

This should all just work out of the box. If only the camera vendors would provide a minimum of support (aka provide a working WIC codec for their camera models, at at least provide LibRaw and Microsoft with information and documentation).

[Stefanjan]

Users either don't understand these problems or don't care.

In my case I don't understand the technical stuff. But I implemented your suggestion "Switch to IMatch RAW Processing under Edit > Preferences > Application (Prefer photools.com RAW processing)" and it seems to work so I am a happy bunny!

[Mario]

Don't forget to donate some money to the free LibRaw project which makes the magic work: https://www.libraw.org/
These volunteers do the work your camera vendor (to which you gave money but they don#t give a sh*t about you) and Microsoft (to which you...) should do.

How hard can it be for camera vendors to provide a WIC codec? They have all the code already in their cameras. It might take a week or four of developer time to wrap that up in a WIC codec and give it to you.
Consider you buy a printer and you have to go hunting to find a printer driver which allows you to use it...

[Stefanjan]

Hi Mario,

Your donation suggestion reminded me that I had not donated to ExifTool, OpenStreetMap, GeoNames.org. Now done.

I followed your link to LibRaw but did not see an opportunity to donate.

[Mario]

Thank you!

If users of these projects give just few bucks per year, it keeps these projects running and shows the people doing all the work some respect and appreciation.
And that helps all of us.