Bug 293500

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.)

It still reproducible with 2.5.0 release ?

Gilles Caulier

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.

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.

Also, it looks like the photos reappear after I delete the temporary JPEG versions.  Deduplication gone awry, perhaps?

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.

*** Bug 288494 has been marked as a duplicate of this bug. ***

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.

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.

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?

Marcel,

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.

Gilles

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

http://commits.kde.org/digikam/147fb2836249daedb0aa3588791a81b6016a3463

Gilles: Is there a reason that the watermark code is not moved to a filter, or is it just work left to do?

Marcel,

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...

Gilles

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