Viewer slow on rotated images

[OffPeak]

I've tried to search for this subject, but have not been able to find it.

I recently moved an IMatch photo database to a newer, faster computer (using Pack&Go).

I have found an issue on the new machine which I haven't seen before:

(I put the photos in a different folder than the old computer.)

If I rotate a thumbnail, it takes forever (OK, 20 seconds) to open in the Viewer.
If I reset rotation, it appears almost instantly when the Viewer is opened.
If I rotate again, it takes 20 seconds again.
If I do this for more than one thumbnail, it takes 20 seconds for each.  (For the little green check mark to appear in the Viewer.)

I've attached a graphic hopefully illustrating the problem.
I also restarted IMatch, just performed the rotation/unrotation/rotation, and have attached the log file.
Let me know if more information is needed.
Thanks,
Carl Eidbo

[Mario]

This has been reported by one another user, quite a while ago.

The problem was, and apparently is here as well, some sort of weird effect inside Windows DirectX / Direct3D.
IMatch uses a Direct3D function (on the graphic card) to rotate images in the Viewer. Apparently, under some (unknown) conditions, and only for certain (unspecified) images, this rotation, which usually takes maybe 0.2 seconds, takes 5 or more seconds.

Since this is an atomic function inside Windows DirectX, IMatch cannot influence or 'solve' his.
IMatch just calls the function and waits for it to return the rotated image. No options or anything.

From your description I gather (?) that you use virtual rotation inside IMatch to rotate files?
Have you tried to fix the EXIF orientation in the image itself? Or re-save the JPEG files (as a copy) to see if this changes the behavior of DirectX?
Update the graphic driver to the latest version, this often solves such mysterious effects.

Please also produce a log file in debug mode (see log file) because this contains more data. Usually the Viewer is never a problem source and only very little is logged in non-debug mode. I see no operations logged which take 'long' enough to be reported in the normal log.

[OffPeak]

My new computer is kind of a home-brew machine; I bought all the separate parts (two or three years ago), and assembled.
The graphics card is a NVIDIA GEFORCE GTX970, if that is significant.

Anyway, I'm trying a number of methods to avoid virtual rotation.
(EXIF rotation; Lossless rotation; or maybe use a rotation app, not sure what method that would use.)
However, I probably have a LOT of virtually rotated photos from the old computer, and would like to find them.
Is there a way to filter for Virtually Rotated ?

I tried based on orientation, but that wasn't specific enough.

Thanks

[Mario]

Changing the EXIF orientation tag is a lossless method (only updates the metadata).
Are all your virtually rotated files affected by this? This would be most unique. And probably indicates an issue with the graphic card driver or something.
For the other user who reported the problem a year or two back the effect only happened for a few virtually rotated files.

[OffPeak]

I did find a filter for "Virtually Rotated" under File Properties, so I will work with that.

Thanks for your help.

Go to bed; it must be getting late in Germany!

Carl

[OffPeak]

I filtered by Virtually Rotated, and found 205 files.
I created a temporary category, and assigned them all to it.

I clicked the viewer starting at the first file, and it opened right up.
As I progressed, all files opened right up, until approximately the half-way point.

Then the 20 second delay kicked back in.

I then went in reverse, and some of the files that previously opened quickly, had a delay.

I closed the viewer, and repeated the steps above, with about the same results.

[OffPeak]

Files fixed, problems solved.

Thanks Again!

[Mario]

Did you keep the log file from the session where the 20 second delay kicked in?
Maybe it contains some WIC or DirectX error messages. That would be helpful to know.

How did you fix the files?

[OffPeak]

Mario:

I didn't specifically save the log file for the event I reported.
I have a huge standard log file that started at 19:01; I reported the the problem at 19:06, so not sure if it's in there.
I have attached it, but it's 3MB.
(I assume you can read a log file like the guys in The Matrix can read dripping numbers!)

From memory, I think I:
1. (maybe) reset virtual rotation for all 205 files (since they were displayed via a temporary category);
2. selected EXIF (no rotation) for all;
3. then went through them manually, and EXIF-rotated them to the proper orientation.

Didn't take long.

Car

[Mario]

Nothing unusual in the log file.
Quite a number of ExifTool warning about files w/o metadata (normal) and some invalid timestamps (also normal if you have modified your files in other apps and these have not written the date and time data in the correct format). Nothing indicating any issue.

I have removed the log to save space on the server.
TIP: If you ZIP log files before attaching, they compress to maybe 10% to 15% of the original size.