darktable-org
crop of version 5.2.1 changes to square crop after altering with 5.3.0
Is there an existing issue for this?
- [x] I checked and did not find my issue in the already reported ones
Describe the bug
Trying to alter cropped parts of an image that was edited using version 5.2.1 leads to square crops when editing with version 5.3.0.
Steps to reproduce
- in darkroom open an image that was edited with version 5.2.1 and that contains a rectangle crop, e.g. 3:2.
- open the crop module
- change the existing crop e.g. by shifting it, leaving the crop ratio untouched
- close the crop module
- the image has now a square (1:1) crop ratio with the width of the original crop
Expected behavior
The shifted crop format should be 3:2 not 1:1
Logfile | Screenshot | Screencast
No response
Commit
No response
Where did you obtain darktable from?
darktable.org / GitHub release
darktable version
darktable-5.3.0+997.g09b8299fa6-win64
What OS are you using?
Windows
What is the version of your OS?
Win 10 Pro
Describe your system
No response
Are you using OpenCL GPU in darktable?
Yes
If yes, what is the GPU card and driver?
NVIDIA GeForce GTX 1060 6GB
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
No response
I have been able to reproduce with an old edit. @jenshannoschwalm : Probably related to the last changes on crop module. Can you have a look?
Hi @jenshannoschwalm ,
thanks !
Data is here: https://magentacloud.de/s/KsBcJLGm5tbqroX
The parameters used for crop in the given example by @pass712 are "somewhat strange" as cx, cy, ch and cw define a square but ratio_p and ratio_n are 1:0 so defining an original image.
@TurboGit as you confirmed this, also tested with 1:1 crop or other ratio? @pass712 have you observed this only with 1:1 ?
@jenshannoschwalm : Yes, the picture was portrait in 3:2 aspect ratio. I tried to change position and/or change crop size and ends up with a square crop and sometime with a crop with did not correspond to the area I had selected.
I had then reset the crop module and all was ok after cropping again.
@TurboGit would you be able to share this? email if you want it to be confidential
No problem, here is a link https://drive.google.com/file/d/1p1Bv5c-rMTVokVrIVPJIhN6PyxTJDEB7/view?usp=sharing
@jenshannoschwalm : This bug is important enough to delay the creation of the tarball (that I should have done tonight) for the release.
Deeply sorry about this delay. Even more as i don't understand it right now. With a fresh 5.2 compile i cropped some images with various ratios - portrait and landscape - closed, recompiled current master and checked, all good here. I checked d and n in gui_update as that sets the aspects_preset.
Your image also shows 1:0 - which is clearly wrong, it should be 3:2 for portraits. Do you have the timestamp of that file, in case you edited after 5.2.1 ?
@pass712 can you remember if you edited that file after 5.2.1?
Hi @jenshannoschwalm.
The xmp I already sent you was the result of the editing under 5.3.0 (wrong crop = 1:1). It contains the older edit (3:2) in the history. The older one was done with 5.2.1.
If it helps I placed the original xmp (done with 5.2.1 alone) here: https://magentacloud.de/s/KsBcJLGm5tbqroX
@jenshannoschwalm : Sorry now that I read back my message I see that it could be harsh. I was not trying to put pressure on you in any way. Don't be sorry, you're doing the hard work. It was just informative as I have informed also the packagers about the delay.
Seems like that reverting to crop as in d8bb2223fbec77ea44539a391aa690a88eadd2dd solves the issue.
(well part of it, as when I first enable crop module the crop area is sometime displayed as square and then just after after refreshed properly to the correct area).
$ git show d8bb2223fbec77ea44539a391aa690a88eadd2dd:src/iop/crop.c > src/iop/crop.c
So the culprit may well be: c0a8430e647a40f2325c2c6d8ec37b0b875f81b1
But I bet you've already found out about this. Hope this helps anyway.
I must confess i currently don't understand what's happening. For some reason the ratio parameters in your xmps are simply wrong.
I checked by adding a simple info in commit_params
const int rd = p->ratio_d;
const int rn = p->ratio_n;
dt_print(DT_DEBUG_ALWAYS, "commit paramas rd=%d rn=%d", rd, rn);
and something like this to gui_update
const int d = abs(p->ratio_d), n = p->ratio_n;
dt_print(DT_DEBUG_ALWAYS, "gui update d=%d n=%d", d, n);
Your example - pascal - might in fact be good as you might have selected original ratio instead of 3:2 as that is very much the same.
The original xmp by @pass712 always commits 1:0 so for some reason there was never a recorded history to switch to square aspect. How can that happen at all? seems to be the important question
As i see it, at least for the square example there is clearly a mismatch crop-size versus aspect/ratio.
So we see the effect on the main canvas when we move the mouse. Any yes, if we have the bad aspect/ratio we end up with bad master crops. (BTW we would have that also for exports)
Hi @jenshannoschwalm,
IIRC I used the "original image" crop, not 3:2. The image size is 8192 x 5464 resulting in a ratio of something around 1.4992, not exactly 1.5. Maybe this plays a role ?
Forget a lot of the crap i wrote above, just too tired from last weeks work.
Checked again with 5.3.0+1006~g20d0c23d89. Same behaviour as described above.
But when I set the ratio (under 5.2.1) exactly to 3:2 instead of "original image" all works fine under 5.3.0. Maybe in the case of "original frame" there is an error referencing the pulldown list of ratios when closing the crop module ? Just guessing.