Bug #9605

slow pixel pipeline can result in crop area jumping elsewhere (race condition?)

Added by Robert Hutton over 6 years ago. Updated over 5 years ago.

Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git development version
hardware architecture:


There appears to be a race condition somewhere in the crop plugin. This is most evident when working with slow plugins in the pixel pipeline, as this makes the race condition much more likely to occur. If you make quick changes to a crop and then apply it, sometimes the crop area will be resized and will jump elsewhere in the image. I'm working on 5d mark III CR2 files.

Steps to reproduce:
  • open an image in the darkroom.
  • apply some slow plugins. For example, apply one or more copies of the denoise (profiled) plugin, depending on the speed of your computer. For faster computers apply more copies.
  • open the crop and rotate plugin and apply a crop, say a small area in the centre of the image.
  • double click in the cropped area to apply the crop.
  • once the crop is applied, quickly do these two actions:
    • change the rotation slider with the mouse wheel, say by 5-10 degrees.
    • collapse the crop plugin

The result I see is that the crop area is made smaller, and moves towards the top-left of the image. It also appears that the smaller the starting crop area, the more the crop area's size is reduced, so perhaps some calculations are being done on the cropped area rather than the full-size area or something.


#1 Updated by Chris Chiappa over 6 years ago

I've seen what I suspect is the same bug, but with a twist: sometimes the crop gets "inverted," ie rather than the area inside the crop box being clear and the area outside being greyed, it's the area inside the box that ends up greyed. Some random combination of enabling and disabling the module, resetting parameters and playing with the box is necessary to get it back to normal.

#2 Updated by Richard Wonka over 6 years ago

I have a slooow machine and get that all the time.

#3 Updated by Roman Lebedev over 6 years ago

I can reproduce that too.

I think that there is a [another?] bug, that is located not in the C&R module, but in the pipeline code because: enable some slow modules that stand before "Levels" in pipe, then quickly: open levels module & click auto, wait for some time and click auto again - black,medium,white points have changed.

#4 Updated by Aldric Renaudin over 5 years ago

  • bitness set to 64-bit
  • % Done changed from 0 to 100
  • Status changed from New to Fixed

This should be fixed now
thanks for reporting

Also available in: Atom PDF

Go to top