Some issues with v9

Hello,

I just upgraded from v8 to v9 (9.0.0.4) yesterday and I've run into a few problems:

  • The new borders for thumbnails and the image viewer are very obstrusive. There should be an option to revert to the plain borders that v8 was using. And please bring back a proper "make square" option. The new borders make for nice eye candy but they draw to much attention to themselves when you're working with a folder full of photos to sort and evaluate.

  • Auto-rotating images using EXIF alignment information doesn't work properly for me. I'm viewing folders that contain CR2 and matching in-camera JPGs from a Canon 20D. When I first turned the "Use EXIF information" option on, the portrait-oriented CR2s were displayed correctly but the JPGs were in landscape format (both for thumbnails and image viewer). Then I turned it off and now the JPGs were displayed correctly but the CR2s weren't. When I looked at some other folders, it was suddenly working but after fiddling with the EXIF option again and emptying the thumbnails cache, it was again broken. Either the JPGs work or the CR2s but never both of them.

  • Transparent global toolbars don't stay transparent when you press or hover over a button. When the "No higlight border" option is turned off, the selected or default image for the toolbar is shown behind the button. This used to work correctly in v8.

  • When I turn off WindowBlinds compatibility mode, the title bar text is draw one pixel line too low (and the lowest line cut off). See http://szeiger.de/tmp/alignment-bug.png for an example (Windows Explorer left, DirOpus w/o WindowBlinds mode on the right). I'm using a Luna theme with modified colors on XP. No WindowBlinds. With the compatibility option turned on, the gradient backgrounds in the Preferences and Customize window are not drawn correctly. The File Associations window does not suffer from this problem even though it also has a gradient panel. Will this bug be fixed? So far the FAQ simply suggests to turn WindowBlinds compatibility off.

  • The first time I tried Dual Display mode in v9, the Back and Forward buttons on my mouse stopped working for that window. The toolbar and border buttons still worked. After restarting DirOpus, the mouse buttons worked again and I wasn't able to reproduce the problem.

  • The Thumbnail Size control does not appear when I'm in Tiles mode. Is this supposed to work?

You might find you get used to them. If not you can always turn them off completely.

Unless you have a 3rd party RAW-capable shell extension (there are a few), CR2 rotation is handled by the RAW plugin, and even then only currently works if you are doing a full (very slow) image decode for CR2 thumbnails.

If you're using the Opus RAW plugin with preview-image (very fast) decoding then there isn't any auto-rotation at the moment.

If you're using a 3rd party shell extension to provide CR2 thumbnails (if you are then they'll also appear in Explorer) then the rotation of them is up to that extension and, as far as I know, shouldn't be affected by any options in Opus.

I'm not sure how to explain the way that the "use EXIF information" switch in Opus affects the rotation of your CR2 thumbs, though. As far as I know there are no code paths in Opus which could handle CR2 files that would also respect the EXIF option. Is it definitely the case that the option affects CR2 files or have I misunderstood what you said?

If you view the CR2 files in Opus, which viewer plugin is active?

As of Opus 9.0.0.1 the toolbars themselves should stay transparent unless you have the shift key held down, but I presume you're talking about just the individual buttons when you hover over them, which do indeed get filled in (but not the other buttons or the whole toolbar, as happened in 9.0.0.0).

I think I've seen that in the past before with certain fonts/sizes, though I think the example that I found got fixed. Could you tell us the font name and size and the titlebar size that's in use so we can try to reproduce it?

Remember to report bugs to GPSoft as well as the forum. They may not read/remember every message that's posted here and they're the only people who can fix things and tell you when/if they will be fixed.

Which mouse drivers do you use?

No, it's only for Thumbnails mode. Maybe a new slider should be added for Tiles mode.

You might find you get used to them. If not you can always turn them off completely.
[/quote)
Yes, that's what I did.

I'm using your DCRaw Plugin (version 1.1.0.1). I've done some more experimenting and it seems that the CR2 rotation is actually not negatively affected by turning on EXIF usage. On the contrary, without the EXIF option, the thumbnails are always unrotated. But it's affected by the thumbnail cache! When a new thumbnail is created for a CR2, it's always unrotated, but when it comes from the cache and EXIF usage is turned on, it is rotated correctly.

Furthermore, the rotation of a CR2 in the standalone viewer depends on the rotation of the thumbnail. Turning EXIF usage on and off for the standalone viewer works for JPGs but it's ignored for CR2s. Instead, when I turn it on or off for thumbnails and then refresh the lister (so that the new orientation is actually displayed), the rotation changes accordingly in the standalone viewer.

At first I thought that maybe the thumbnail cache ignores the suffix and applies the JPG's rotation to the CR2 but that's not the case. The effect is the same when I use files with different names.

Yes, that's what I mean.

I think I've seen that in the past before with certain fonts/sizes, though I think the example that I found got fixed. Could you tell us the font name and size and the titlebar size that's in use so we can try to reproduce it?
[/quote]

That's Segoe UI 8 on a title bar of height 19.

Which mouse drivers do you use?[/quote][/quote]

I'm using Logitech SetPoint, so that may as well have been a driver problem. I often get situations where application mappings are not applied correctly (e.g. when an application tries to steal the focus but Windows prevents it and just flashes the taskbar footprint, SetPoint still switches the settings to those of the program that tried to get the focus) but I have the Forward and Back buttons mapped as Generic Buttons for all application profiles, so I wouldn't usually expect problems there, even with SetPoint :slight_smile:

That's odd as the DCRaw plugin passes back a basic bitmap to Opus for the thumbnails. There's no EXIF/rotation information at all.

You're not rotating the thumbnails or images manually, are you? If you use the command in Opus that rotates the selected thumbnail then that rotation should be remembered and also should be applied to the viewer when you view the image. Perhaps there's an issue with manual rotation and caching, but I don't want to jump to a conclusion as you haven't mentioned manual rotation.

Could you upload an example CR2 file where this happens? I'll see if I can reproduce it here. It seems quite strange, though.

Yes, that's what I mean.
[/quote]
If you want that changed then you should send GPSoft a feature request.

[quote]* When I turn off WindowBlinds compatibility mode, the title bar text is draw one pixel line too low (and the lowest line cut off).
[...]
That's Segoe UI 8 on a title bar of height 19.[/quote]
I haven't had a chance to try this yet, sorry. Will try to remember.

I'm using Logitech SetPoint, so that may as well have been a driver problem. I often get situations where application mappings are not applied correctly (e.g. when an application tries to steal the focus but Windows prevents it and just flashes the taskbar footprint, SetPoint still switches the settings to those of the program that tried to get the focus) but I have the Forward and Back buttons mapped as Generic Buttons for all application profiles, so I wouldn't usually expect problems there, even with SetPoint :slight_smile:[/quote]
I wouldn't put anything past SetPoint! Logitech seem to have dropped the ball. :frowning: I still can't stop it from using smooth wheel scrolling on my MX Revolution when in IE, no matter what I change in the configuration. (And the configuration still doesn't get saved to the right place with Vista and UAC turned on... Sigh.) I had to resort to manually editing its config files to stop certain program-specific defaults from coming back; every time I removed them and rebooted they came back. Very frustrating. Bring back MouseWare, I say.

To make sure no manual rotation was involved, I took new photos to test it again. These are straight from the camera: http://szeiger.de/tmp/opus-rotate/dctest.7z (first one landscape, second one portrait (camera rotated 90° ccw))

All viewer plugins except jp2raw.dll disabled, Shell image extraction disabled (but I don't have a shell plugin for CR2s anyway).

Step 1: "Use EXIF information" disabled, thumbnails cache enabled and empty. Opening a lister and switching to thumbnails mode gives the expected result:

Step 2: Enable EXIF, refresh lister. Thumbnails are now coming from the cache:

Step 3: Close the lister, empty thumbnails cache, open lister again and switch to thumbnails. New thumbnails are generated. The portrait CR2 has the wrong orientation:

Step 4: Refresh the lister. Thumbnails are coming from the cache again and the portrait CR2 is oriented correctly:

Thanks. I can indeed reproduce the problem with the files you sent. I'll investigate further and also talk to GPSoft to work out what's going on.

I was able to reproduce this problem now. It is not caused by the mouse driver. When I have only single-display listers, there's always only one source lister and one destination lister. Dual-display listers never seem to lose their source and destination status even when I switch to another lister. And when I switch to a dual-display lister, the previously activated single-display lister doesn't lose its source status, either. Using the mouse forward/back buttons in the active dual-display lister makes the previous single-display source lister receive the forward/back commands.

Steps to reproduce:

  1. Open two new listers.

  2. Switch one to dual mode and click through some folders in the left half, so you get a history there.

  3. Click into the other (single-display) lister. It becomes a source lister but the left half of the dual-display lister also stays in source mode.

  4. Click through some folders to give this lister a history, too.

  5. Click into the left half of the dual-display lister. Both this one and the single-display lister are still in source mode.

  6. Use back/forward buttons on the mouse. Even though the dual-display lister has the focus, the single-display lister changes folders.

  7. Close the single-display lister. Now the history in the other one works correctly.

With respect, it is caused by the mouse driver. Logitech drivers are crap basically - it's the same reason the mouse wheel is able to scroll two windows in different applications simultaneously.

I can reproduce this with a Microsoft mouse and without SetPoint running. However, I was not able to reproduce it with a test installation on my Windows recovery system (which does not have SetPoint installed).

But I discovered a similar problem that I can reproduce on both installations: When the current lister (single-display mode) is the destination lister, the mouse forward/back buttons control the history of the current source lister even though it's in a different, inactive window. The forward/back buttons on the toolbar control the lister in the current window (as I'd expect from both, toolbar and mouse buttons).

Oh I see now what you mean. Yes, you're quite right :slight_smile: Sorry, I misunderstood the original report.