Project

General

Profile

Bug #9320

Imported crop settings from Lightroom seems to lock on square aspect

Added by Rickard Nilsson almost 7 years ago. Updated almost 7 years ago.

Status:
Fixed
Priority:
Low
Assignee:
Category:
Darkroom
Start date:
03/29/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
other GNU/Linux
bitness:
64-bit
hardware architecture:
amd64/x86

Description

When Darktable imports the crop settings from a Lightroom XMP file, everything works nicely until you try to edit the crop for the photo in Darktable. Then it directly switches to a square aspect crop, losing the settings imported from Lightroom.

I have attached an xmp-file for which this happens.

O20121208130641_RN-EM5_0327.xmp (3.77 KB) O20121208130641_RN-EM5_0327.xmp Rickard Nilsson, 03/29/2013 02:34 AM

Associated revisions

Revision 6b13d30c (diff)
Added by Pascal Obry almost 7 years ago

Fix aspect ratio computation.

It cannot happen in legacy_params() as at this point the size of the
image is not yet known. We then use a deferred circuitry to handle
this at the right point in the code.

Fixes #9320.

Revision b68111d3 (diff)
Added by Pascal Obry almost 7 years ago

Fix aspect ratio computation.

It cannot happen in legacy_params() as at this point the size of the
image is not yet known. We then use a deferred circuitry to handle
this at the right point in the code.

Fixes #9320.

History

#1 Updated by Jérémy Rosen almost 7 years ago

  • % Done changed from 0 to 20
  • Assignee set to Pascal Obry
  • Status changed from New to Triaged

Assigning to pascal to check if it is lighroom import related, my guess is that it's either c&r acting weird again or the aspect ratio which is not set properly by the LR importer....

#2 Updated by Pascal Obry almost 7 years ago

Not a Lighroom import issue but a clipping iop one.

The issue is in clipping.c, routine legacy_params where we have:

const struct dt_interpolation* interpolation = dt_interpolation_new(DT_INTERPOLATION_USERPREF);
float whratio = ((float)(self->dev->image_storage.width - 2 * interpolation->width) * (fabsf(n->cw) - n->cx)) /
((float)(self->dev->image_storage.height - 2 * interpolation->width) * (fabsf(n->ch) - n->cy));

But at this stage the self->dev->image_storage.width and self->dev->image_storage.height are still 0 because the image is not yet fully loaded I suppose.

See pull-request to fix this.

#3 Updated by Pascal Obry almost 7 years ago

  • % Done changed from 20 to 50
  • Target version set to Candidate for next major release
  • Status changed from Triaged to In Progress

#4 Updated by Anonymous almost 7 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed

Applied in changeset darktable|commit:6b13d30c0a3acfc535a184b56d662c1b54523edd.

Also available in: Atom PDF

Go to top