Queued export/overwrite acts on current image, not the image which it was invoked upon
GIMP version: 2.10.18
Operating System: Arch Linux x86_64
Package: Official Arch package (in extra/ section)
Description of the bug
Suppose you are cropping a series of high-resolution scans; each scan's actual used area (paper size within the raw scanned area) may differ, and you want only the relevant area, not the space around it.
You would then use a process like this:
- crop this image.
- overwrite the on-disk image with the cropped image.
- go to the next image and repeat the process.
This seems straightforward, but it is not reliably doable.
The reason why is the combination of these three factors:
- exactly one export/overwrite can be done at once
- Triggering an export while an export is already running 'queues' an export for later.
- The 'queued' export acts on the active image, not the image which it was actually invoked upon.
So, consider the following expansion on how this will go in practice:
- Crop an image A
- [Overwrite] (export process begins)
- Switch to next image B
- Crop this image
- "[Overwrite]" (really, queue the overwrite action). (nothing visible happens at this point, unless the earlier export process has already completed)
- Switch to next image C
- Prepare to crop C
- (Export of image A finishes).
- Overwrite action starts on image C (but, it was never triggered for image C!).
- Image B is never overwritten; image C 'stole' its export operation.
- Additionally, the export action on image C may fail (for example, in the case where you confirm the crop after the export process has begun)
Reproduction
Reproduction steps:
- Create a new, high resolution image. Say 4096x4096; more might be needed if your system is especially fast.
- Generate some noise to ensure it takes a while to save (Filters->Noise->CIE LCH noise, crank Lightness to maximum)
- Export this image as a PNG. Call it
a.png
- Copy this image
for v in b c d e f; do; cp a.png $v.png; done
- Open {a,b,c,d,e,f}.png in GIMP
- Follow the 'crop, then overwrite' procedure outlined above for 3 or more of these images. Use arbitrary crops (or even no cropping, I guess)
- Wait for all pending exports to finish
- Inspect the status of the images. If it were done 'correctly', there would be no "gaps" -- if you look at a, b, c, d, e, f in that order, no image would exist with status 'imported' which was between two images which have status 'overwritten'; all 'overwritten' images would be grouped together.
…
Expected result:
Ideally, each image on which Export or Overwrite was triggered would be processed in the order that the operations were triggered. (so a proper 'queue' would be kept, that could accept an arbitrary number of images.)
More realistically, only one Export/Overwrite action would be queued, but it still would be applied to the image it was triggered on, rather than the current image. This would require some 'going back to previous image' at times, but it would never a) pointlessly overwrite a not-yet-cropped image, nor b) fail to export because the image changed during export.
Actual result:
Overwrite / Export acts always on current image, even when it was never triggered on current image