Bug #9148

high vs low quality export - different image dimensions and crop area

Added by Igor Kuzmin over 7 years ago. Updated over 6 years ago.

Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git development version
hardware architecture:


When comparing pictures exported with and without "high quality resampling" option enabled in preferences I notice 2 things:
1). dimensions differ by 1 pixel (2700x1799 vs 2700x1798), this is probably just some rounding error and can be ignored
2). different parts of original image get into exported files, so there's noticeable differences between these pictures, not in quality but in content; this depends also on pixel interpolator settings - lanczos* make this issue more pronounced; also it seems that the more picture is trimmed using crop&rotate the more is difference.
Here are example files: - original RAW file - XMP sidecar - exported with HQ setting enabled - exported with HQ setting disabled (both use lanczos3 as interpolator)


#1 Updated by Pascal de Bruijn over 7 years ago

  • % Done changed from 0 to 50
  • Target version set to Candidate for next minor release
  • Assignee set to Pascal de Bruijn
  • Status changed from New to In Progress

I think I found it:
(present in both git master and our darktable-1.1.x branch, also available on my unstable ppa within a few hours)

Seems to work for me. Could you please double check and report back?

#2 Updated by Igor Kuzmin over 7 years ago

Sizes now do match, but visible shift of content is still present, maybe reduced a little.

#3 Updated by Pascal de Bruijn over 7 years ago

  • Assignee deleted (Pascal de Bruijn)

That's as far as I can take it I'm afraid. The clipping code is not particularly entry level :(

What might be relevant though is figuring out which mode (HQ or nonHQ) matches the selection in Darkroom mode best.

#4 Updated by Igor Kuzmin over 7 years ago

  • System set to all

After digging in clipping.c today I think I have now a general idea what's going on. Cropping area dimensions and position are saved as normalized values, so they are independent of input buffer size. But for interpolation to work, it needs several (1, 2 or 3, depending on selected mode) rows and columns of pixels adjacent to the borders outside the selected area. And obviously depending on the scale these 2 or 3 pixels translates to different normalized value and so different shift and aspect ratio change (since most pictures aren't square).
This probably affects both darkroom view and export. Also the consequence is that when user changes interpolation method, crop area moves too.
A couple of questions:
1). does interpolation really need to eat pixels? can't smth like CLK_ADDRESS_CLAMP_TO_EDGE || CLK_ADDRESS_MIRRORED_REPEAT in opencl be used?
2). can't crop&rotate not use interpolation if just crop is used, no rotation and whatnot?

#5 Updated by Igor Kuzmin over 7 years ago

Also, why cut from inside of crop area and not use pixels outside of selected area in case if they are available?

#6 Updated by Tobias Ellinghaus over 6 years ago

  • bitness set to 64-bit
  • % Done changed from 50 to 20
  • Status changed from In Progress to Incomplete

Any update here?

Also available in: Atom PDF

Go to top