Bug 303163

Summary: "Undo" after "Color, Color Space Conversion" does not restore the original ICC profile
Product: [Applications] digikam Reporter: Elle Stone <elle>
Component: ColorManagement-ProfilesAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, kde
Priority: NOR    
Version: 2.6.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 2.8.0

Description Elle Stone 2012-07-07 19:30:58 UTC
If you hit the "Edit, Undo, Color Profile Conversion", the color space conversion is "undone" but the embedded profile is still the color conversion destination profile. For instance, if you convert from sRGB to ProPhoto and then "undo", the color space conversion itself is undone, but the embedded profile is ProPhoto. So the colors look funny. If you save (preferably under a new name), close showfoto, and then reopen the image, you can see that ProPhoto is still assigned and the colors look funny. Assign sRGB and the colors are restored. 

If you try to undo two sequential color space conversions, I'm not sure what really happens, but the results are very wrong.

To reproduce, open an image and convert to another color space profile using "Color, Color Space Conversion." Then select Edit, Undo and select "Color Profile Conversion. The colors will immediately look wrong. If you save and reopen, you'll see that the embedded profile is the profile you converted to, and the colors will be wrong. Assign the original profile and the collors will be correct. 

The same thing happens in digiKam and showFoto.
Comment 1 Marcel Wiesweg 2012-07-22 15:21:19 UTC
Git commit ead996b2a89b72e0f248c57edc68c22ba079fd93 by Marcel Wiesweg.
Committed on 22/07/2012 at 15:58.
Pushed by mwiesweg into branch 'master'.

Record color profile and metadata in undo history in editor.

So far only the history was recorded. Add a container to store history and icc profile.
Undo/redo now works cleanly when a plugin changes the color profile.
DMetadata is currently not kept in undo because either an imageplugin (only two atm, noncritical)
or a concurrent user metadata editing operation can change the metadata; essentially,
all critical metadata editing would need to be applied before saving.
In ImageWindow, we re-write from the database to metadata before saving, so probably all will work.

M  +2    -1    NEWS
M  +0    -5    utilities/imageeditor/canvas/canvas.cpp
M  +0    -1    utilities/imageeditor/canvas/canvas.h
M  +29   -5    utilities/imageeditor/canvas/dimginterface.cpp
M  +3    -2    utilities/imageeditor/canvas/dimginterface.h
M  +27   -10   utilities/imageeditor/canvas/undoaction.cpp
M  +19   -3    utilities/imageeditor/canvas/undoaction.h
M  +18   -18   utilities/imageeditor/canvas/undomanager.cpp
M  +2    -1    utilities/imageeditor/canvas/undomanager.h
M  +1    -1    utilities/imageeditor/editor/imagewindow.cpp

http://commits.kde.org/digikam/ead996b2a89b72e0f248c57edc68c22ba079fd93
Comment 2 Marcel Wiesweg 2012-09-23 14:17:41 UTC
*** Bug 306087 has been marked as a duplicate of this bug. ***