Exif reading problems (Orientation and GPS)

[KchoPrro]

Hello friends:

For some time now (I do not know how long exactly) I have verified that iMatch 2019 does not finish reading the exif data of my RAW files of my Canon EOS 7DMkII when generating the thumbnails. The orientation (vertical) is not shown in the thumbnail but the image is displayed correctly if we see it in full screen.

The thumbnails in other programs such as GEO Setter, Canon DPP or the Windows file system itself show the vertical orientation of the RAW well, so I have ruled out a problem in the EXIF data storage or RAW itself.

I give some examples:


Canon DPP


GeoSetter


Windows


Imatch 2019

[KchoPrro]

This does NOT happen in the JPG files, the thumbnails are shown correctly in vertical.

On the other hand, iMatch does not detect in the RAW files that GPS data exists (embedded with the GeoSetter program), however, there are no problems with the JPG files (photos from my Smarphone).

I have solved the problem, this is what I do:

1º I select all the vertical format photos.
2º I select the option "Rotate And Transform" -> "Orientation (Exif)".
3rd Select the option "Rotate 90º Counter clock-wise"



After these steps, iMatch updates the thumbnails after a few seconds (depending on the number of photos, if they are minutes they can be minutes) and updates the thumbnails in vertical orientation.

Interestingly, when updating the thumbnails, the GPS data icon also appears and, indeed, I am sending the EXIF ​​data in iMatch and now the GPS data is there.

With the horizontal photos I do not need to do anything, but if I want Imatch to read the GPS data of the EXIF, I have to do the same steps as before, but in this case, with the option "Normal (No Rotation)." In the previous case, Imatch updates the thumbnails and they appear with the GPS icon and I can see them in the Imatch EXIF ​​information (metadata).

In the following example, it can be seen that Imatch is updating the thumbnails in which the "Normal (No Rotation)" option has been used and they already show the GPS data icon. In the non-updated images, they are not shown, although the data is the same:



Note that Imatch, in this Imatch process, generates the .xmp files

Is it possible that iMatch correctly visualized the orientation without having to do all this process? and with the GPS data?

Thank you!

[Mario]

All the screen shots don't help much.
You did not even include an IMatch Log file which would how is if IMatch or ExifTool or the WIC codec or a 3rd party image library has problems processing your files.

Please provide:

1. Sample image which exhibits this behavior
If the image is too large to attach, upload to your cloud space and post a link.
You can also send the image to support email address. Include a link back to this topic in your email, else it may be deleted as SPAM.

2. Information about the installed WIC codecs on your system if the file is a RAW file.
Use WIC Diagnostics for that and attach the result.

3. Which RAW settings do you use? Have you enabled the "Prefer photools.com RAW processing" under Edit > Preferences > Application?

Orientation has nothing to do with "finishing reading the EXIF data". IMatch reads the EXIF data for your files via ExifTool, but loads and processes image data (and the orientation) using the WIC codecs installed on your system or 3rd party image libraries, depending on the format.

[KchoPrro]

All the screen shots don't help much.
You did not even include an IMatch Log file which would how is if IMatch or ExifTool or the WIC codec or a 3rd party image library has problems processing your files.

Please provide:

1. Sample image which exhibits this behavior
If the image is too large to attach, upload to your cloud space and post a link.
You can also send the image to support email address. Include a link back to this topic in your email, else it may be deleted as SPAM.

2. Information about the installed WIC codecs on your system if the file is a RAW file.
Use WIC Diagnostics for that and attach the result.

3. Which RAW settings do you use? Have you enabled the "Prefer photools.com RAW processing" under Edit > Preferences > Application?

Orientation has nothing to do with "finishing reading the EXIF data". IMatch reads the EXIF data for your files via ExifTool, but loads and processes image data (and the orientation) using the WIC codecs installed on your system or 3rd party image libraries, depending on the format.

ok, I upload the data.

[KchoPrro]

Attached logs.

Sorry, but I do not use Imatch as a RAW processor, I prefer Canon DPP. In any case, I do not process the photos, I keep them with Imatch as I copy them from the SD card. Once I have all the photos in Imatch, cataloged, it is possible to try the RAW with an external processor from iMatch ("Open With dpp4.exe"), but 300-500 photos of a session, can be 2 or 3 photos.

Do you need an affected RAW file ?, I ask it because it happens with all the vertical photos (orientation), and with 100% of the photos that have GPS data embedded.

[Mario]

When I understand all the info you have posted correctly, your problem is that IMatch displays some of your CR2 files with the wrong orientation. Is this correct?

For loading thumbnails and files for the Viewer, IMatch uses the installed WIC codec (the default Microsoft WIC codec in your case)
If the WIC codec delivers the wrong orientation or your files have a physical image orientation that does not match the EXIF orientation recorded, IMatch will display the file rotated wrong. IMatch has no way to tell if the EXIF orientation or physical data arrangement in the RAW is correct.

I will need a sample file so I can see what the orientation is, what the Microsoft WIC codec makes of it, etc.

[KchoPrro]

When I understand all the info you have posted correctly, your problem is that IMatch displays some of your CR2 files with the wrong orientation. Is this correct?

That's right, but they are NOT some, they are all vertical orientation files.

For loading thumbnails and files for the Viewer, IMatch uses the installed WIC codec (the default Microsoft WIC codec in your case)
If the WIC codec delivers the wrong orientation or your files have a physical image orientation that does not match the EXIF orientation recorded, IMatch will display the file rotated wrong. IMatch has no way to tell if the EXIF orientation or physical data arrangement in the RAW is correct.

But then ... why do the thumbnails show up well in other applications such as Canon DPP, GeoSetter and the Windows Operating System itself through its RAW Codec ?. If it only happens in Imatch, a problem should be ruled out in the EXIF file since the orientation of the file the rest of applications show it correctly.

In addition, it is only a problem in the thumbnails, when I click on the option to see the image it shows it in full screen correctly (you can see it in the previous image capture):

I will need a sample file so I can see what the orientation is, what the Microsoft WIC codec makes of it, etc.

Ok, I see how to upload a RAW CR2 file

[Mario]

1. As I said, this is usually never a problem. Something with your files is different.

2. DPP does use WIC codecs. I don't know what GeoSetter does. Windows Explorer uses WIC codecs so the result should be the same in IMatch and Windows Explorer. It usually is. See 1. above.

3. Canon is the only of the good camera vendors which does not offer their own WIC codecs. A shame, really.

When I have a sample file, I can tell you more. From experience, such problems are usually caused by a) the EXIF orientation in the RAW being wrong or b) the embedded preview does not march the EXIF orientation of the RAW data. IMatch by default uses the embedded preview in the RAW file to produce the thumbnail.

[KchoPrro]

1. As I said, this is usually never a problem. Something with your files is different.

I do not think so.
I am reviewing the date on which it has begun to happen to me and I notice that the problem appears from the folder 01-03-2019 (the folder 01-19-2019 has vertical photos and they are shown correctly, in the rest of the folders until the folder 01-03-2019 I simply did not take pictures in vertical format). From that date onwards, the vertical orientation is NOT shown in the thumbnails (the vertical orientation is the correct one). Also, the GPS labels and their data have stopped showing in the files in iMatch (it does not happen in other applications such as GeoSetter and Canon DPP, nor in Windows). I have not changed anything before that date, the camera and its configuration is the same.

I updated Imatch on those dates twice (09-02-2019 and 03-03-2019), could the problem come from any update of those dates?

2. DPP does use WIC codecs. I don't know what GeoSetter does. Windows Explorer uses WIC codecs so the result should be the same in IMatch and Windows Explorer. It usually is. See 1. above.

I share your opinion, if Canon DPP, Windows and GeoSetter show the thumbnails correctly, I do not understand why Imatch does not do it. You are only able to do this when you update the thumbnails.

3. Canon is the only of the good camera vendors which does not offer their own WIC codecs. A shame, really.

When I have a sample file, I can tell you more. From experience, such problems are usually caused by a) the EXIF orientation in the RAW being wrong or b) the embedded preview does not march the EXIF orientation of the RAW data. IMatch by default uses the embedded preview in the RAW file to produce the thumbnail.

I attached a download link of a RAW file in vertical, simple photo made yesterday:

https://we.tl/t-i3lwfj4J0k
(The link will be active 7 days)

The RAW file is as it came from the camera, it does not have GPS data embedded, I have not even changed the name with Imatch. I do not see the thumbnail either, I think that Imatch does not generate the thumbnails correctly because it does not read fully the exif data where the orientation and GPS data could be.

So I see the RAW of the link:


Thanks for helping

I pass a download link of a RAW file in vertical, simple photo made yesterday.

[Mario]

I have downloaded the file.

Findings:

1. The EXIF data is of course read completely by ExifTool.
2. I get consistent results (wrong rotation) for the thumbnail and Viewer / Quick View Panel when I use the option "Use embedded Preview" under Edit > Preferences > Cache. This is the default.
3. When I disable this and force IMatch to develop the full RAW, I get a correctly rotated thumbnail but still the wrong orientation in the Viewer.
4. The EXIF data extracted by ExifTool reports that the file needs to be rotated 270° clockwise.
5. When IMatch is loading the file via the WIC system in IMatch, WIC does not find any usable EXIF orientation flag and hence the file is not rotated in the Viewer or Quick View panel.
IMatch uses two different WIC metadata tags to determine the orientation. This is the official way as documented by Microsoft.
Both are empty for your file so no rotation is performed. I have never seen this before.
Either Windows WIC is incompatible with your file or the EXIF orientation is stored in a way that prevents WIC from reading it or I need to figure out yet another way to make Windows WIC apply the orientation.

6. I now tried the IMatch RAW processing based on LibRaw. Edit > Preferences > Application: Prefer photools.com RAW processing.
This avoids using WIC and uses open source LibRaw RAW processing library instead.

Here I get again different results.
When I allow LibRaw to use the embedded preview in your file, it determines that the file needs to be rotated 90° counter-clockwise and thus produces a rotation that is the opposite we see when we process your file using Windows WIC. Doh! When I change my code to ignore the required rotation as reported by LibRaw, the preview is displays correct.

When I disable the option to use the embedded preview, LibRaw loads the full RAW data and displays the file in the correct orientation. it determines an orientation of (default, don't rotate) in this case.

Summary:

The RAW data and preview data in your file, in combination with the IFD0 EXIF data, confuses both the WIC subsystem and LibRaw. A rather unique case, I must say.

I can try to ask Microsoft about this, but I would not expect an answer (or at least not within a couple of months).
I don't know what firmware produced this file, but Windows WIC finds no rotation info at all and LibRaw apparently determines the correct orientation (the 90° counter-clockwise orientation applied by LibRaw matches the 270° clockwise orientation I see in the IFD0 EXIF record in IMatch.

But applying the 90° ccw rotation to the preview data causes the image to be rotated wrong!

There is definitely something wrong with the EXIF data for this file. Or the EXIF data for ether the thumbnail, or the embedded preview or the RAW data...
Maybe it does not match the physical image data.

To Fix this:

I used the Command > Image > Orientation (EXIF) to change the EXIF orientation in the file to "Normal (No Rotation)".

Now the file displays correct using the default Windows WIC processing pipeline in IMatch. For both modes (use embedded preview on or off).

LibRaw still rotates the image wrong when I use the standard option to use the embedded preview. It still reports that the file needs to be rotated by 90° ccw.
The RAW data still loads correct. This seems to be independent from whatever EXIF orientation is in the file...

Don't recall a similar case. Not much I can do about it. Window WIC is developed by Microsoft and the LibRaw is an open source project developed by volunteers.
I can try to find out more, but that can take a couple of weeks.

[KchoPrro]

I have downloaded the file.

Findings:

1. The EXIF data is of course read completely by ExifTool.
2. I get consistent results (wrong rotation) for the thumbnail and Viewer / Quick View Panel when I use the option "Use embedded Preview" under Edit > Preferences > Cache. This is the default.
3. When I disable this and force IMatch to develop the full RAW, I get a correctly rotated thumbnail but still the wrong orientation in the Viewer.
4. The EXIF data extracted by ExifTool reports that the file needs to be rotated 270° clockwise.
5. When IMatch is loading the file via the WIC system in IMatch, WIC does not find any usable EXIF orientation flag and hence the file is not rotated in the Viewer or Quick View panel.
IMatch uses two different WIC metadata tags to determine the orientation. This is the official way as documented by Microsoft.
Both are empty for your file so no rotation is performed. I have never seen this before.
Either Windows WIC is incompatible with your file or the EXIF orientation is stored in a way that prevents WIC from reading it or I need to figure out yet another way to make Windows WIC apply the orientation.

6. I now tried the IMatch RAW processing based on LibRaw. Edit > Preferences > Application: Prefer photools.com RAW processing.
This avoids using WIC and uses open source LibRaw RAW processing library instead.

Here I get again different results.
When I allow LibRaw to use the embedded preview in your file, it determines that the file needs to be rotated 90° counter-clockwise and thus produces a rotation that is the opposite we see when we process your file using Windows WIC. Doh! When I change my code to ignore the required rotation as reported by LibRaw, the preview is displays correct.

When I disable the option to use the embedded preview, LibRaw loads the full RAW data and displays the file in the correct orientation. it determines an orientation of (default, don't rotate) in this case.

Summary:

The RAW data and preview data in your file, in combination with the IFD0 EXIF data, confuses both the WIC subsystem and LibRaw. A rather unique case, I must say.

I can try to ask Microsoft about this, but I would not expect an answer (or at least not within a couple of months).
I don't know what firmware produced this file, but Windows WIC finds no rotation info at all and LibRaw apparently determines the correct orientation (the 90° counter-clockwise orientation applied by LibRaw matches the 270° clockwise orientation I see in the IFD0 EXIF record in IMatch.

But applying the 90° ccw rotation to the preview data causes the image to be rotated wrong!

There is definitely something wrong with the EXIF data for this file. Or the EXIF data for ether the thumbnail, or the embedded preview or the RAW data...
Maybe it does not match the physical image data.

To Fix this:

I used the Command > Image > Orientation (EXIF) to change the EXIF orientation in the file to "Normal (No Rotation)".

Now the file displays correct using the default Windows WIC processing pipeline in IMatch. For both modes (use embedded preview on or off).

LibRaw still rotates the image wrong when I use the standard option to use the embedded preview. It still reports that the file needs to be rotated by 90° ccw.
The RAW data still loads correct. This seems to be independent from whatever EXIF orientation is in the file...

Don't recall a similar case. Not much I can do about it. Window WIC is developed by Microsoft and the LibRaw is an open source project developed by volunteers.
I can try to find out more, but that can take a couple of weeks.

Thank you very much Mario for such an elaborate response.

Yes, it seems like something weird. For me it is not a major problem, it allows me to work with iMatch normally, only the vertical thumbnails do not show correctly but I can live with it because everything else works well (for this reason, I have been several months, now that I have time I have decided consult it).

The solution you propose does not convince me, Mario. If I use the command "Normal (No Rotation)" it definitely leaves all the vertical images in horizontal format, both the thumbnail and the preview, but I also transfer the problem to Canon DPP, Windows and GeoSetter, that is, leave the photos verticals in horizontal format, incorrectly rotated. To solve this problem and that does not affect the rest of applications, only in the vertical photos, what I do is use the command "Rotate 90º Counter Clockwise" (only for vertical images). With this solution I rotate the thumbnails when updating the file, the preview remains correct and does not affect the rest of applications. Also, when updating the RAW, it also shows me the GPS tag (you do not mention this in your answers, but it must be related because Imatch does not show me the coordinates in the EXIF ​​either, it only does it when it updates the data).

The option "Normal (No Rotation)" I use it for the horizontal files, but I do not do it for the orientation since it is correct (horizontal) but because this way I get Imatch to update the file and show me the GPS tag.

I add a curious fact. Yesterday I revealed all the RAW's of the folder with Canon DPP and saved the changes. Imatch automatically detected the changes and updated all the files and showed the thumbnails correctly. The solution is because Imatch refreshes or updates the data, takes a few minutes if there are several files, but corrects the problem.

And other data to keep in mind, the vertical photos I make with my Samsung phone in vertical (JPG) are displayed correctly. I have to try a RAW from my other camera, Canon EOS 40D and, another test that I will do is to try with my current camera the same image in RAW and in JPG to see how the IMatch shows them.

One question, is there any way for IMatch to update the information in the files? Refreshing the cache does not solve it, I only think that when the file is updated, either because another program has made some change (in this case, Canon DPP) or because the IMatch itself used the options of Rotate And Transform (Orientatio EXIF).

I just upgraded IMatch to version 2019.6.2 although I do not think that will solve the problem.

If you allow me, I will upload another RAW file shot with the same camera, with the same firmware before it detected the problem of rotation and GPS.

[KchoPrro]

Hi Mario!

Attached another file RAW, vertical, made with the same camera (Canon EOS 7D MkII), with GPS data embedded with GeoSetter and that IMatch shows without problems its orientation (only orientation, does not indicate anything regarding the GPS tag and its values):

https://we.tl/t-UkIpA07cR1

On the other hand, I can confirm that if I convert the RAW to JPG with Canon DPP, IMatch correctly shows the JPG (which has the same EXIF data as the RAW) but it is not so with the RAW:



Some thumbnails show the correct orientation, others do not. All of them show the GPS tag. This folder was already updated with the modification of the orientation according to EXIF (90º) but the data was not updated in all cases, some photos were not refreshed. I will insist

[Mario]

If you have actually modified the EXIF GPS data with GeoSetter, you did the same I did when modifying the EXIF orientation. In both cases ExifTool rewrites the entire EXIF record, which fixes the problem Window s WIC seems to have with your files. Why LibRaw is unable to detect the orientation correctly in your files is unknown to me. My diagnosis is complete. Nothing more I can do.

[sinus]

Without looking big, I just want to reproduce my observation with a Nikon D750.
I don't know if this has anything to do with this problem or not.
Personally, I never saw this as a problem, but simply as a little oddity.

I have the camera on the studio tripod, camera upright (vertical).
Then I take various shots without moving the camera, just pressing the trigger.
Then it's quite normal for me that some of the shots are high in IMatch, some are transverse.
See attachement (all images are raw-nefs).

Up to now I have simply attributed this to the camera, I thought that the camera is probably exactly at a border where a "draft" is enough to tell the camera that the camera is now horizontal or vertical.
And that the camera then somehow writes that somewhere in the Exif.

It never bothered me, it only happens when I put the camera on the edge, but then I thought, ok, when I press the shutter release button, the camera is just a hundredth of a millimeter high, then across again.

I don't know if this has anything to do with the problem here.

[KchoPrro]

If you have actually modified the EXIF GPS data with GeoSetter, you did the same I did when modifying the EXIF orientation. In both cases ExifTool rewrites the entire EXIF record, which fixes the problem Window s WIC seems to have with your files. Why LibRaw is unable to detect the orientation correctly in your files is unknown to me. My diagnosis is complete. Nothing more I can do.

Ok, thanks for the help Mario, as I said, it's not a major problem, I can continue to work with the rotated thumbnails or rotate them manually. I'll wait for an update, hopefully, to solve it alone.

Without looking big, I just want to reproduce my observation with a Nikon D750.
I don't know if this has anything to do with this problem or not.
Personally, I never saw this as a problem, but simply as a little oddity.

I have the camera on the studio tripod, camera upright (vertical).
Then I take various shots without moving the camera, just pressing the trigger.
Then it's quite normal for me that some of the shots are high in IMatch, some are transverse.
See attachement (all images are raw-nefs).

Up to now I have simply attributed this to the camera, I thought that the camera is probably exactly at a border where a "draft" is enough to tell the camera that the camera is now horizontal or vertical.
And that the camera then somehow writes that somewhere in the Exif.

It never bothered me, it only happens when I put the camera on the edge, but then I thought, ok, when I press the shutter release button, the camera is just a hundredth of a millimeter high, then across again.

I don't know if this has anything to do with the problem here.

Well I think it may be related but it does not seem exactly the same problem because in my case it happens to me with 100% of the vertical files and they are only the thumbnails. In your case it happens with some and not with others, it also seems weird.

Does it also happen with the preview or only in the thumbnail?

[Mario]

@Sinus

Check the EXIF orientation of your files in the Meta Panel oder the ECP.
If the EXIF orientation looks correct, there are 3 possible reasons for this to fail:

The EXIF orientation flag does not match the physical orientation of the image data.
The installed WIC codec (depends on which you use) does not handle the orienation
WIC is unable to determine the orientation.

Shooting portrait on a tripod is a known problem case for some cameras, especially if the camera is tilted. This may confuse the orientation sensor. Often it depends on a fraction of a degree.

This has to be checked for each image of course.

I shot Nikon cameras (old and new) and I have never noticed a similar problem. I use tripods only occasionally, and then most often a monopod, not my 3-leg pod.

[Belenos2017]

It seems to me, that I have the same problem - but only since some weeks. I use Win7 64bit and Imatch2019 - both with all updates, Camera Canon 5DMarkIII, no GPS.
I made a Test:
On 2019.03.12 I had imported a vertical CR2-picture  - and Imatch shoed it imediatly correct with a vertical thumbnail.
Today I took the same CR2-picture from my backup without any sidecarfiles - made a new Import to the actual version of Imatch 2019.5.2 - and now the Thumbnail is wrong: horizontal.

Could that Info hel?

[sinus]

Well I think it may be related but it does not seem exactly the same problem because in my case it happens to me with 100% of the vertical files and they are only the thumbnails. In your case it happens with some and not with others, it also seems weird.

Does it also happen with the preview or only in the thumbnail?

Only in the thumbnail, QuickView and Viewer are correct.

[KchoPrro]

Well I think it may be related but it does not seem exactly the same problem because in my case it happens to me with 100% of the vertical files and they are only the thumbnails. In your case it happens with some and not with others, it also seems weird.

Does it also happen with the preview or only in the thumbnail?

Only in the thumbnail, QuickView and Viewer are correct.

I think something happens in IMatch when generating the thumbnail that can not get to read correctly the metadata / Exif of the Orientation. In other applications such as ... Adobe Lightroom, etc. you see the miniature well, right ?. Have you tried using the function with the selected file "Rotate And Transform / Orientation (Exif) / Rotate 90º Counter Clockwise"? This should work, it works for me, although I hope that, in the future, I do not have to do this with all the vertical photos.

It seems to me, that I have the same problem - but only since some weeks. I use Win7 64bit and Imatch2019 - both with all updates, Camera Canon 5DMarkIII, no GPS.
I made a Test:
On 2019.03.12 I had imported a vertical CR2-picture  - and Imatch shoed it imediatly correct with a vertical thumbnail.
Today I took the same CR2-picture from my backup without any sidecarfiles - made a new Import to the actual version of Imatch 2019.5.2 - and now the Thumbnail is wrong: horizontal.

Could that Info hel?

Well I think we have the same problem, I suppose that in Canon Digital Pro you will see the thumbnails correctly, even in the Windows folders themselves, it only happens in IMatch ..., if it is the case, it seems that there is no solution, just use the rotation menu depending on the IMatch EXIF, but this also generates an .xmp file

In my case, in addition, the rotation menu based on IMatch's EXIF helps me to update GPS data that is not taken initially (it is the only program I use that is not capable of displaying GPS data).

I think something happens that prevents IMatch from reading the EXIF data correctly, unless we manually indicate that it does so using the rotation menu.

In any case, you must forgive my ignorance in computer science, possibly it is not a problem of IMatch, it is another question but that affects the way of working of IMatch.

[sinus]

Uh, just now, I tried to do a rescan with "force update" and see:

all is fine now, the thumbs are correct now.

I tried the same with some older and with new files, all is correct now.

I work with the newest version 2019.6.2.

OK, I tried this with some new files from yesterday, means the same version.

Yesterday, after a normal scan into IMatch with new nefs, some have been wrong turned.
But only the thumb was wrong.
Just now, with the same version, I did a rescan "force update" ... and now also this thumb is correct.

So, do a forced rescan seems to solve this for me.

[KchoPrro]

Uh, just now, I tried to do a rescan with "force update" and see:

all is fine now, the thumbs are correct now.

I tried the same with some older and with new files, all is correct now.

I work with the newest version 2019.6.2.

OK, I tried this with some new files from yesterday, means the same version.

Yesterday, after a normal scan into IMatch with new nefs, some have been wrong turned.
But only the thumb was wrong.
Just now, with the same version, I did a rescan "force update" ... and now also this thumb is correct.

So, do a forced rescan seems to solve this for me.

Can you please explain how you "force update"? (Steps, please!  )

[Mario]

Select files in file window, then Shift+Ctrl+F5.
Also available as a command in the context menus of folders and the file window.

@sinus:

Is this reproducible? Maybe this is some sort of stress issue on your system? When IMatch indexes folders it does many things in parallel, including reading many images in parallel. If this somehow causes an issue with the WIC codecs on your system and they deliver the image data wrong somehow... I assume you are use the option to create cache images on-demand, which means that IMatch creates the cache image at a later time, not when the images are indexed. But then, when you do a force rescan, IMatch creates the thumbnail and the cache image at the same time (when a cache image exists). But the code is the same, during regular indexing of new images the part for creating the cache image is just skipped.

Do you have a NEF file which allows to reproduce this? I mean a file which produces a wrong thumbnail when you add it to a database for the first time, but becomes correct when you later do a forced rescan? If I can reproduce this here, I may be able to fix this. Also let me know which WIC codecs you use.

[sinus]

Some additional infos, maybe helpful.

Yesterday I was on tour with my Nikon D750.

In the evening I let scan into IMatch 369 files.
65 of these files have been vertical images (hochkant).

32 of these files has been the wrong orientation in IMatch, but only the thumbs.
In the orientation is written "Rotation 270 CW", in the correct AND in the wrong rotated files the same.

Just now, I selected all these files, did a force rescan (Ctrl Shift F5, then "Force Update") and all thumbs are now correct.
The version is the same, the newest one.

[KchoPrro]

Select files in file window, then Shift+Ctrl+F5.

Ok, thanks !!, I used Shift + F5 to rescan but it did not solve the problem. With Ctrl. + Shift + F5 I have the option to Force Update and, in this case, the GPS data that had not been read initially appears. Unfortunately I do not have any Vertical photo to check it (I've already corrected them all, I've been doing it all morning), but this afternoon I'll take more pictures and check that this works for me with the orientation because it would be a great step forward !!

Some additional infos, maybe helpful.

Yesterday I was on tour with my Nikon D750.

In the evening I let scan into IMatch 369 files.
65 of these files have been vertical images (hochkant).

32 of these files has been the wrong orientation in IMatch, but only the thumbs.
In the orientation is written "Rotation 270 CW", in the correct AND in the wrong rotated files the same.

Just now, I selected all these files, did a force rescan (Ctrl Shift F5, then "Force Update") and all thumbs are now correct.
The version is the same, the newest one.

I think it's the solution, I can not test with my vertical images now but I'm pretty much convinced that it will also show me the thumbnails correctly after forcing update.

[Mario]

Some additional infos, maybe helpful.

Yesterday I was on tour with my Nikon D750.

In the evening I let scan into IMatch 369 files.
65 of these files have been vertical images (hochkant).

32 of these files has been the wrong orientation in IMatch, but only the thumbs.
In the orientation is written "Rotation 270 CW", in the correct AND in the wrong rotated files the same.

Just now, I selected all these files, did a force rescan (Ctrl Shift F5, then "Force Update") and all thumbs are now correct.
The version is the same, the newest one.

Please send me one of the files which produce the error.
And also the ExifTool output panel logs and the IMatch log file from that session where you experienced the problem.
Only knowing about the problem will not help solving it. We need as much technical data from your machine and at least one example NEF file.
I have just added a couple of hundred NEF files from yesterday (two camera models) . No problems with orientation at all. All portrait and landscape images show correctly. All metadata imported of course.

Did you run other software while IMatch was running? Especially software from Adobe?

[Mario]

the GPS data that had not been read initially appears. images now but I'm pretty much convinced that it will also show me the thumbnails correctly after forcing update.

This sounds more like a locking file issue or a stress issue. Do you use a virus checker? When ExifTool could not read the GPS data, what error message was logged to the IMatch log file?
It is very unusual that ExifTool cannot read data from a file. And you say that only the GPS data was missing?

Do you run Adobe software at the same time you run IMatch?
Adobe has the habit of locking files or writing back metadata changes in the background, which often causes strange problems...

[KchoPrro]

the GPS data that had not been read initially appears. images now but I'm pretty much convinced that it will also show me the thumbnails correctly after forcing update.

This sounds more like a locking file issue or a stress issue. Do you use a virus checker? When ExifTool could not read the GPS data, what error message was logged to the IMatch log file?
It is very unusual that ExifTool cannot read data from a file. And you say that only the GPS data was missing?

Do you run Adobe software at the same time you run IMatch?
Adobe has the habit of locking files or writing back metadata changes in the background, which often causes strange problems...

Usually not. My work routine is usually like this:

1) I open IMatch.
2) I add a new folder that I rename with the date of realization of the photos (for example, 20-06-2019).
3) I add the properties to the folder in IMatch.
4) From IMatch, I indicate to open the folder with the Windows Explorer.
5) I download all the photos of the SD card to the folder created, now open in Windows.
6) IMatch is recognizing and updating the data of the images. After a few minutes I have all the images in IMatch. The thumbnails of the vertical images are incorrect (only the thumbnails, as I have already explained).
7) I rename all the images with IMatch (great !, it takes only 1 second even if there are hundreds of photos!).
8 ) Open GeoSetter and embed the metadata of "location, city, author, etc."). I also add the GPS location and save the changes (3 months ago, when I did not have the problem with IMatch, after this step and after a few seconds, IMatch already showed me the GPS tag).
9) If I am interested in processing an image, from IMatch, I open the image with the Canon DPP RAW processor and save the changes (IMatch recognizes this, when updating the file, it shows me the correct orientation of the model and if it has GPS coordinates , now when updating, it shows me the label).
10) Canon DPP finished the process of editing the image in Adobe Photoshop.

In summary, that the process of cataloging the images with IMatch does not involve another program.

Other times I have Adobe Photoshop programs open when I import the images to IMatch but I do not see any differences in that.

On the other hand, it is still curious that this happened to us from a few months ago to the present (since the end of February 2019 / beginning of March).

IMatch does not register any errors, only the orientation of the thumbnails (incorrect) and GPS data (appear) fails.

And another important issue is that it only happens to me with the RAW files (.CR2), with the JPG files none of the two things happen, in fact, in the same folder there are photographs taken with my Smarphone and the orientation is correct, and the GPS data appear (this I already mentioned at the beginning).

On the other hand, comment that I work with 4GB of RAM and W10 x64, I think possibly if it could be a problem of stress in the process, but I do not know.

[Mario]

Run IMatch with debug logging and keep an eye on warnings or errors reported by ExifTool in the log and the ExifTool output panel.
Details are in the IMatch help and here log file.

As I said in my analysis, WIC does not find usable orientation info in your RAW files, even when I process only one file. No stress issue.
I did all the many tests I've described using the "force update" command. The metadata in the files is neither read correctly by Windows WIC nor LibRaw. Only when you "fix" the metadata by rewriting it with ExifTool (setting GPS data in GeoSetter (you know that IMatch has very powerful functions for that?) or setting the EXIF orientation to "none", WIC can read the file properly. LibRaw still fails to figure out the correct data, or looks at some other tag, I dunno.

My analysis is complete. All I could learn from your problem file was reported above, including the solution found.

[Belenos2017]

On the other hand, it is still curious that this happened to us from a few months ago to the present (since the end of February 2019 / beginning of March).

I have the same problem since March 2019: The identical CR2-Files produced correct thumbnails in earlier times, and produce now wrong orientated thumbnails.
I didnt work with GPS in these files, I use Win7 64bit.
DXO opens from imatch in correct Orientation. After Importing the jpg-file in Imatch the CR2 thumbnail turns because of their relation original/version.

What happend since that time with Windows? with exif-tool? with imatch?

[Mario]

Please provide a sample file which exhibits this behavior.
ExifTool is not used when IMatch extracts thumbnails or previews for RAW files.
Do you use WIC codecs? Which? The codecs on Windows 7 are quite old any may not be updated anymore by Microsoft.
Show us a https://www.photools.com/help/imatch/#wic_diag.htm result.

Can you also "solve" the problem by selecting one file in a file window and then pressing Ctrl+Shift+F5 > Force Rescan?
If so, we have another possible hint.

I would need a sample image which shows this behavior...

[Belenos2017]

Hi Mario,

- the Download-Link of an exampel-File https://we.tl/t-uBy6Wn7GjF
- the WIC-Diagnosis of that file in attachment
- forced update with strg/shift/F5 does not change the Thumbnail
- the viewer shows a horizontal picture, even though the thumbnail had changed after JPG-development

Thanks a lot!

[Mario]

I have downloaded your file, thank you.

No problems reading the file with the standard Windows WIC codecs or the FastPictureViewer codecs.

Your system has no WIC codecs installed (!) so IMatch has to fall back to using LibRaw. LibRaw.
See https://www.photools.com/1167/wic-support-codec-availability/ for download and installation instructions, even for Windows 7.

I only get a wrong orientation when I

a) Use LibRaw (as in your case because your system is lacking the standard WIC codecs) and
b) enable the "Use embedded Preview" under Edit > Preferences > Cache.

LibRaw tells IMatch to rotate the image by -90 degrees, but that seems to be wrong. -90 counter-clockwise is the same as the 270 clockwise, but applying it to the image returned by LibRaw produces a wrong orientation. No idea why this is the case.

I see two solutions:

A) Install the missing WIC codecs on your system.
Then select the files with problems and press Shift+Ctrl+F5 > Force Update.
This is the preferred solution.

B) Alternatively, go to Edit > Preferences > Cache and disable the option to use the embedded preview.
Then select the files with problems and press Shift+Ctrl+F5 > Force Update.
This will cause LibRaw to develop the full RAW but the result will be different than the preview embedded by your camera.


Here is what I get with the standard Windows WIC codecs and with the standard IMatch Cache settings (use preview):

[sinus]

Select files in file window, then Shift+Ctrl+F5.
Also available as a command in the context menus of folders and the file window.

@sinus:

Is this reproducible? Maybe this is some sort of stress issue on your system? When IMatch indexes folders it does many things in parallel, including reading many images in parallel. If this somehow causes an issue with the WIC codecs on your system and they deliver the image data wrong somehow... I assume you are use the option to create cache images on-demand, which means that IMatch creates the cache image at a later time, not when the images are indexed. But then, when you do a force rescan, IMatch creates the thumbnail and the cache image at the same time (when a cache image exists). But the code is the same, during regular indexing of new images the part for creating the cache image is just skipped.

Do you have a NEF file which allows to reproduce this? I mean a file which produces a wrong thumbnail when you add it to a database for the first time, but becomes correct when you later do a forced rescan? If I can reproduce this here, I may be able to fix this. Also let me know which WIC codecs you use.

Mario,
sorry, I guess, I am not very helpful here, because my original nefs are gone into the nirwana.

I usually have no other programs open, if I scan files into IMatch, except firefox.
But I have uploaded the same files as here in the attachement. Some are correct (vertical), some wrongly horizontal.
But these files I had already scaned into IMatch (that is why they have such filenames).

But they are still wrong in my DB. But if I do a rescan, until now, such files are after this correct.

In the uploaded zip I have added the wic-analysis and the log-file.
But the log is maybe not helpful, because it is not the log from the import.

Maybe you can check one of the wrong files and look, if they are also wrong in your system.

The link is: http://www.sinusbild.com/holen/sinus-imatch.zip

[Belenos2017]

.........
I see two solutions:

A) Install the missing WIC codecs on your system.
Then select the files with problems and press Shift+Ctrl+F5 > Force Update.
This is the preferred solution.

Here is what I get with the standard Windows WIC codecs and with the standard IMatch Cache settings (use preview):
..........

Thank very much - THIS WORKS  - erveything correct now! ( CR2 files from Canon EOS 5D Mark III ) - wic diagnosis now okay.

Curious what happend in march 2019 ....

I also downloaded for testing the problem-picture from KchoPrro ( made with Canon EOS7D MarkII ) - that doesnt work well - wic diagnosis says "No Codec" - even though both are CR2-files - very very curious....

[Mario]

I also downloaded for testing the problem-picture from KchoPrro ( made with Canon EOS7D MarkII ) - that doesnt work well - wic diagnosis says "No Codec" - even though both are CR2-files - very very curious....

That can happen. Canon released dozens of different RAW format variants over time, all with more or less subtle changes. Since Canon never documented their RAW formats, Microsoft has to reverse engineer every format they want to support. They may be willing to do this. Or not.  WIC is such a good concept. Windows provides the framework and the camera vendors provide the WIC codec - without the need to reveal their precious RAW format details. And Camera vendors should be able to write the best WIC codecs - they know their cameras in and out, after all.

Unfortunately, Canon let their camera buyers down big time a couple of years by discontinuing their WIC codec. Without reason. It cannot be that expensive to keep up with support. A few developer days per month, max. Nikon still offers a current WIC codec, and other camera vendors released many camera models without changing their RAW formats every time...

If your camera model is not supported by the built-in WIC codecs in Windows and your camera vendor is to shabby to provide you with a WIC codec, your choices are limited. IMatch supports WIC and the LibRaw project - if both cannot read  a RAW file or have problems with the orientation or other attributes, there is not much I can do.

[Mario]

Maybe you can check one of the wrong files and look, if they are also wrong in your system.
The link is: http://www.sinusbild.com/holen/sinus-imatch.zip

I have downloaded your sample files, thanks.

I've just extracted the ZIP file and dropped the folder into an IMatch database.
I used the default settings in IMatch (Installed WIC codec, Cache set to prefer preview, minimal size 2,000 pixel).
IMatch 2019.6.2 and FastPictureViewer codecs (I currently have no access to a system with only the Windows WIC codecs installed)

All files show the correct orientation, for thumbnails and Quick View Panel / Viewer using IMatch defaults (image1.jpg).


Now I switch to LibRaw and recreate all thumbnails and cache images with "Force Update"

1. I get the (consistent) wrong orientation for both thumbnail and cache image when I use LibRaw in combination with "Prefer Preview".

2. I get correct orientation for both thumbnail and cache image when I use LibRaw but set "Use Preview" to off

[KchoPrro]

Hello again friends!

Yesterday I downloaded the new photos from the camera. It is surprising but mysteriously, now everything is shown correctly, it seems magic!

In my opinion, I think it could have been for two reasons (it's just a suggestion, it could be something else):

A) I updated the latest version of IMatch a few days ago to version 2019.6.2. I did not restart the computer until yesterday (when I do not have time, I often leave the computer in sleep mode). Perhaps the new version of IMatch has solved the problem and it has not been effective until the restart of the computer.

B) I left downloading the card while I took advantage to eat and shower, when I returned to the computer were all the correct images. It is possible that before I did not give IMatch time to read all the data, as soon as the photos were downloaded it is possible that I started to work with IMatch when I was still reading and updating files. This is easy to check, I'll do it next time.

Also, yesterday I modified and edited the mode of presentation of the thumbnails, passing from the "Default" mode a new mode, inherited from "Image Info", I added some new fields (Camera Name, File Size, ISO).

@ Belenos2017, your picture now I see it also perfectly, I have not needed to force the update:



@Mario, I know the IMatch GPS options, I started using them but I like GeoSetter even if it's an external application (maybe it helps also because it's the applications I've been using for years and I know it well).

I will observe in these days the behavior of the miniatures, if I detect any novelty I will comment here.

Thank you all!!

[sinus]

Maybe you can check one of the wrong files and look, if they are also wrong in your system.
The link is: http://www.sinusbild.com/holen/sinus-imatch.zip

I have downloaded your sample files, thanks.
...

1. I get the (consistent) wrong orientation for both thumbnail and cache image when I use LibRaw in combination with "Prefer Preview".

2. I get correct orientation for both thumbnail and cache image when I use LibRaw but set "Use Preview" to off

Thanks, Mario, for this.
I will have an eye on my nefs in the next time.
If I get again wrong orientated image, I will set the "Prefer Preview" to off (though the help says, it takes then longer).

Thanks!

[Mario]

A) I updated the latest version of IMatch a few days ago to version 2019.6.2. I did not restart the computer until yesterday (when I do not have time, I often leave the computer in sleep mode). Perhaps the new version of IMatch has solved the problem and it has not been effective until the restart of the computer.

No changes in how IMatch interfaces with WIC for a long time. No updates to LibRaw since March.

B) I left downloading the card while I took advantage to eat and shower, when I returned to the computer were all the correct images. It is possible that before I did not give IMatch time to read all the data, as soon as the photos were downloaded it is possible that I started to work with IMatch when I was still reading and updating files. This is easy to check, I'll do it next time.
ou all!!

You can always see if IMatch is processing things in the background in the Info & Activity Panel
When a file is being processed, it shows a special icon and the thumbnail is dimmed: Icons used in the File Window

[Mario]

Thanks, Mario, for this.
I will have an eye on my nefs in the next time.
If I get again wrong orientated image, I will set the "Prefer Preview" to off (though the help says, it takes then longer).

Using the preview is preferred. Your camera (usually) writes a high-quality JPEG file into the preview, applying all the settings you have made. So the image looks in IMatch as it looks in your camera. The same is true for DNG files, where the producing application / camera is supposed to write an as-intended rendition.

Processing the full RAW will take a lot longer than using the embedded preview and the results will vary widely, depending on the WIC codec you use.

[KchoPrro]

A) I updated the latest version of IMatch a few days ago to version 2019.6.2. I did not restart the computer until yesterday (when I do not have time, I often leave the computer in sleep mode). Perhaps the new version of IMatch has solved the problem and it has not been effective until the restart of the computer.

No changes in how IMatch interfaces with WIC for a long time. No updates to LibRaw since March.

B) I left downloading the card while I took advantage to eat and shower, when I returned to the computer were all the correct images. It is possible that before I did not give IMatch time to read all the data, as soon as the photos were downloaded it is possible that I started to work with IMatch when I was still reading and updating files. This is easy to check, I'll do it next time.
ou all!!

You can always see if IMatch is processing things in the background in the Info & Activity Panel
When a file is being processed, it shows a special icon and the thumbnail is dimmed: Icons used in the File Window

Thanks Mario!!!