duplicate manager - inconsistent processing

[elstoc]

Within the darkroom the duplicate manager allows you to click on any of the duplicate images to compare with the current edit. However, the image you get when you click on a duplicate is often not consistent with the image you'd get if you double-clicked to change image and view directly in the darkroom.

For example, I import an image and perform some edits on it. I then duplicate that image in the lighttable and do not perform any further edits (so both duplicate images - in this case v0 and v2 - are identical).

I expect that if I view version 0 in the darkroom and click on version 1 in the duplicate manager then, after some processing, the image should remain unchanged (they are identical edits).

The actual result, when the entire image is viewed, is that version 2 seems to be more 'fuzzy' than version 0:

v0 (the image being processed currently)

v2 (viewed by single-clicking in the duplicate manager)

If I zoom to 100% the results are better, but the image position seems to be off (the image moves up and to the left by a few pixels when I click on version 2) and sometimes the brightness can be different (though I didn't reproduce that here).

v0 (the current image)

v2 (from duplicate manager)

I would like to be able to perform different edits on the same picture and use this module to perform an accurate comparison but this does not currently seem to be possible as I can't rely on the processing to be the same on both. The only reliable and consistent way to do this at the moment is to load v2 in the darkroom, take a snapshot, and then go back and enable the snapshot against v0

These issues seem fairly consistent (I've reproduced on a number of versions including current master and on a number of images) so I haven't uploaded the raw or xmp but I can if needed.

I'm running on ArchLinux and the issue occurs both with and without OpenCL.

Presumably because it's getting the images from the cache, if I switch to version 2 in the darkroom and view v0 from the duplicate manager, both images look the same as they did in my original example above (i.e. v2 is fuzzy).

If I clear the cache before re-entering darktable and start off with v2 in the darkroom the above results are reproduced (i.e. v0 is fuzzy)

[todd-prior]

No sure but it might be cool if you could just arrow up and down in the dup manager and have it update the preview on the screen...what about creating a series of snapshots based on the current set of duplicates.....not sure if that would be useful.....should think on this some more.....

[AlicVB]

Question, do you observe the same issue between image in darkroom and lighttable full preview one ?

For the pixels offset, iirc, it's due to the fact that preview generation use some low quality optimizations which are required to avoid too long delay, but produce such small differences. It may be the same for the "fuzzy" issue

[elstoc]

Yes I think I do see the same issues between lighttable and darkroom (not so easy to tell as there's a border around the lighttable one so they're different sizes). The more thorny problem is that the lower quality version makes it into the cache and is then used in the actual darkroom center view if you then go into the second version in the darkroom itself. Is there any way to disable those optimizations for the duplicate manager?

[AlicVB]

iirc, I've test that (use high quality for full preview images) but the delay was so long that it was unusable in real. Now if you want to do that specifically for the duplicate, it'll require quite bigger amount of work because you'll need to add another mipmap cache creation path, or to find a way to pass some quality options to mipmap cache creation.

[elstoc]

:( I used to just flit between the two images in darkroom with the next/previous button but now that the screen greys out between images it doesn't work so well (I can't retain the previous image in my head for the amount of the loading time). I was hoping the duplicate module might be a good alternative. But it sounds hard.

[phweyland]

Just some thoughts here.

In mipmap cache we have the value DT_MIPMAP_FULL. If that name means what it tells (fully developed image), we should be able to have in cache the images we are working on, and in particular for duplicate comparison. Is that correct ?

The snapshot feature pursues similar goals (I would love to have a unique function with advantages of both, but that's another topic). It is quite effective for comparison (as long as we don't change the scale/crop). If quick cache reuse is not practical maybe the same method help here.

[aurelienpierre]

This happens on my system too. I have a DPI scaling factor == 2 (4K screen). So it is related to Cairo interpolation filter. What happens is the mipmap cached thumbnail queried by the lighttable is 4 times as large as the "virtual" image size, instead of twice as it should. Test the focus-peaking (Ctrl + Alt + F), it should be pegged in a corner about a quarter of the thumb size. So, in addition of this scaling error, Cairo filter are super bad (and slow… :-( ).

It doesn't happen in darkroom because the image buffer sent to Cairo surface is 1:1 and darktable manages the scaling internally.

It's on my to-do list to implement an interpolation method specially for thumbnails (content-aware downscaling), and I have half-fixed the scaling issue.

[elstoc]

I have my dpi changed a bit to reduce the size of all the modules and give myself some more image real-estate.

Ctrl+Alt+F isn't doing anything for me - do I need to be in a particular view or is there another way to toggle it on? Edit: oh it's ctrl+shift+f. I see what you mean.

[elstoc]

(and slow… :-( ).

I did notice that the duplicate module seems to take longer to render the duplicate than the main darkroom image.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[elstoc]

@TurboGit based on my testing of #5453 I don't really consider this to have been fixed, though I appreciate that this might not be fixable (without overriding Cairo filters). So it's up to you, but I'd prefer it to remain open in case a better solution can be found.

[jenshannoschwalm]

Hi, after merging #5431 things are better but not completely fixed.

After reading through the sources i think i understand whats going wrong, hold on, will make it for 3.2...

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions[bot]]

This issue did not get any activity in the past year and thus has been closed. Please check if the newest release or master branch has it fixed. Please, create a new issue if the issue is not fixed.