Wrong orientation displayed for ORF files / Missing WIC codec?

[Roter Rabe]

Hello! I am new to this forum and am not familiar with the proper procedure for asking for help yet. I will try to be as clear as possible.

What happens:
iMatch shows pictures shot in portrait orientation in landscape orientation. This happens only for .ORF raw files. The in-camera jpeg produced alongside the raw is displayed correctly.

Reproducibility:
Always occurs.

Problem isolation:
The orientation is shown correctly in Olympus Workspace, Adobe Bridge CC, Faststone Image Viewer, and DXO Optics Pro 11.

Steps undertaken so far:
1) Restarted both the application and the system.
2) Tested both with "Prefer photools.com RAW processing" enabled and disabled. Forced a rescan of a sample file after each change.
3) Downloaded and installed the Olympus RAW codec from https://cs.olympus-imaging.jp/en/support/imsg/digicamera/download/software/codec/index.cfm Restarted application and system, forced a rescan. This is the codec that is linked to on the WIC support entry, but I am not sure if this is actually the right codec, as it looks like the codec is older than my camera. But for the life of me, I couldn't find a newer version.

System info:
IMatch 2019.8.3 (30-day-trial version)
Windows 10 Home 10.0.17763

Additional information:
The WIC codec report returns "WIC Result: It looks like no WIC codec is installed which can handle this file." It does identify the 'Microsoft Camera Raw Decoder' for .ORF files and the newly installed "ORF Decoder" for .orf files.

Files attached:
1) WIC codec report
2) Application log
3) I have tried to attach a sample ORF file, but reached the file limit. Please let me know if you need it and I'll try to upload it another way.

Thank you very much, I appreciate your help! I do speak German as well, if that makes things easier at all.

[Mario]

No WIC codec is installed on your system which handles your ORF files.
There is an ORF codec (default Windows codec?) but it does not understand the ORF variant you are using.


IMatch automatically falls back to using the open source LibRaw processing library to read and process your ORF file.
Maybe this library does not properly detect the orientation of the ORF. I don't know.

I suggest you apply a virtual rotation in IMatch to the file.
You may also want to send a sample ORF file to Microsoft so they can enhance the ORF codec included in Windows.

[Roter Rabe]

Thank you, Mario.

[Mario]

You can send me a sample ORF file to support email address
I can check it and maybe inform the LibRAW project folks about the problem with the orientation interpretation for this format variant.

That's the risk when you reply on undocumented RAW formats. Camera vendors change them all them time and without notice.

[Roter Rabe]

Thank you, I just sent a message to the support email address. I appreciate the help!

[Mario]

I have looked at the file. The RAW data reports a required orientation of 270° clockwise (or 90° counter-clockwise).

It loads fine with the FastPictureViewer WIC codecs. I have not yet tried on a clean Windows 10 with only the default codecs.

The fallback to LibRaw extracts the preview OK.
But it also reports that the file should be rotated by -90° so that is what IMatch does.
I think the preview is stored rotated already so IMatch should not apply the -90° again. Not sure how to determine this. I will look into this for IMatch 2020.

Until then, I recommend using a virtual rotation in IMatch. This is fast and can be easily undone when a later version of IMatch/LibRaw treats the file differently.

[Roter Rabe]

Thank you for your reply!

Sorry, I think I am a bit confused. Do I understand it correctly that iMatch is essentially rotating the file twice?

Would the files be displayed correctly in iMatch if I installed the FastPicture Viewer Codec Pack?

[Mario]

IMatch rotates once.
IMatch loads the preview via LibRaw and then applies the rotation specified. But that rotation does not match the rotation of the embedded preview in your file, hence the problem.

Would the files be displayed correctly in iMatch if I installed the FastPicture Viewer Codec Pack?

While it is still on sale (AFAIK), it is several years out of date. It still works great.
But the developer of the FPV codecs was hired by Microsoft some years ago and now develops the official WIC codecs for Windows (among other things).

Which also means that the ORF files you use must be something special. If they load fine here with the 2 year old FPV codecs but fail with the current standard Windows 10 codecs, which are newer. Strange, indeed.
I need to try your file on a Windows machine without FPV codecs, but that can take a while. But since the problem has been identified and there is an easy work-around in IMatch, I'll move this into my "things to look into when there is time" queue.

[Roter Rabe]

Thank you, I appreciate your help.

[RobiWan]

I have the same Problem with orf files.

I gave some files to a colleague and he displays them correctly. So there must be something wrong with the installations or the codec interface that only IMatch interprets it wrong for some installations.

@Mario - is there any way to "debug" the interface to find the cause?

Robert

[Mario]

Has your system WIC codecs which handle the format or does IMatch have to use LibRaw? Check with WIC Diagnostics

[RobiWan]

Win 10 and IMatch use the same Codec "LibRaw"

Show my old thread https://www.photools.com/community/index.php?topic=9165.msg64548#msg64548
(but now I use 2019.8.4)

Robert

[Mario]

Then what I wrote above should apply to you, too.

This seems to be a problem only with non-neutral oriented ORF files and LibRaw.

[RobiWan]

If you mean with "neutral" landscape/ portrait mode than it is true. But only in IMatch, not if I see the images in Windows Photos.

And here would be interesting (at least for me) where exactly information gets lost or misinterpreted. Therefore the question for an "extra debugging"

Robert

[Mario]

But only in IMatch, not if I see the images in Windows Photos.

I doubt Windows Photo is using LibRaw.
But I wonder why IMatch gets an error when it tries to load your ORF files via the installed WIC codec.
Or does it not get an error (WIC Diagnosis says what?).
WIC is a black box. IMatch tells WIC ("Load this file") and gets the loaded image back. Or an error message. Which is then written to the log file and also visible when you run the WIC diagnosis.

And I said above that LibRaw tells IMatch the wrong orientation. And how I've corrected that in IMatch 2020. Anything unclear with that? Do do need more info?

[RobiWan]

Of course it uses that, RAW Image extention is part of Windows Phots. And RAW Image Extention just uses LibRAW.

I see no any Errors in WIC.
If this is bypassed in version 2020 - perfect

Robert

[Mario]

Your problem is then different.

This thread is about a missing WIC codec for ORF or the codec not loading the ORF or IMatch rotating the ORF wrong when no WIC codec can handle the file and IMatch falls back to using LibRaw.

Your WIC diagnosis shows that the installed Microsoft WIC codec can load your file without problems.
And IMatch should load this file without problems, too. Is this not the case?
If so, what is the problem? IMatch should use the embedded preview in your file and applies the orientation WIC demands for the file, automatically.

If you get a wrong orientation for your ORF file in IMatch, please upload a sample and send me an email with a link to the image and a link to this thread to support email address.
Maybe ORF, or the firmware you use in your camera has a specific problem with the orientation. Maybe they always store the embedded preview in neutral orientation, independent from the RAW. Because, the "rotate the image as specified in EXIF" seems to work well with all other RAW formats.

[RobiWan]

I already did that with the old thread. And that does not bring anything, because it works correctly on your and e.g. a colleague installation. With me on 3 computers but not.

Robert

[Mario]

Please understand that I process between 30 and 50 support emails plus this community every day.
I cannot remember everything. Which thread do you mean? Do you have a link?

Did we test your files already on other computers and it fails only on yours? If so, the problem will be very hard to identify in IMatch.
Maybe a old broken WIC registration or a left-over from some software once installed has damaged something. Hard to tell. WIC is basically a black box and all the possible diagnostics are used by IMatch (via log file) and the WIC Diagnostics.

But the WIC diagnosis succeeds on your PC and IMatch should load the files. Does it not? Or is only the orientation wrong? If so, just apply a virtual transformation in IMatch and the problem is solved. Does that not work?

[RobiWan]

Of course I understand that.

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

yep - on all my machines the same behavior - orientation is always landscape. And I believe that it's very hard to find something in such a situation, especially if you write WIC is "black box". All files are loaded, only the orientation in portrait format are wrong.
Virtual trasformation works of course, but first I have to search for the pictures and correct them. This is not optimal.

Robert

[EDIT]

I have created now a "wokflow category"

"@MetadataTag[orientation,regexp,^Rotate 270 CW]" AND "IMatch Standardkategorien|Olympus Corporation"

But how I can search for Images with this criteria wich are "not virtual trasformed"?

[/EDIT]

[Mario]

There is no filter for that, sorry.

[RobiWan]

Is there a chance that there will be implemented in Version 2020?

Robert

[Mario]

A filter for files with virtual transformations?

As far as I recall this was never requested and I doubt many users will ever have a use for this.
Why don't you just use a Metadata Filter based on the EXIF Orientation to find all files with non-default orientation and then eyeball / select the files needing a transformation and rotate?

[RobiWan]

And that's the problem. I have now about 3000 pictures of the camera in portrait format. I can shoot them all today. If new shots come later, then I will select only the new images
Other consideration to it. Can I add shooting date to my previous workflow?
like this one?

"@MetadataTag[orientation,regexp,^Rotate 270 CW]" AND "IMatch Standardkategorien|Olympus Corporation" AND Images taken between 01.11.2019-31.11.2019

Robert

[Mario]

Why not making a data-driven category based on a variable? This gives you lots of options.

[RobiWan]

That's just because -- I have no idea how I could realize it.

I have now tried
"@MetadataTag[orientation,regexp,^Rotate 270 CW]" AND "IMatch Standardkategorien|Olympus Corporation" AND "@MetadataTag[datecreated,between,2019:03:01,2019:03:03]"

but it's not work corectly. Only the year is evaluated from the last part.

Robert

[Mario]

See Variables for more information about IMatch variables.

[RobiWan]

Maybe I'm wrong but I don't see how the variables can help me here.
In the first step I found the images with the workflow rule (see above)
Now it is about the future and I would like to find e.g. 1 time in the month pictures which are not turned yet and just turn. So I have to start again a search where first all pictures from the camera are rotated and then limit the time frame. And I always have to adjust this time frame manually as needed. Or do you have another / better idea?

Robert

[thrinn]

Maybe you can start with the Timeline view. Select the date interval or month you are interested in and add a filter with your already defined formula category to identify rotated images.
Or you combine yor formula with one of the collections like "Added today" etc.

[Mario]

That's what I would do. The timeline is designed for this purpose.
Do the rest with the filter panel.