Olympus .ORF images shot in portrait orientation...

[ConradW]

...are displayed by IMatch in landscape orientation using the installed WIC codec, while the built-in Windows 10 apps display landscape and portrait .ORF images correctly.

While this issue appears superficially similar to these other threads,

https://www.photools.com/community/index.php?topic=9422.msg66663#msg66663

https://www.photools.com/community/index.php?topic=9165.msg64548#msg64548

...my system has the latest Microsoft Raw Image Extension app (1.0.21991.0) installed, which requires the Windows 10 May 2019 update (version 1903), and the IMatch WIC diagnostics report (attached) states, "A codec for this file format is installed and it looks like it fully supports the format."

What happens:
With Prefer photools.com RAW processing = No (the default) IMatch displays Olympus .ORF images shot in portrait orientation in landscape orientation, although it does show the Exif Orientation metadata value as Rotate 270 CW. Those shot in landscape orientation, with Orientation = Horizontal (normal), are displayed correctly.

The same images are always displayed in the correct orientation in Windows File Explorer, Windows Photo Viewer, Microsoft Photos app (2019.19071.17920.0), Olympus Workspace (1.2), and DxO PhotoLab (2.3.1 Build 24039 and 3.0.0 Build 4210).

With Prefer photools.com RAW processing = Yes IMatch does display Olympus .ORF images shot in portrait and landscape orientation correctly.


Reproducibility:
Always occurs.

Problem isolation:
The .ORF images are always displayed in the correct orientation in Windows File Explorer, Windows Photo Viewer, Microsoft Photos app (2019.19071.17920.0), Olympus Workspace (1.2), and DxO PhotoLab (2.3.1 Build 24039 and 3.0.0 Build 4210).

Steps undertaken so far:

• Tested with "Prefer photools.com RAW processing" enabled. Forced a rescan of sample files. Both portrait and landscape .ORF images are displayed correctly.
  Reset "Prefer photools.com RAW processing" to disabled. Forced a rescan of sample files. Landscape .ORF images are displayed correctly, but portrait .ORF images are displayed in landscape orientation.

System info:
IMatch 2019.8.4 (64-bit) Licensed Version
Windows 10 Home 10.0.18362
Microsoft Raw Image Extension 1.0.21991.0 (installed free from the Microsoft Store)

Additional information:
The WIC diagnostic report states that the 'Microsoft Raw Image Decoder' codec and 'Microsoft Camera Raw Decoder' are both installed, and both are listed as handling files with the .ORF extension.

The report further states, "WIC Result: A codec for this file format is installed and it looks like it fully supports the format."

Files attached:
1) WIC diagnostic report
2) Screen capture (imatch_orf_orientation.jpg) comparing IMatch display with "Prefer photools.com RAW processing" disabled and Windows File Explorer display of the same four sample .ORF files (two shot in 2012 with an Olympus E5, and two shot in 2019 with an Olympus E-M1 Mark II)

So while I can force IMatch to display the .ORF images correctly by setting Prefer photools.com RAW processing = Yes and having it ignore the installed WIC codecs that correctly display those files in the built-in Windows 10 apps (File Explorer, Photo Viewer, and Photos) I read in an older thread that using the IMatch open source LibRaw processing is considerably slower than relying on the WIC codecs. Is this still the case? If so then it would obviously be preferable to have IMatch use the latest WIC codecs for .ORF files that the built-in Windows apps already use successfully to display these images in the correct orientation.

[Mario]

Isn't this a duplicate of the other thread where the orientation fails only when NO WIC codec is installed and IMatch has to fall back to LibRaw and this causes the wrong orientation.
Your case seems to be the opposite, WIC does not work but LibRaw does. How strange. And apparently the only format which causes this is ORF.

What happens if you force IMatch to use the full RAW via WIC and not the embedded preview?
Switch back to WIC in IMatch (disable photools.com RAW processing) and go to Edit > Preferences > Cache and disable the "Use embedded preview".
Then select the image and force a reload with Shift+Ctrl+F5.

If this works then maybe Olympus stores the embedded preview in a different orientation than the RAW data?

You can also send me a sample image to support email address. Please include a link back to this thread because I get between 30 and 50 emails per day.

[ConradW]

Hi Mario,

Thanks for such a quick response.

Yes, as I mentioned earlier, although my issue appears superficially similar to the other threads I appear to be seeing the opposite. I do have an up-to-date WIC codec installed for .ORF files, included in the Raw Image Extension 1.0.21991.0 free from the Microsoft Store. Interestingly this extension also uses LibRaw (see attached ms_raw_image_extension.jpg screen capture).

With this extension installed Windows File Explorer shows the thumbnails from all .ORF files in their correct orientation. But when IMatch does not use its own LibRaw processing and does use the embedded preview from a .ORF file shot in portrait orientation the image is shown in landscape orientation (instead of being rotated by 270 CW, or sometimes 90 CW as shown in the Exif metadata when I held the camera differently).

I did as you suggested and switched back to WIC in IMatch (i.e. disabled "Prefer photools.com RAW processing"), disabled the "Use embedded preview" and forced a reload for my four test images with Shift+Ctrl+F5. The result can be seen in the attached imatch_orf_no_no.jpg image. The thumbnails of the images shot in portrait orientation are still shown horizontally in landscape orientation.

I then went through the other three combinations of "Prefer photools.com RAW processing" enabled and disabled, with "Use embedded preview" enabled and disabled. The results of those tests are attached.

imatch_orf_no_yes.jpg --> "Prefer photools.com RAW processing" = "No", "Use embedded preview" = "Yes"
imatch_orf_yes_yes.jpg --> "Prefer photools.com RAW processing" = "Yes", "Use embedded preview" = "Yes"
imatch_orf_yes_no.jpg --> "Prefer photools.com RAW processing" = "Yes", "Use embedded preview" = "No"

Strangely, with "Prefer photools.com RAW processing" = "Yes" and "Use embedded preview" = "Yes" the thumbnails of the images shot in portrait orientation are still shown horizontally in landscape orientation but are rotated 180 CW compared to "Prefer photools.com RAW processing" = "No" and "Use embedded preview" = "Yes".

Only with "Prefer photools.com RAW processing" = "Yes" and "Use embedded preview" = "No" are the thumbnails and "Quick View" of the images shot in portrait orientation shown in the correct portrait orientation. Using some other images I have verified this to still be true with portrait oriented images tagged in the Exif metadata as "Rotate 270 CW" and tagged as "Rotate 90 CW" depending on how I held the camera vertically when taking the shot. (Although I found that the thumbnails and Quick View of these files were much darker than they should be given that the images are correctly exposed.)

I have zipped up the four .ORF files that I have been using for my test and emailed you a link as requested.

It is indeed very strange that Windows File Explorer using the LibRaw-based Raw Image Extension codecs for WIC in Windows 10 Home v1903 can correctly display thumbnails from .ORF files while IMatch using the same WIC codecs appears to have a problem with those shot in portrait orientation. Hopefully the information here and the sample files that I have provided will help you quickly discover the root cause of this discrepancy.

Best regards,
Conrad

[Mario]

I will look at your images as soon as I have time.
There are currently over 10 open issues, where customers have send me files or metadata or similar information so this might take a while.
Every of these 10 cases may cost me hours or even days to process.

The WIC diagnostic report states that the 'Microsoft Raw Image Decoder' codec and 'Microsoft Camera Raw Decoder' are both installed, and both are listed as handling files with the .ORF extension.

Please clarify.
Having multiple WIC codecs associated with the same format introduces an element of randomness.
IMatch asks Windows WIC to "open" a specific image and to retrieve the preview or full RAW. Which codec is picked depends entirely on Windows. This is totally opaque.
Maybe a different codec is chosen by Windows for different applications. Or Windows Explorer does something special that is not officially documented.

IMatch processes all files via WIC in the same way.
1. Load the image
2. Ask WIC for the required orientation of the image for display
3. Rotate the image as indicated.

Why this fails for some ORF files, and apparently ORF files alone, is unknown to me.

[sinus]

Mario, this is only MAYBE a hint, what you will very quickly see.

I have also this problem with horizonal-vertical (I had reported it).

I checked my files.
And I have seen, that I have this behaviour since this version:
IMatch 2019 (Version 2019.2.4)

I had this not before, but since this version.

Important:
Maybe you want quickly check this. If you haven't changed anything about this topic in this mentioned version, then forget this post.
Then this has nothing to do with it and forget this post, because the problem from ConradW has nothing to do with nefs.

[Mario]

You have reported it where? (Link?)
I have written 23,000 posts in this community. You may remember that you reported an issue at some point in the past. I don't.
Is this still open? I cannot find anything in the bug report board..?

You are using NEF files and that's probably a different thing.
I also use NEF and I have never experienced a problem. I use D3, D300, D7500, D800 etc. files daily. And have many more in my sample library.

[Mario]

I have looked at the four sample files.

1. On my normal PC with FastPictureViewer codecs.
IMatch on default settings (WIC, use embedded preview if > 2000 pixel).
Result: All 4 files show with the proper orientation.

2. On a fresh Windows 10 installation (latest version) with all default Windows WIC codecs.
IMatch on default settings with WIC and embedded previews.
IMatch shows only "D8292632.ORF" with the wrong orientation.
This file reports than it has to be rotated by 270° CW or 90° CCW. And this is what IMatch does.
When I skip the EXIF orientation in the debugger, the file comes out correctly orientated.

3. Windows Explorer does not show the files "D8292631.ORF" and "D8292632.ORF" but shows only the broken image icon.
Windows Photos can only display two 2 out of 4, the others are reported as "unsupported format". Same as in Explorer.

4. When I force IMatch to use the full RAW for the wrong rotated file, the orientation is correct (after applying the EXIF orientation requested).
So the RAW data is rotated as indicated by the EXIF record. But the EXIF record returned by WIC for the preview also indicates a 270° rotation.
This either means that Windows is unable to determine the orientation of the preview and returns the orientation of the RAW (270° CW).
Or maybe the camera (is this a file straight from the camera?) stores the preview always in neutral orientation but does not bother to correct the EXIF orientation?
Both EXIF records (RAW and preview) report 270° according to ExifTool.

This would be similar to the effect we see in LibRaw where, for ORF files only, the embedded preview must always be considered as having a neutral orientation, independent from what the EXIF is reporting.
Which is unfortunate, of course.

I'm not sure how I should handle this without potentially breaking other RAW formats. Or, if I would limit this hard-coded change to the .ORF extension only, I could probably break orientation for images created with older cameras or firmware versions. Not sure.

[sinus]

You have reported it where? (Link?)
I have written 23,000 posts in this community. You may remember that you reported an issue at some point in the past. I don't.
Is this still open? I cannot find anything in the bug report board..?

You are using NEF files and that's probably a different thing.
I also use NEF and I have never experienced a problem. I use D3, D300, D7500, D800 etc. files daily. And have many more in my sample library.

Sorry, here the link:
https://www.photools.com/community/index.php?topic=9121.msg64260#msg64260

Yes, this could be another thing, because I have nef.
I wanted it only mention, because I checked these days and before the release, what I have written, all files are correct.
After this I had this problem, with the same camera.

But no, for me this is not open, it is closed, not worth to investigate time, because I am maybe the only one.

Because whatever I do set in the preferences, I have this behaviour always.
Every time, if I take pics by hand vertical or with a studio (big and heavy) stand, it is the same:
Say, 15 percent are the wrong orientation. There can be absolutely the same pic, even with self-timer, maybe 6 correct (vertical), 2 false (horizontal) and then again 5 correct.

Sometimes 2 of 10 are false, sometimes 4.

My simply solution is in the last monthes: select the wrong images, do a force-rescan and then they are correct.

Hence for me this is solved, because I think, maybe it is only here and I want not, that you use your time for such an issue, what is finally not that bad.

[Mario]

If this is random and for NEF files, do you use the latest NEF codec from Nikon (yes, they make one), see https://www.photools.com/1167/wic-support-codec-availability/
If you use the FPV codecs, these are almost 3 years out of date now. Maybe you have better luck with the native NEF codecs included in Windows.
Do not install multiple WIC codecs for the same RAW format.
If files fail to load properly, check the log file. Did IMatch report warnings or errors?
Don't run Adobe applications at the same time for the same set of images. Adobe applications sometimes keep file locks, preventing other applications from accessing files. But then you'll get warnings in the log file.

[sinus]

If this is random and for NEF files, do you use the latest NEF codec from Nikon (yes, they make one), see https://www.photools.com/1167/wic-support-codec-availability/
If you use the FPV codecs, these are almost 3 years out of date now. Maybe you have better luck with the native NEF codecs included in Windows.
Do not install multiple WIC codecs for the same RAW format.
If files fail to load properly, check the log file. Did IMatch report warnings or errors?
Don't run Adobe applications at the same time for the same set of images. Adobe applications sometimes keep file locks, preventing other applications from accessing files. But then you'll get warnings in the log file.

Thanks Mario, for your tips!
I will check this and do so.
I did not know, that Nikon has NEF codec, thanks for this. 

[ConradW]

2. On a fresh Windows 10 installation (latest version) with all default Windows WIC codecs.
IMatch on default settings with WIC and embedded previews.
IMatch shows only "D8292632.ORF" with the wrong orientation.
This file reports than it has to be rotated by 270° CW or 90° CCW. And this is what IMatch does.
When I skip the EXIF orientation in the debugger, the file comes out correctly orientated.

3. Windows Explorer does not show the files "D8292631.ORF" and "D8292632.ORF" but shows only the broken image icon.
Windows Photos can only display two 2 out of 4, the others are reported as "unsupported format". Same as in Explorer.

Many thanks for digging into this Mario!

Yes, all of the supplied ORF files are straight from their respective cameras.

With a clean install of Windows 10 v1903 I believe that only the older Microsoft Camera Raw Decoder codecs are installed. According to Microsoft (https://www.microsoft.com/en-us/download/details.aspx?id=26829) these codecs do support the Olympus E-30 camera launched in 2009 ("_9085746.ORF" and "_9085756.ORF" were shot with an E-5 launched in 2010 that uses the same 12-megapixel sensor as the E-30, hence the E-5's ORF format is probably the same as that used in the E-30), but they do not support the much more recent Olympus E-M1 Mark II launched in 2016 (used to shoot  "D8292631.ORF" and "D8292632.ORF" that uses a 20-megapixel sensor introduced sometime after all of the Olympus cameras listed as being supported by the Microsoft Camera Raw Decoder codecs).

This might explain why only "D8292632.ORF" is shown with the wrong orientation in IMatch when only these default Microsoft Camera Raw Decoder codecs are installed in Windows 10 because, as you said, when you "...skip the EXIF orientation in the debugger, the file comes out correctly orientated." As you suggest, this implies that the embedded preview has a neutral orientation (i.e. is already rotated with respect to the RAW image).

I wonder if doing the same with "_9085746.ORF" shows that the embedded preview for that image is not already rotated with respect to the RAW image? If not already rotated it might confirm that at some point Olympus changed how the embedded previews are stored (which leaves us to perhaps find out when, and with which models).

It certainly does explain why Windows File Explorer and Microsoft Photos app cannot show the later  "D8292631.ORF" and "D8292632.ORF" images...as the older Microsoft Camera Raw Decoder codecs do not support the 20-megapixel sensor in the E-M1 Mark II. The E-M1X from earlier this year and the just announced E-M5 Mark III both use this same sensor and so will probably exhibit the same issue.

Installing Microsoft's recently released Raw Image Decoder from the Microsoft Store on a clean install of Windows 10 v1903 does enable Windows File Explorer, Microsoft Photos app, and even the older Windows Photo Viewer to correctly display images from the more recent E-M1 Mark II, as well as the earlier E-5.

As for having both the older Microsoft Camera Raw Decoder and newer Raw Image Decoder codecs installed that both handle ORF (and many other RAW formats), I believe that the newer ones are taking precedence when WIC comes to processing an image. As we see in the WIC diagnostics file when testing the "_9085746.ORF" image, it is reported that the newer 'Microsoft Raw Image Decoder' is being used:

WIC: Testing file 'D:\Pictures\_Masters\2019\20190829\ORF-TEST\_9085746.ORF'
   Thumbnail: Codec 'Microsoft Raw Image Decoder'
      () 1024x768 pixel in 250 ms.
   Preview: Codec 'Microsoft Raw Image Decoder'
      () 3200x2400 pixel in 250 ms.
   Full resolution: Codec 'Microsoft Raw Image Decoder'
      () 4096x3084 pixel in 234 ms.

WIC Result: A codec for this file format is installed and it looks like it fully supports the format.

Unfortunately there does not appear to be any way to uninstall the older Microsoft Camera Raw Decoder codecs. They appear to be a default part of Windows 10 and don't even appear as "Windows Features" that can be disabled/uninstalled. Perhaps the next major update to Windows 10 will not include them and instead users will be advised to install the new Raw Image Decoder instead.

Having worked in the software industry myself for over 30 years I fully understand the desire to avoid "hard coding" exceptions for specific scenarios.

Best regards,
Conrad

[Mario]

How strange.
Microsoft is shipping software based on LibRaw, which itself is just based on dcraw. LibRaw took over after the author of dcraw discontinued it. Obscure.
Why do they include a set of WIC codecs as an integral (!) part of Windows 10. And then provide yet another set of WIC codecs, downloadable from the Microsoft Store.
If these are better, why not include them in Windows 10?

NOTE: The software downloadable on the page for your link (https://www.microsoft.com/en-us/download/details.aspx?id=26829) dates back to 2014. This cannot be the right thing (see the Details on that page).
This page for the "RAW Image Extension" in the MS Shop mentions May 2019: https://www.microsoft.com/en-us/p/raw-image-extension/9nctdw2w1bh8?=&activetab=pivot%3Aoverviewtab


How hard can it be to ask camera vendors to provide a WIC codec for Windows? There is one billion Windows PCs out there. Great customer reach for maybe US$ 10,000 that it would cost the Canon, Sony, Olympus to develop and distribute a WIC codec...We all remember the patent fight between Nikon and Adobe (Nikon encrypted white balance info in their NEF files to make reverse-engineering illegal) and Adobe complained loudly until Nikon provided Adobe (alone) with a component which could extract the white balance info...

I mean, camera vendors should know their RAW formats best and thus should be able to deliver superior WIC codecs.
Nikon did that (in the past) and their WIC codec could even interpret the virtual edits done in Capture. They no longer do that (after shipping a re-branded version of SilkyPix (?) as their own) but at last Nikon still offers an up-to-date WIC codec. One of the reasons why I personally use Nikon gear.

The WIC concept was to cool in the beginning. Microsoft provides the infrastructure in Windows and all the camera vendors have to do is to provide a WIC codec. No need to reveal file format details or patented algorithms,  but their users can still open and view their RAW files in all Windows applications.

But noooo - camera vendors let Microsoft and their users down. They never did or stopped, for some stupid reasons, to deliver a WIC coded. Probably for some lame cost saving, leaving their customers standing in the rain.
And often the shit boils up at the IMatch end, when yet another RAW file fails to display properly or is not supported by the installed WIC codec or fails to rotate correct for some unknown reason. Which costs my time.

Some day we will all have to subscribe to an Adobe package just in order to be able to view our RAW files...

[Jingo]

One of the main reasons I export all RAW images post edit (via Capture One) to JPG and consider the JPG's the new master files.... universal support on almost every device available and except for minor color shifts based on color space, should show pretty accurately the image as it appears to me.  If I need to review RAW files, I use Capture One.... it shows my original image (before) and the edited image (after) in the catalog... since my folder and image name setup is the same, it is simple to find the file in the C1 catalog - even without metadata.

BTW: the newer Windows Codec requires the March 2019 update in order to load so perhaps that is why they have not replaced the original codecs yet?  I downloaded the new ones for fun and it does show NEF images now in explorer (and in XYPlorer).. so that is good if you need that.

[RobiWan]

@ConradW - thank you. Your solution works perfect for me 

[ConradW]

@Mario I totally agree that the camera manufacturers have let us all down. Microsoft provided a framework and all the camera manufacturers had to do, without revealing any of their proprietary IP, was to provide a suitable WIC codec.

As @Jingo suggests, Microsoft is probably shipping and installing the older Camera Raw Decoder with Windows 10 as the newer RAW Image Extension WIC codecs were (I think) still considered to be in beta when Windows 10 v1903 was released. The newer RAW Image Extension WIC codecs will probably become the default preinstalled codecs with the next version of Windows 10.

[Mario]

It could all be so simple. But (most) camera vendors just don't care.
And they still cling to 30 year old EXIF metadata, despite the fact that modern cameras have the same computing power as smart phones and could easily create a clean XMP record in-camera. Which would make so many things much easier. Oh, well...

[Carlo Didier]

It could all be so simple. But (most) camera vendors just don't care.
And they still cling to 30 year old EXIF metadata, despite the fact that modern cameras have the same computing power as smart phones and could easily create a clean XMP record in-camera. Which would make so many things much easier. Oh, well...

They probably all use some common old software library because noone wants to reprogram it ... 

[Jingo]

Also, I'm sure only about 1% of users are that interested in the data to really care where and how it is stored... not worth the programming and testing time from camera companies.

[maffe69]

I can confirm that ORF files shot in portrait orientation by a E-M1 mark I are displayed by IMatch in landscape orientation. The same happens with RW2 files shot with Panasonic GX9 and G9. Can we hope in a solution? I do not understand whether the previous replies provided one. Getting things right shouldn't be too difficult: every other photographic software on my Windows 10 PC gets the orientation right (there are more than 10 installed, at the moment).

[Mario]

Please tell a bit more. Do you have a WIC codec from Olympus installed which supports your files? Does IMatch have to fall-back to LibRaw?
See WIC Diagnostics and attach the result (do not copy/paste the data in your reply, please).

If you have no WIC codec installed, or the installed WIC codec does not support your proprietary ORF format, please contact Olympus and request an updated WIC codec.
When the WIC codec does not tell IMatch correctly how to rotate the file, IMatch has no chance.

[maffe69]

Please find attached the WIC diagnostic output for RW2 from a Panasonic G9 image and ORF from Olympus EM1 mark I. As we all know, Microsoft Raw Image Decoder takes very well care of supporting these formats. Imatch seems quite satisfied with my WIC codecs, as any other program installed on my PC. It seems I'm in the same boat of the user ConradW.

[Mario]

The WICs codec supports both files so there should be no problem at all.
But if the WIC codec for some reason returns a wrong orientation value and IMatch rotates the image wrong as a result, you can use a virtual rotation in IMatch to correct the problem.
Maybe the EXIF orientation is wrong? Or the embedded preview uses a different orientation as the RAW but reports the wrong EXIF orientation? Hard to say without actually having the file here.

Are both the RW2 and the ORF file rotated wrong?
ORF seems to be problematic when LibRaw is used (not WIC) but I've never had a report that the built-in WIC codecs in Windows 10 fail to rotate a RW2 correctly.

Please upload the files to your cloud space and post a link.
Also post a screen shot of the Edit > Preferences > Cache dialog in IMatch.

[maffe69]

Please find attached two screenshots:

1) In the first one, you see two raw files, ORF and RW2, displayed with the wrong orientation in Imatch and the correct orientation in File Explorer.
2) IN the second one, the cache settings, as requested.

I'm ready to provide the files on request, but to a private email address. Please let me know where to send the link.

Thanks.

[Mario]

The screen shots do not help much, unfortunately.

To send me an email, use the standard support email address listed here: support email address
NOTES:

1. Do not post email addresses in public forums like this.
2. Include a link to this thread in your email. I process between 40 and 50 emails each day and I cannot always remember everything.
3. It may take a while for me to look into this peculiar problem. User sending me files for analysis all the time, and there is always a backlog.

Maybe installing the latest version of the Microsoft WIC codecs for your system solves the problem?

https://www.microsoft.com/en-us/p/raw-image-extension/9nctdw2w1bh8?activetab=pivot:overviewtab

[maffe69]

I sent a message to the support address, referring to this forum thread.
I'm well aware of the backlog. Let's hope it has shortened a bit.
As far as the WIC is concerned, please consider that the MS Store keeps its stuff automatically updated.

Thanks in advance.

[Mario]

There are two sets of WIC codecs. The default ones in W10 and the newer ones in the store, which are based on LibRaw.

[maffe69]

Yes, I'm aware of this. The older set is called Microsoft Camera Raw Decoder, the new one Microsoft Raw Image Decoder, as the OP ConradW reminded us in one of the previous posts. The WIC diagnostic files I attached to my previous post clarify that I'm using a (fully updated) version of the 'Microsoft Raw Image Decoder'.

[Mario]

I have downloaded and tested your files.

On my system, they load fine with the FastPictureViewer WIC codec for ORF and also the latest (libRaw) based ORF codec.
I've also tested the pure LibRaw (Edit > Preferences > Application: Favor photools.com RAW processing) an they also load fine and with the proper orientation.
Since I've changed the LibRaw code in IMatch to ignore the orientation returned by LibRaw if the embedded preview is used, this seems to do the trick for your files also.
So, all is well.

[maffe69]

Thanks for your efforts! I'm sorry, but I do not understand how to take advantage of your last post. I'm currently away from my usual PC, so I downloaded the trial of IMatch and installed it on my fully updated Win10 laptop (with updated WIC codes) and tried to browse through some RW2 files from my G9. Let my assure you that the orientation is still very wrong, exactly as reported in my previous posts. Hence, I'm extremely happy to learn that everything is fine on your hardware, but I would really appreciated some hints about how to make it properly work on my own PCs. Thanks in advance.

[Mario]

This change will be part of IMatch 2020.

[spiff]

Canon .CRW Raw files are also affected. Another way to get rid of it is taking RAW+jpg and use Display option --> toggle visual proxy in the viewer.

regards Björn

[spiff]

i have to correct myself, it does not help. I speak about Canon .crw files. What i can see: If it is just the .crw file and no developed jpg, imatch shows in correct orientation. if a .jpg ist developed with lightroom, .jpg and .crw are shown in correcht orientation in imatch and windows explorer preview as long as imatch does not rescaning the directory / the files. When imatch rescaned it, imatch shows the vertical .jpg horizontale when opened. I have no idea about the reason. What is curious, imatch shows the thumbnail preview still in correct orientation. What is much more curios, imatch shows the .jpg in correct orientation using the imatch "Bilderschau". Windows Explorer starts showing thumbnail preview .jpg in false orientation AFTER imatch rescaned the directory, when imatch does not rescan the directory, the thumbnail preview of Windows Explorer is o.k. When opening the jpg with Windows Image Viewer, it takes a second an Windows corrects the orientation. Imatch does not. When opening the jpg in another picture editing software [photoline], the vertical jpg is oriented correct vertical. Please see the examples.

[JohnZeman]

I have not been following this thread so I don't know if what I'm about to say is relevant to this problem or not but I'll throw it out there anyway just in case it might help someone.

I shoot Canon CR2 files, they are my masters in my IMatch file relations.
After I have processed a CR2 in PhotoLab + Affinity Photo and have exported it back to IMatch as a JPG, that JPG becomes a version of the CR2 master.

Long story short I've learned that when I shoot a CR2 image in portrait mode, in IMatch I should leave the orientation alone (Rotate 270 CW) so it appears correctly in PhotoLab.

The final exported JPG version, in order to display correctly in IMatch and other programs, must always have its orientation set to Horizontal Normal regardless of whether the CR2 master was in portrait mode or landscape mode.

Where I got in trouble, which led to this conclusion a couple months ago, was when I was propagating metadata from master to version (copy XMP all data) and when IMatch was also copying the master (CR2) orientation to the JPG version which caused the JPG to display sideways.  And since the JPG is used as a visual proxy for the CR2 IMatch then appeared to rotate the CR2 image sideways too when it was actually just the JPG.

To completely solve the problem in Preferences > File Relations > CR2 Versioning > Versioning I checked the box to "Don't copy XMP orientation" for CR2.

[Mario]

Rescanning a folder does not modify anything. Unless IMatch finds new/updated images, imports them, this creates new metadata and you have enabled the option to write-back immediately in the options. Only in this case IMatch will write-back metadata.

Not enough information to do anything useful. Please

1. Check the EXIF orientation for your CRW and JPEG files in the IMatch Metadata Panel. Switch to 'Browser' mode to see this data.
2. Check the EXIF orientation for your CRW and JPEG in the ExifTool Command Processor in IMatch. Use the "List Metadata" preset and then search for orientation.
3. Run a WIC diagnosis on one of your CRW files so we see if and which WIC codec is installed and used for loading your CRW files.
4. Send a sample CRW and JPEG file to my support email address so I can have a look at the files, as soon as time permits.

This will allow us to analyze this problem properly.

As described above at some length there was a bug in IMatch which could rotate a RAW file wrong when a) no WIC codec is installed and IMatch falls back to LibRaw and b) LibRaw returns a non-default orientation for the RAW file even when the preview is used and has been already rotated.

But this affects only RAW files. Not JPEG files.
For RAW IMatch rotates the image using the EXIF orientation reported by the WIC codec.
For JPEG files IMatch rotates the image using the EXIF orientation reported by the EXIF data.

If your workflow produces 3 different orientations for the same file, and different orientation in Windows Explorer and IMatch on top, something is badly wrong with the EXIF orientation in your files. Or some software has messed up the RAW/Preview orientation. IMatch has tools to correct that under Edit > Image > EXIF Orientation.

[maffe69]

@Mario In your post dated December 27, 2019 you claimed that the problem with the wrong orientation of ORF and RW2 files would have been fixed in iMatch 2020. At the time, I was a bit surprised to learn that in order to have such an obvious bug corrected I would have to pay for an upgrade. However, I went along and purchased iMatch 2020 this afternoon.
I have been very surprised to discover that the issue is still there: ORF and RW2 raw files are still shown with the wrong orientation. This is a huge pain in the back. Frankly, this situation is highly unsatisfactory and difficult to accept ... I'm not a fully-fledged programmer, but I suspect that getting the orientation right is the bread and butter of any photo viewer, and any other viewer I used on my PC does the job properly. Unfortunately, I was trusting enough to spend my money without trying iMatch 2020 in advance. It's s pity, since the new features seem very interesting.

[Mario]

Did you force IMatch to reload the files using Shift+Ctrl+F5?
IMatch does not re-create thumbnails and cache images when an update is installed.

All my sample ORF files processed with LibRaw that exhibited this problem don't anymore with IMatch 2020.
If you have still a sample ORF which fails to process with LibRaw, send it to my support email address.

[maffe69]

@Mario Of course I did. This was the first thing I tried. Never mind. As far as support is concerned, I'll pass this time: been there, done that, left unimpressed. I kissed goodbye to my money and I'm in the process of moving to Digikam 7. While still in beta it's free, works fine, and shows my RAW files correctly. It even does face recognition sufficiently well, without much fuss. I wish all the best to iMatch.

[Mario]

If you don't want to send me a ORG file which exhibits this behavior, I'm unable to solve this.
All ORF files I have here (about 50 from different cameras and users) work correct with IMatch 2020.

I wish you good luck with digikam.

[spiff]

Mario,

@maffe69 is right. ORF files still not o.k. in orientation. Same here, updated to 2020 yesterday night because you promised to have it fixed then. But thats not the case. It´s ORF + jpg out of the cam. The old lightroom 4, Windows etc. on my PC does it, but still not imatch 2020. I am really disaapointed because you say it is fixed, no it is not fixed. This is not acceptable. I send you 2 files.

Regards Björn

[Mario]

y it is fixed, no it is not fixed. This is not acceptable. I send you 2 files.

From all I could tell, this is fixed. I don't write "fixed" into the release note when I don't think it is fixed. That would be non acceptable.

Does IMatch use LibRaw or do you have an ORF WIC codec? Big difference. Run a WIC diagnosis to be sure.

The bug fix only involved LibRaw (Fallback when your ORF is so special that the Windows WIC codec does not support it), which returns a non-neutral orientation even if the preview is used (and already rotated). This is what I have fixed. IMatch ignores the orientation if the preview is used.
This fixed the problem for the "wrong orientation ORF files" I have here, sent it from customers.

What are your cache settings under Edit > Preferences > Cache? Do you force IMatch to load the full RAW or is the embedded preview large enough.

[spiff]

Mario,

i try to give feedback as i can. Be aware, IT IS NOT FIXED! It is not interesting me as an user and non programmer what in deep there is to look on. Other software does it, imatch does it not, on my system.
About cache, please see the attachment. Using the viewer, if imatch ist told to show "Stellvertreterbild" (the .jpg) everything is fine. But in 2020 i have to disable "Stellvertreterbild" (T,X) to use "Anmerkungen-panel" (T,A) [working with face detection]. That forcees Imatch to show the .orf, and this is not in vertical orientation. Please telling me how to run a WIC diagnosis.

[Mario]

Did you run a WIC Diagnostics?
Does your system have a WIC codec installed which can handle the file (from Olympus or Microsoft) or has IMatch fall back to LibRaw because your ORF variant is not handled by WIC?

[spiff]

Please see attached. Windows WIC codec is able to open my ORF files. If i open orf files in Portrait orientation with Windows Foto, the files first shown horizontal, but after a short moment Windows orientate it correct. This is what imatch does not. Did you received my Email?

[Mario]

That's a different thing.
Your ORF files are processed by the installed ORF WIC codec on your system. Not LibRaw!
The bug fix I made was for users using ORF formats which are not handled by Windows WIC and for which IMatch has to fall back to using LibRaw.
And LibRaw returns an non-neutral image orientation even if the preview has been already rotated. This was my bug fix for IMatch 2020 - to deal with that.

Apparently the WIC codec on your system loads the file but returns none (?) or the wrong (?) orientation. Never seen that before.
Please send me a sample image which exhibits this behavior to support email address.
Please state your Windows version and build START menu > Search for winver and then run the command to see your Windows version.
Different Windows versions have different versions of the Microsoft codecs.

[spiff]

>Apparently the WIC codec on your system loads the file but returns none (?) or the wrong (?) orientation. Never seen that before.
Please read my last report again, i modified it. No; just in Windows preview (Thumbnails) Portrait .orf are shown horizontal, if they are opened with Windows Foto they are shown in correct orientation. As Lightroom 4 does it also.

Have you received my Email?

Please see attached winfer.

[Mario]

I currently get about 50 to 80 emails per day. Which email do you mean?

If i open orf files in Portrait orientation with Windows Foto, the files first shown horizontal, but after a short moment Windows orientate it correct.

So it is wrong first, then correct?
This sounds like Windows Foto is first loading the embedded preview (which has the wrong orientation) and then it loads and develops the full RAW, which has the correct orientation.

IMatch only uses the embedded preview if it is large enough (depending on your cache settings). This would explain the discrepancy.
When you disable the "Use embedded preview" option under Edit > Preferences > Cache and then select one of your problem files, press Shift+Ctrl+F5 and use "force update", does IMatch then display the file correctly?

IMatch just asks Windows WIC to load the image. If this works, it asks Windows WIC how to rotate the image. And then does it.
This usually just works.

Lets see if I have a sample of your ORF file what WIC does with the image.

[spiff]

Betreff: Imatch 2020 - ORF files falsch orientiert - Beispielbilder
sent: 22:32 Uhr

[Mario]

Ah, I see.

When I click on the download link I get:



Nothing to download?
I replied to that email but got no response.

[spiff]

problem between the headphones, sent you the delete link, wait a minute.

[spiff]

o.k., you should now received a E-mail whith a valid link.