Bug 293500

Summary: photos disappear from albums after processing in the batch queue
Product: [Applications] digikam Reporter: Alexander Wauck <alex.wauck+kdebugs>
Component: BatchQueueManager-WorkflowAssignee: Digikam Developers <digikam-bugs-null>
Severity: normal CC: caulier.gilles, philippe.quaglia, sebo.moz
Priority: NOR    
Version: 2.6.0   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In: 2.6.0

Description Alexander Wauck 2012-02-07 01:58:41 UTC
Version:           2.1.1 (using KDE 4.7.4) 
OS:                Linux

When I convert RAW photos to JPEG using the batch queue, the RAW photos disappear from the album they were in.  The image files are still there, but they don't appear.  The only way to fix it is to import the album's folder into a new album and then move the images into the old album.  I don't know if it's limited to RAW source photos.

Reproducible: Always

Steps to Reproduce:
1. Put some RAW photos in an album.
2. Select a few, right click, and select "Batch Queue Manager->Add to Current Queue".
3. Select "Convert to JPEG".
4. Select a different album for the output.
5. Click "Run".
6. Wait for the queue to finish.

Actual Results:  
The photos I added to the queue no longer appear in the source album.

Expected Results:  
The photos I added to the queue still appear in the source album.

I'm tempted to set the severity to Major, since a non-technical user would probably think data was lost.
Comment 1 Alexander Wauck 2012-02-07 02:04:46 UTC
Update: apparently the photos will reappear eventually.  The only thing of note that I did before I noticed that the photos had reappeared was to delete the temporary album I used for the JPEG versions.  (I do this because I really just want to keep the RAW version in the album and save a temporary JPEG version to give to someone else.  I don't want to use a service like Flickr; I have my own server.)
Comment 2 caulier.gilles 2012-02-07 06:19:58 UTC
It still reproducible with 2.5.0 release ?

Gilles Caulier
Comment 3 Alexander Wauck 2012-02-13 02:40:18 UTC
I haven't tried that version yet.  It's not packaged for Ubuntu, so it looks like I will have to compile it.  I'll try to get that done tomorrow.
Comment 4 Alexander Wauck 2012-02-15 04:25:08 UTC
Well, it was an adventure, but I finally got a more recent version installed.  I ended up going with 2.6.0 beta 1 because there was readily-available Debian packaging available for it (apparently it's in Debian experimental).  The problem is still present.
Comment 5 Alexander Wauck 2012-02-15 04:26:39 UTC
Also, it looks like the photos reappear after I delete the temporary JPEG versions.  Deduplication gone awry, perhaps?
Comment 6 Alexander Wauck 2012-02-21 03:39:59 UTC
This is interesting.  The problem no longer seems to happen with 2.6.0 beta 1 (the same version I tested with last time).  Also, checking the Versioning tab reveals that this is probably caused by the feature described here: http://scribblesandsnaps.wordpress.com/2012/02/15/prevent-photos-in-digikam-from-disappearing/
I also noticed that the two checkboxes mentioned in the blog post were unchecked.  I don't remember unchecking them since I last tested, but who knows.

I would argue that this feature is poorly implemented: I would never expect this to work across different albums.
Comment 7 caulier.gilles 2012-02-22 17:04:07 UTC
*** Bug 288494 has been marked as a duplicate of this bug. ***
Comment 8 Marcel Wiesweg 2012-04-25 16:55:42 UTC
There is a side effect of versioning. In the BQM, it seems often more desirable to do the equivalent of "Save to new version" in the image editor rather than "Save changes" which hides the original.
Comment 9 Johannes Wienke 2012-04-25 17:04:52 UTC
Some of the effects here are also related to bug 298380 and the last patch I added. With current release versions, versioning might still be active partially and hence hide images, even though it is switched off in the settings.
Comment 10 Marcel Wiesweg 2012-04-25 17:18:10 UTC
Gilles: There is BatchTool::loadToDImg(). Does every tool load a file from disk, or do tools operate on the same DImg object in a row? Are all BQ tools based on DImg, or are there tool not using DImg/imageplugins?
Comment 11 caulier.gilles 2012-04-25 20:22:53 UTC

This depend of chained tools set in workflow. The first one, load image from disk through DImg container. All other one use DImg data to process image. The last one save DImg data to disk.

All tool are based on DImg. Tools processing code are shared with imageplugins.

Comment 12 Marcel Wiesweg 2012-05-04 19:14:41 UTC
Git commit 147fb2836249daedb0aa3588791a81b6016a3463 by Marcel Wiesweg.
Committed on 04/05/2012 at 21:01.
Pushed by mwiesweg into branch 'master'.

Port all BQM tools (with some exceptions *) to record their filter actions in the image,
thus properly supporting versioning

* The tools which actually tune the saving format do not apply history.
  Watermark tool is missing as it is not based on a filter.
  Rotation does not add an action for some cases intentionally

M  +5    -10   utilities/queuemanager/basetools/color/autocorrection.cpp
M  +1    -2    utilities/queuemanager/basetools/color/bcgcorrection.cpp
M  +1    -2    utilities/queuemanager/basetools/color/bwconvert.cpp
M  +1    -2    utilities/queuemanager/basetools/color/channelmixer.cpp
M  +1    -2    utilities/queuemanager/basetools/color/colorbalance.cpp
M  +3    -1    utilities/queuemanager/basetools/color/convert16to8.cpp
M  +3    -1    utilities/queuemanager/basetools/color/convert8to16.cpp
M  +1    -2    utilities/queuemanager/basetools/color/curvesadjust.cpp
M  +1    -2    utilities/queuemanager/basetools/color/hslcorrection.cpp
M  +5    -4    utilities/queuemanager/basetools/color/iccconvert.cpp
M  +1    -2    utilities/queuemanager/basetools/color/invert.cpp
M  +2    -3    utilities/queuemanager/basetools/color/whitebalance.cpp
M  +1    -3    utilities/queuemanager/basetools/decorate/border.cpp
M  +2    -0    utilities/queuemanager/basetools/decorate/watermark.cpp
M  +1    -2    utilities/queuemanager/basetools/enhance/antivignetting.cpp
M  +1    -2    utilities/queuemanager/basetools/enhance/blur.cpp
M  +3    -2    utilities/queuemanager/basetools/enhance/lensautofix.cpp
M  +1    -2    utilities/queuemanager/basetools/enhance/localcontrast.cpp
M  +1    -2    utilities/queuemanager/basetools/enhance/noisereduction.cpp
M  +1    -6    utilities/queuemanager/basetools/enhance/restoration.cpp
M  +3    -6    utilities/queuemanager/basetools/enhance/sharpen.cpp
M  +1    -2    utilities/queuemanager/basetools/filters/filmgrain.cpp
M  +12   -1    utilities/queuemanager/basetools/transform/flip.cpp
M  +3    -1    utilities/queuemanager/basetools/transform/resize.cpp
M  +22   -17   utilities/queuemanager/basetools/transform/rotate.cpp

Comment 13 Marcel Wiesweg 2012-05-04 19:15:33 UTC
Gilles: Is there a reason that the watermark code is not moved to a filter, or is it just work left to do?
Comment 14 caulier.gilles 2012-05-04 20:41:05 UTC

well, i would to share WaterMark code between BQM and IE, as all other Batch tool using a common implementation in DImg::Filter, but, the code is a little bit different. In fact factoring and re-writting need to be done. This is why WaterMark code still as well in BQM for the moment...

Comment 15 Marcel Wiesweg 2012-05-06 15:45:32 UTC
I assume that the original bug is fixed.
Some improvements to integrate BQM with versioning are possible:
- add a UI setting that the BQM does not create a new version, as it does currently, but saves changes "replacing" the original
- integrate versioned naming; this removes the option to overwrite the original, and generates a new name automatically