I have a 2x1 crop selected and when I export the image I need to resize it down to a lower resolution. What I want is 2160 x 1080. In the export, if I select “make shortest side 1080” then I get 2159 x 1080. If I select “make longest side 2160” then I get 2160 x 1081.
Also of note, the actual pixel size of the crop selection is displayed as “2025 x 1013 px (2 x 1)”, which of course is not perfectly 2 x 1. I’m not sure if this is where things go wrong, or if it’s on the export scaling operation.
The main thing I’m trying to do in this workflow is split a 2160x1080 into a left and right 1080x1080 to make an image you can pan across on an IG carousel. I have been doing this by hand in Affinity Photo. Does the app you mention have parameters to be able to do something like this? I.e. one image in, two (left and right) out?
I actually installed the linux version in WSL so I’ll play around with it some more. But your command will definitely get me pointed in the right direction. And yes, I’d like to do TIFF input and JPG output. I’m not clear on what the embedded preview is exactly, I’ll have to check that out.
For desktop I’m exclusively a Windows user but for command line tools I find the Linux environment quite convenient. With Windows terminal I always have a powershell and Ubuntu tab open. In this case I was able to install the tools, read the man pages and execute commands all from one window and without ever touching a mouse. The Ubuntu window operates on my windows directories so there’s no hiccups in the workflow.
That said I have just recently read about the export to application feature in PL (new PL user) so it may make the most sense to install the Windows version if the batch file can be executed directly (then again you could just as well make a .bat with a wsl.exe invocation of the unix tool).
In the end I probably just find it fun to explore different environments, helps keep my unix skills up.
The raw image is 8256x5504 (Nikon Z8). I then picked 2x1 and used the mouse to drag my crop rectangle and those are the dimensions it shows me for the selection I made.
It would seem the software either needs to adjust user selections to exact 2x1 dimensions (e.g. 2026x1013), or, internally track decimal points (e.g. 2025x1012.5) so that it has the precision required in later steps to achieve a perfect 2x1 on export.
with a pile of bugs and requests that DxO has to deal with ( which is growing every day, higher and higher, much faster than DxO can possibly deal with as we all see ) it is as noted above much easier to let it go and just export to app that does it all ( resize and split ) better and fully automatically
I’m certainly not waiting around on a fix, and I appreciate the workaround provided, but as a software developer myself I believe all bugs should be reported with sufficient detail so that they can be added to some kind of backlog.
Hilarious, but no, you haven’t read what I’ve written if you think that. When a user picks 2 x 1 as their crop ratio and the resulting crop ends up not 2 x 1, what exact math principle suggests this is correct?
Changing the size based on a new length of 1 size will be done by a factor original length/new length. That number will be used to calculate the new other size. There is no relation with the other edit: the crop. Resizing is not part of the crop.
What you want is that the new second size is calculated out off the first size based on the crop ratio. But even if that is done, one has to start with the shortest size.
A crop ratio is not only 1x2. What if the crop ratio is 2x3? How will you get exact numbers then?