Project

General

Profile

Bug #9320

Imported crop settings from Lightroom seems to lock on square aspect

Added by Rickard Nilsson about 6 years ago. Updated about 6 years ago.

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

100%

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) Rickard Nilsson, 03/29/2013 02:34 AM

Associated revisions

Revision 6b13d30c
Added by Pascal Obry about 6 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
Added by Pascal Obry about 6 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 about 6 years ago

  • Assignee set to Pascal Obry
  • % Done changed from 0 to 20
  • 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 about 6 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 about 6 years ago

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

#4 Updated by Anonymous about 6 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