Hi,
when using the "Dimensions" in the layout editor to display the image dimensions this will show the dimenstion of embedded JPG for Olympus RAW files (instead of RAW file dimension) . This is usually 2.400x3.200.
Olympus seems to be a little special here, using only "Image Width" and "Image Height" tags, while all? others (and also JPG) uses the "Exif Image Width" and "Exif Image Height" tag for their RAW images.
I have now found a solution to display the correct dimensions also for the Olympus RAW files (and also works with JPG and the other RAW files I've tested).
In the layout editor, use this as "Custom Template"
{File.MD.Exif::Main\256\ImageWidth\0|default:{File.MD.Exif::Main\40962\ExifImageWidth\0}}x{File.MD.Exif::Main\257\ImageHeight\0|default:{File.MD.Exif::Main\40963\ExifImageHeight\0}}
This will first try to use the "Image Width/Height" (used by Olympus RAW files) and in case this is not set it will fallback to "Exif Image Width/Heigt" (used by all? others).
IMatch uses the "original image dimensions" as reported by your WIC codec or LibRaw (depending on what you use to process ORF files).
Run a WIC diagnosis on one of the files to see what the WIC codec and LibRaw can extract from your files. Post the results
As always, contact your camera vendor and ask for an up-to-date WIC codec which handles your ORF variant. There are probably 30 to 50 different ORF variants in use already...
QuoteAs always, contact your camera vendor and ask for an up-to-date WIC codec which handles your ORF variant. There are probably 30 to 50 different ORF variants in use already...
Tried that already because of the image rotation problem of ORF files and WIC codec with very limited success. That's why I use the LibRaw fallback which works fine for me.
See here: https://www.photools.com/community/index.php?topic=9446.msg70380#msg70380 (https://www.photools.com/community/index.php?topic=9446.msg70380#msg70380)
With the sale of Olympus imaging to JIP I have even less hope that something will change for the Oly RAW files in future...
The workaround I found with the custom template is also working OK for me, so maybe it also helps others (Olympus users).
WIC diagnosis results?
attached the WIC Diag of a Portrait Oly ORF file.
But we analyzed that in the past and it was very clear that this is a bug in the WIC when using the embedded JPG (in case it is in portrait orientation).
When processing the RAW with WIC the orientantion is OK.
I don't remember the exact details. The Exif of an portrait .ORF contains:
Orientation : Rotate 270 CW
It was something like the embedded JPG is already stored in correct orientation within the .ORF file, while the RAW data itself is horizontal.
But WIC applies "Rotate 270 CW" to both JPG and RAW, and therefore JPG ends up in wrong orientation. (But as said, not 100% sure about that anymore).
When you check the orientation of a portrait .ORF when using WIC with embedded JPG:
(https://www.photools.com/community/index.php?action=dlattach;topic=10797.0;attach=25706;image)
then you see that the Top of the image is pointing to the right: This is what happens when you rotate the image in correct portrait orientation by the command stored in the exif (Rotate 270 CW). This is why I think the preview JPG is already stored correctly in the ORF file, but WIC codec will rotate it based on Exif tag (Rotate 270 CW). But for .ORF files this rotation tag should only apply for the RAW data itself (WIC using RAW instead of embedded JPG shows correct orientation)
Here how the RAW should be stored in RAW (RawDigger Screenshot -> will show RAW without rotation applied)
(https://www.photools.com/community/index.php?action=dlattach;topic=10797.0;attach=25708;image)
Both WIC and LibRaw report wxh as 5240x3912. That's all IMatch knows.
Maybe send me this sample image for my test library?