I have a NEF image of size 8288x5520. If I try to export with “set size in pixel” = 1860x1020, I get an image of size 1531x1019. My goal is to have at least one side of the resulting image equals to either 1860 or 1020. This 1 pixel error (1019 instead of 1020) appears to me as a bug. Am I missing someting ? Running Flatpak 4.6.1 on Linux Mint 21.3
I assume this can happen when it’s not possible to exactly preserve the original aspect ratio with the given size limits.
Seems like it is working for some but not everyone… Related bug reports: Image export size doesn't respect crop aspect ratio · Issue #16638 · darktable-org/darktable · GitHub, Version 3.0.0, lighttable 'max size' image export off by 1 pixel · Issue #4412 · darktable-org/darktable · GitHub and Incorrect file size on export · Issue #3757 · darktable-org/darktable · GitHub.
This is a known rounding issue “hard” to fix.
Do you think we could consider an option to prioritize the “export crop box” over the aspect ratio ? Meaning force the export resizing so that at least one of the side of the box is exactly matched even is the aspect ratio is not exactly preserved ? The use case for that is to produce an image that fits exactly some screen resolution (e.g. HD or 4K TV). Of course, most images will have just one side that exactly fits the crop box in order to preserve (almost…) the aspect ratio, since most images are not HD or 4K ratio, but it is perfectly fine
Are you specifying both dimensions… try only one and leave the other blank if so that has always worked for me… maybe not but try if that is what you did…
no, it give the same result. Furthermore, in my case I am exporting a bunch of image, some wide, some almost square, some tall. So it would not work in my use case.
I have no idea but I wonder if the scaling aligo used in preferences makes any difference?? You could try changing it…
This occurs in all software including commercial software that I have tested. I just presume there is some reason this occurs and I am not sure 1 pixel size difference would be earthshattering.
I have tried all 4 algo (assuming you are refering to processing - pixel interpolator (scaling)). It makes no difference. Thx for the tip
1 Like
Worth a try I guess
The fact that it may occur in some other apps is not an indication it is right or adequate (maybe just that it is not easy to fix). I would argue that this 1 pixel diff (not always that, sometimes it is 0) is annoying if you want to export to a specific box size (e.g. for an HD tv). I am not saying this is catastrophic, but what is the purpose then of this scaling box if it means “sometimes it will be precise, sometimes not, and we cannot predict when” ? What if we had a checkbox “exact match” that would force one side of the result to match one side of the box ? So if the downscaling factor become not an integer, we would still apply this scaling factor to the other side, even if it means have an aspect ratio not exactly identical. This aspect ratio anyway cannot always be maintained with exactitude, due to rounding in the scaling.
I tried resizing with ImageMagick :
convert image.tif -resize 1860x1020 a.jpg
and interestingly, it worked…the final dimension is 1531 x 1020. DT is giving 1019, whatever the scaling algo used (any of the 4 provided).
So, it means I guess we could improve DT to do the same, i.e. provide exact cropping to specified box dimension (at least one side).
I just tried on two files and set one to 1020 portrait edge and one landscape edge,
Resulting mages are 1528x1020 and 1020 x 680…
Not sure if that’s a pass or fail… but it might be image to image or system to system… seems to work for me…
Source image size…
Picking 1860 on the long edge either portrait or landscape give an image with the long side of 1860… in the case of landscape its 1820 by 1238
1020 is odd… It works for width but not height…If you use it for height you get 1019… If I specify 1019 or 1021 1022 1023 1024 etc they are fine…
So for me and using this image setting the height to be 1020 gives 1019…off by one pixel but other values are produced as entered…
Taking several other files I don’t see that ie a DNG a Sony and Olympus… so I am not sure what this really amounts to…seems trivial and possibly linked to that file…do you see that with all your nikon files??
Edit: I just tried a Nikon 7200 raw and it will honour 1020 as 1020 for either width or height so I am not sure why you get this one pixel thing and only for 1020 and not values on either side of that…
yes, I got this for other images also. Not always though. Unfortunately, I dont have the knowledge to compare DT code with ImageMagick code for resize (ImageMagick gives the correct answer for this very image)
I have had issues even when not specifying the pixel size. In darkroom I have cropped an image to a square, and the exported result is not a square. It’s one or two pixels off on one side. 1:1 crop is not a square when exported · Issue #16133 · darktable-org/darktable · GitHub
1 Like
Yep, imagemagick seems to be the only app that can deliver predictable results even with very unusual settings like the ones you showed - restricting the shorter axis is a rather rare use-case and from my experience is most often an uneccessary restriction in web-layouts.
In my workflow all raw-conversions output to a fixed value for the long axis, which currently is 4k (3840px). The final downscale (with appropriate pixel level sharpening) is done with a long collection of imagemagick scripts that are called either from gthumb or the commandline. This makes fiddling in the raw converter uneccessary, allows for multiple outputs, quick changes in the workflow and stable output - if something doesn’t add up I only have to fix the right imagemagick script instead of getting to grips with the peculiarities of each and every version of every raw converter. Trust me, trying to do the latter is a nightmare.
… probably because getting all the weird edge cases into a flow will make the if then else case select part almost uncomprehensible an hour later and therefore very brittle. It would be like a regex, just worse.