8000 Problem with export dimensions · Issue #18781 · darktable-org/darktable · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Problem with export dimensions #18781

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
1 task done
firefly910 opened this issue May 9, 2025 · 5 comments · Fixed by #18811
Closed
1 task done

Problem with export dimensions #18781

firefly910 opened this issue May 9, 2025 · 5 comments · Fixed by #18811
Assignees
@jenshannoschwalm

Comments

@firefly910
Copy link
firefly910 commented May 9, 2025 •
edited
Loading

Is there an existing issue for this?

  • I checked and did not find my issue in the already reported ones

Describe the bug

Bug:
Darktable doesn't respect the export dimensions when I want to export an image in 4k (3840 x 2160).

Explanation:
Let's say I have a large image with any aspect ratio. By large image I mean that it has more pixels than in 3840 x 2160. So it can be for instance 6000 x 3376.
Now let's say I want to export my image as 4k (3840 x 2160). What I do is to crop the image with the 16:9 HDTV preset of the crop module because 4k (3840 x 2160) is 16:9. This will allow in the export step to have the perfect aspect ratio to export to 3840 x 2160. Important: let's say I don't crop to a smaller size than 3840 x 2160. So there is no upscaling to then export to 3840 x 2160, only downscaling. Finally I set in the export tab the dimensions to 3840 x 2160.

However, when I hit export and check the dimensions of the produced image I get a 3840 x 2159 not 3840 x 2160 image. This is very bothering and makes it difficult to use Darktable for professional purposes.

Steps to reproduce

  • take any image larger than 3840 x 2160 with any aspect ratio. So for instance 6000 x 3376.
  • crop the image with the 16:9 HDTV preset (But don't crop to an image smaller than 3840 x 2160)
  • set the dimensions in the export tab to 3840 x 2160
  • export the image and inspect the dimensions of the produced image. It will be 3840 x 2159 not 3840 x 2160.

Expected behavior

A 3840 x 2160 image should be produced

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

darktable.org / GitHub release

darktable version

5.0.1

What OS are you using?

Windows

What is the version of your OS?

Windows 11

Describe your system

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

pixls.us thread
@jenshannoschwalm jenshannoschwalm self-assigned this May 9, 2025
@asmartin
Copy link

I see the problem - you can reproduce it with -d imageio and watch for the debug statement on line 1285 of imageio.c. The issue can be illustrated with the following example (where X is either width or x for width or height or y for height depending on the row):

pipe.processed_X processed_X scale pipe.processed_X * scaleX floor(pipe.processed * min(scalex,scaley))
width 4009 3840 0.957844849089549 3840 3840
height 2255 2160 0.957871396895787 2160 2159

The problem is twofold:

  • in _get_pipescale(), the scale is calculated independently for width and height, but then the smaller of the two values is chosen and used for both width and height, even if the scale values for each actually differs (as is the case above)
  • the floor() function is used to round down the scaled value, which results in 2,159.94 in the above height example being rounded down to 2159

I can think of two solutions:

  • calculate the scale for width and height independently, that way each value (if they differ slightly) is correct
  • use ceil() instead of floor() when rounding the scaled value; I don't like this solution as it solves it in this case but would probably introduce another case where the rounding is off

Other suggestions? I can try to make a PR once a solution is agreed upon

@parafin
Copy link
Member
parafin commented May 10, 2025

Why not use round()?

@jenshannoschwalm
Copy link
Collaborator
jenshannoschwalm commented May 10, 2025 •
edited
Loading

I don't think this is the culprit code part. Here we make sure that we always have complete data available in the pixelpipe (not having black single line borders or alike). Thus we use floor here.

For me the tricky/bad part is happening in crop module, more exactly in it's gui_post_expose() as that output is possibly different than what we do while exporting.

EDIT: no sure about above :-(

@asmartin asmartin mentioned this issue May 10, 2025
Closed
@asmartin
Copy link

I went ahead and made a PR that calculates the scale for each dimension separately. I tested this with several images and different aspect ratios and was always able to get the exact specified dimensions in the output. I also set allow upscaling to yes and upscaled the image successfully (to the specified larger dimensions) too.

Why not use round()?

I think the problem is it will still choose the incorrect value in some cases. Better to calculate what is needed precisely.

@jenshannoschwalm jenshannoschwalm mentioned this issue May 10, 2025
Merged
@firefly910
Copy link
Author
firefly910 commented May 12, 2025 •
edited
Loading

Hi, just to clarify I opened this issue because there is currently no way in Darktable to easily output images of well known dimensions like 4k (3840 x 2160). And be 100% sure that the dimension will be respected.
What I would like to be implemented is a way to solve this issue.

Because currently the best way to be 100% sure to make a 4k (3840 x 2160) image is actually to export with Darktable the full scale image and then do a rescale + crop in GIMP. But it is not very convenient in my opinion.

@jenshannoschwalm jenshannoschwalm mentioned this issue May 13, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jenshannoschwalm jenshannoschwalm

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Crop to ratio-precise dimensions jenshannoschwalm/darktable
4 participants
@parafin @asmartin @jenshannoschwalm @firefly910
0