high vs low quality export - different image dimensions and crop area
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:
http://paraf.in/junk/IMG_2612.CR2 - original RAW file
http://paraf.in/junk/IMG_2612.CR2.xmp - XMP sidecar
http://paraf.in/junk/HQ.jpg - exported with HQ setting enabled
http://paraf.in/junk/nonHQ.jpg - exported with HQ setting disabled (both use lanczos3 as interpolator)
#1 Updated by Pascal de Bruijn over 6 years ago
- Status changed from New to In Progress
- Assignee set to Pascal de Bruijn
- Target version set to Candidate for next minor release
- % Done changed from 0 to 50
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?
#4 Updated by Igor Kuzmin over 6 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?