Bug 125387 - Simulate changes to images only
Summary: Simulate changes to images only
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ImageEditor-Versioning (show other bugs)
Version: 0.8.1
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-11 22:42 UTC by Aaron Digulla
Modified: 2022-02-02 05:09 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Digulla 2006-04-11 22:42:39 UTC
Version:           0.8.1 (using KDE KDE 3.4.2)
Installed from:    SuSE RPMs

When working with lossy images (JPEG) and when doing small changes, it would be great if digikam didn't actually change the picture but just added a small extra file (a note) with the change. Examples: Saturation, Color enhancements, fixing red eyes, rotation, small changes to the image.

The goal here is to preserve as much of the quality of the original image.

Maybe it would be even better to never change the original image at all (except the operation is known to be lossless) and apply all changed to a kind of matte which is overlayed to the original or, if that's too expensive, always make a backup of the original image when the user attempts to save a change (prefs option). This would be very simple to implement.

Then, a user could experiment for a while and always revert back and start from scratch if the results get too ugly.
Comment 1 caulier.gilles 2006-04-12 11:18:06 UTC
Hi Aaron,

Like i have already explained in digikam mailing list and in this room, working with JPEG files in image editor is a wrong issue. You must use a lossless file format like PNG or TIFF and save your results like this. When you have completed your changes you export to JPEG the target image.

Regards

Gilles Caulier
Comment 2 Aaron Digulla 2006-04-12 12:06:55 UTC
Hi Gilles,

That still means I have to convert twice: JPEG -> TIFF and back.

Enhancing the colors is an operation which is so quick that it can be applied while loading.

For this, many PC programs just note the change (new Gamma, whatever) without touching the JPEG data.

So I'm not talking about simulating The GIMP or something but for tiny retouching work (like "Make all images in this album 10% brighter").

I'm not sure how far this can extend. It depends on the speed of the computer (the change needs to applied every time), etc.

Also, I specifically might not want to change the original image (keeping the option to always revert back) without having to manually manage all the copies.

Think of Joe Sixpack, who just got his first digital camera. He's busy making photos. On the computer, they look dull. So he enhances them.

Later, he learns a much better to improve the images.

But the old mistakes are now saved for eternity.

Also, the c't (big German computer magazine) would rate digicam better, if it could do this non-destructive filtering.
Comment 3 Martin Rehn 2006-05-25 19:18:06 UTC
See this wish about version management:

http://bugs.kde.org/show_bug.cgi?id=103350

Version management is a more generic solution to Joe's problem, of course. That said, your idea about saving a list of editor actions separately from the actual images, as a kind of macro, is an interesting one that could perhaps be extended even further? For a start, you could save a set of operations that you could then quickly apply to other images. What else?

By the way, which are the PC programs you are referring to, apart from Picasa?
Comment 4 glaurent 2006-05-25 19:31:05 UTC
Bibble does exactly that. A time-limited demo version is freely downloadable, I suggest you give it a try. Even though the UI is a bit clumsy (and fugly looking thanks to Qt's Win95 theme) they did got the work process down pretty well.
Comment 5 Aaron Digulla 2006-05-28 22:19:47 UTC
I can't find the article right now but I think many picture viewers/archivers like ACDSee and IrfanView can do this.
Comment 6 caulier.gilles 2006-09-03 20:04:04 UTC
Let's me explain my recent investiguations about Nikon Capture NX beta:

This program can be used to manage RAW .NEF file format from Nikon camera. There is a great future to perform changes in RAW image without changing original image data in file. The idea is to use the metadata to store a list of actions in editor to perform when the image is opened later.

A NEF file is just tagged with new binary data used by the software to store the actions list. This is require only some Kb !

In digiKam, this can be done like this :

1/ Adapted the actions management core from editor to identify each action by an ID and a list of option availabe for each tools (core action and image plugins).
2/ Fix all editor tools to use the new actions management interface.
3/ Added a new option in editor to save action list to perform in picture.
4/ Using a metadata tag to store a list of actions. IPTC can help us : there is normally free-for-use tags for that. We can use XMP later when Exiv2 will support this metadata type.

This way can be used with all image type witch support IPTC : JPEG, PNG, TIFF, and all RAW Tiff files based (NEF, CRW, CR2, MRW, ARW, etc.)

Another way is to use the digikam database to store action list to perform in editor for a picture.

Of course, in all case, these solution are specific to digiKam, and cannot be used easily to an other image manipulation sofware. 

I think that using a versionning of picture is a non sence for me, especially about performance reasons...

Gilles Caulier
Comment 7 caulier.gilles 2006-09-05 20:58:55 UTC
*** Bug 127039 has been marked as a duplicate of this bug. ***
Comment 8 Julien Narboux 2006-09-06 09:22:34 UTC
IMHO this wish is very important because it is IMHO the main missing feature of Digikam compared to expansive commercial software such as Aperture and Lightroom. 

Let me give a few thoughts about a possible implemantation of "action lists".

It would be great if :
The gui of digikam allows to build and edit action lists using different ways:
- the standard way using the current gui of Digikam editor
- using a diagrammatic interface : the list of actions is represented by a graph whose nodes are the actions and edges represent dependancies. (By the way the actions list may one day become an action graph if you think of merging layers, etc ) 
 For instance: Original Image -> Saturation +0.3 -> Crop 600*800, 100*100 -> Unsharpmask 3
One can select a node: the "before" node. 
Then if one click on a node,  the picture corresponding to this node is displayed using the standard user interface correponding to the action to edit the parameters of this actions. The picture you can compare with using this gui is the one represented by the node which has been selected as the "before" node.
- by cut and paste of actions, if you want to apply the same actions to a bunch of pictures. Here it would be nice to define some actions as "picture specific" and other as "general" so if you cut and paste you only cut and paste general actions. For instance I think you may often want to apply the same sharpening parameters to a bunch of pictures but you don't want the same cropping.

Now about the evaluation of the actions list:

I think to be responsive it needs a smart implementation, maybe one needs to:
- cache the picture corresponding to the last action in the list, so one can open a picture very quickly.
- perhaps also cache the pictures correponding to intermediate nodes, maybe just smaller versions of the picture at screen resolution in order to allow a quick preview of "undo". This may be configurable by the user using a slider:
Quick (Use a lot of disk space) <-- (Average Use the disk space correponding to twice the size of the original pictures : (the original and the final)) --> Slow (Use only the disk space for the original picture) 

The speed of evaluation may be increased by 
- changing the order of the actions, for instance crop should be evaluated first because it reduces the size of the problem.
- grouping similar actions, for instance if the user change the saturation twice only apply it one time with the parameter corresponding to the "sum" of the two actions.
- maybe some actions which are defined by a matrix transformation could be composed to improve speed by computing the composition of the matrices before applying them (I do not know enough about image manipulation maybe it is impossible or useless)

Another feature would consist in defining a standard order for actions : 
For instance, I think I have read one several tutorials that sharpening should be the last operation. This could be made transparent to the user: he defines the actions in the order he wishes then they are sorted using the "right" order by Digikam.

Sorry If what I try to say is not very clear.


 


 



 

Comment 9 caulier.gilles 2006-09-06 10:18:58 UTC
Marcel, 

i would to have your viewpoint about "action lists" feature, especially how to implement easily this part. Of course, this will be done later 0.9.0 release (:=)))

Andreas, can you give me your viewpoint about where we can store "action lists" metadata in IPTC via Exiv2, if we use this way of course. 

I think that "action list" will be a future digiKam killer feature. Thanks in advance to all for your constructive comments.

Gilles
Comment 10 glaurent 2006-09-06 10:55:56 UTC
I'm not Andreas but I'd still like to share my point of view :-). I use Bibble for pre-processing raw files along with Digikam, and Bibble also stores "actions" seperately while leaving the main image unaltered. This is indeed an extremely powerful and useful feature, however storing this action data as metadata in the file itself would be a mistake IMHO. Bibble simply stores it in a .bib file next to the image, which makes it very easy to remove or archive it if needed (what's more, Bibble being written with Qt, the file is actually a Qt config file). It also makes debugging trivial, not to mention regression testing. I strongly suggest you follow the same path.
Comment 11 Marcel Wiesweg 2006-09-06 13:45:24 UTC
One idea I have had for some time is to introduce links between images, "these images are derived from that", "show original image of this". At a closer look, this feature is a subset of the features requested here.

First, how to store actions. I think we should do it in the db, and additionally we can store it either in metadata or in extra files.

I assume that some actions (gamma adjustment, cropping) can easily be carried out on the fly, while others (most image plugins) require lengthier computation.
So we should have the possibility to store action results as "real files" on disk, or "virtually". If the user clicks "save" in IE, we should assume he actually wants to store, or offer the choice. One option is to keep the original as a "digital negative", another option is not do this, no problem.

Say the users opts to keep the original and store a new version, we would store all actions applied to the image, and from which image it is derived.

If only the actions shall be stored, the file is unchanged on disk, but the actions are stored. (problem: what to do with thumbnail?)

These are only first thoughts, we should take our time to think about this.
Comment 12 glaurent 2006-09-06 14:10:09 UTC
Marcel :

- storing actions in the DB will be a nightmare both from a development and usability standpoint. I want my raw files untouched, and I want to be able to easily copy it along with whatever edits I've done, so the external file is really the only viable solution.

- regarding saving, as a user the last thing I want to be bother with is an implementation detail such as "keep the original or not ?". Always keep the original, if I want a processed file then I'll explicitly export it (like in Bibble). If you have to store images of intermediate steps, then do it. Disk space is cheap (forget about the complains "oh but I only have 10Gb", let's be realistic - if you're serious about photography, you'll get yourself a decent HD, and by the time this feature is implemented, HDs in the terabyte range will be available for $100).
Comment 13 Marcel Wiesweg 2006-09-06 19:17:02 UTC
We are storing complex searches in the db (in form of a url), so no problem to store parametrized actions ;-) No, storing everything in DB is not necessary.

I see we need to cut something of this to keep complexity low. Multiple "virtual" images/action lists per image are a problem. We would rather do a real copy of the image each time.
To keep the relation or links between original and derived images, the DB is the way to go.

Storing in an extra file has the problem of extra files lying around, storing in metadata has the problem of changing the original file and IPTC is not available for all formats.

If you say disk space is no problem, other users will claim this is a problem. Sometimes users will want to remove the previous image (it may be derived from another original version, which is kept), there is a number of possibilities. We need to provide enough but not too many options.
Comment 14 Andreas Huggel 2006-09-07 04:34:34 UTC
Besides the arguments discussed, another reason why not to store this in the metadata of RAW images, even if technically possible (at least for TIFF-like RAW formats), is that most RAW specs are proprietary and the available specs are reverse-engineered. So it is usually not known if adding the IPTC tag (for example), even if it’s possible, is within the original specs. Other software - maybe that from the camera vendor - may not like images with such an added tag.

To answer Gilles' question, IPTC application records 4 and 5 look like candidates for this, although the IPTC standard is not very clear on that.

-ahu.
Comment 15 caulier.gilles 2006-09-07 07:28:41 UTC
I'm fully agree with Marcel about to store in all case in database the "action List" data for each image.

Laurent, the advange for that, is to have the capability to search images using "actions list" criteria. For exemple, you can find all images where you have applied the "red eyes correction" tool !

I'm not favorable to store "actions list" in a separate file. It's not clean and search will be impossible do do like this (for performance reasons).

But, i'm favorable to have a new metadata option to store "actions list" in an IPTC tag, exactly like digiKam tags or digiKam Rating.

Gilles
Comment 16 Arnd Baecker 2006-09-07 07:53:45 UTC
Independent from the place where actions will be stored
one important issue might be the compatibility of the
individual actions:
E.g., is it guaranteed that any tool/plugin will always require
the same number of parameters in the future?
If not, how does one cope with changes?

BTW: If the procedures to store and load actions are implemented,
this would allow a kind of "action recorder",
where certain sequences of actions can be replayed for other images.

Arnd
Comment 17 caulier.gilles 2006-09-07 08:01:31 UTC
A release action ID need to be added to identify how many parameters need to be used.

better than a simple action recorder, by an actions management tool need to be done to remove or share actions between images for example.

Gilles
Comment 18 Julien Narboux 2006-09-07 08:50:36 UTC
I think you may also store the md5sum of the picture you are supposed to get from the output of the action. So in case the implementation of an action is changed in a future version of digikam the user can be warned that its picture has changed.
Comment 19 caulier.gilles 2006-09-07 08:53:11 UTC
You have right. There is also a file in B.K.O about MD5 stuff...

Gilles
Comment 20 Julien Narboux 2006-09-07 08:58:19 UTC
Another point : when the user use the "open with" feature to edit the picture using an external program such as gimp, Digikam must evaluate all actions and save the current status of the picture. The user is then warned that using an external application will prevent to undo his actions in digikam and he is asked if he wants to work on a new copy of the picture. If he answers yes Digikam add the picture corresponding to the evaluation of all actions as a new picture in the database before opening it using the external application.   
Comment 21 Julien Narboux 2006-09-07 09:08:10 UTC
Another point : IMHO the digikam album tree which appears to the user on the filesystem should contain the last version of the pictures, the originals should be hidden.
For two reasons: 
- if you want to edit in an external application you don't need to open digikam first to export the picture.
- it is easier for the beginner user: you won't get bug reports such as "I changed something in Digikam but I do not see my changes using external apps"

It would be great if pictures that have not been changed are stored only one time.
Comment 22 Arnd Baecker 2006-09-07 10:12:24 UTC
> last version of the pictures, the originals should be hidden.


A more general feature, which could be used for this particular
purpose as well, is grouping of pictures:
When combining several pictures into a group, one could
select which of them is visible.

(This could be useful when shooting a sequence of pictures
where maybe one or two are really good, while
the others are ok, and still nice to keep.)
Visually line like |----------------| in the thumbs display
could indicate pictures belonging to a group. Clicking on such a line
would display all of them, and not just those which are marked
as visible.

Arnd
Comment 23 Julien Narboux 2006-09-07 10:47:00 UTC
There is already a wish about grouping of pictures. Please add you comments here :
http://bugs.kde.org/show_bug.cgi?id=121310
Comment 24 Aaron Digulla 2006-09-13 23:13:26 UTC
I think the first step would be to allow to record all changes made to an image in some data structure (no matter where that finally ends up). I'd suggest that this data structure should be exportable to XML because that's most simple to exchange. 

If it makes sense to use XML internally is something I can't decide. But that would help with the version issue because the next version of the action can see what parameter it gets and do the right thing.

The next step is to attach these to images. I'd prefer the "keep original and display the final version" way. This would also allow to offer undo-after-save (because we could load all actions into the undo buffer when the image is loaded).

It should also be possible to store actions in a separate file to apply them to a range of images. If this is done with XML, it will be possible to integrate digikam and other applications seamlessly.

For example, inkscape allows to record all changes ever made to an image. It can even display all actions in a history dialog. You can select any action to move quickly through all the modifications made to the image.

As for grouping/linking images, I think that's something which will confuse the user. When I make a copy of an image, I expect to have a new image. In this case, digikam should copy the image (original, action list, final image) to the new place and let me work on that. Or create a "copy from" action but I guess that will be hard to implement because then, every image will have to remember all it's copies (so you don't get broken action lists when you move the original around).

Note: The final image is something like the thumbnail. It's just generated to make the UI more responsive (especially when the action list contains expensive actions). When it gets lost, digikam should just regenerate it like it does with the thumbnails. But digikam should never touch the original image.

Note 2: I wonder if there should be a "delete" action, that is, images are never really deleted but the delete action will simply hide them. In the prefs menu, there could be a "Show deleted images" checkbox to get them back.
Comment 25 Matt Rosewarne 2006-11-06 22:36:23 UTC
This sounds like a job for... Tenor! </1950's TV Narrator Voice>  Seriously, this exactly the functionality that the upcoming Tenor framework is designed to facilitate.  Please consult whoever is working on it, I believe Scott Wheeler or the Stigi team are persons of interest, instead of implementing a digikam-only version.  The advantage of this approach is that all KDE- or Tenor-compatible apps can take advantage of the versioning/grouping.  In such an approach, images could be stored as in a VCS, which has the benefit over action lists in the ability to display changes regardless of what software is installed.

This would also resolve bug 121310.
Comment 26 Fabien 2006-11-24 14:35:31 UTC
About this bug vs http://bugs.kde.org/show_bug.cgi?id=125387

IMHO, there's no reason to oppose them (I mean versioning vs "actions list").
I think actions list is very powerful but too complex for newbies. It would be more dedicated to advanced users...

What I can see is that sometime my mum makes a mistake when she just want to resize a picture to send it to me by email : she just save the picture with the new size (30% of the original) and definitely lose the high-resolution one. This is what should be solved first I think ;-))

This is why I first ask to add a warning message when overwriting the original file...
Comment 27 Aaron Digulla 2006-11-24 16:53:32 UTC
If you want to start small, save the changes to a second file and always leave the original file alone.

Then, just a "revert changes" menu item is necessary.
Comment 28 Feth AREZKI 2006-12-07 00:24:55 UTC
Simple user, I just came today with the same idea you are discussing :
I always keep an original of my pictures, but I often need to modify them prior to showing, sometimes in several ways for as many contexts as needed.
Those modifications include : cropping, resizing, red eyes...
I believe that somehow it would be possible to help me manage that collection of versions of the same image by storing {original_image, operations_leading_to_new_versions}
And maybe caching the diffs between original and new images to still get high speed rendering (once the cache is full, just flush least used renderings).
Comment 29 Luka Renko 2006-12-25 20:01:02 UTC
Qimage (http://www.ddisoftware.com/qimage) has such feature: all changes to the original are stored as actions in a .flt file. This is very powerful and useful, so it may be useful to review that implementation to pick up some ideas.
Comment 30 Luka Renko 2006-12-25 20:01:36 UTC
*** This bug has been confirmed by popular vote. ***
Comment 31 Valtteri Vanhala 2008-07-04 21:41:25 UTC
Rawtherapee seems to have this feature well implemented (http://www.rawtherapee.com/). You can make changes to one file, then save the set of changes as a profile and then add them to any other file. 
I would love to see rawtherapeelike functionality inside digikam so that the actual changes are not permanently added to the file but show as a version only.
Comment 32 Valery Novikov 2009-01-19 17:16:04 UTC
Hi hackers from digikam team!

It's already pretty large value of votes for this feature (336 currently) and almost two years of "no answers" from digikam team.

What is a "showstopper" for this issue?

You are coding really lovelly application! It should be extremly useful enhancement for DigiKam.

Thanks!
Comment 33 Stibbons 2009-08-12 14:36:17 UTC
I vote for this new feature.
Non destructive file treatment is so great. Just rely on an xml file that applies all change to some cached files and export the jpeg result would ease the work on large scale level, allow to "sync" setting between serveral files etc, change a setting without redevelopping everything, and moveover, never touch the original file (should be a golden rule!)
This is the trend for professionnal photography workflow application, and I might understand it is quite difficult to implement, but having into digikam would be soooo cool!

Good job!
Gaetan
Comment 34 Julien Narboux 2009-10-17 12:54:01 UTC
To implement this feature one could use the GEGL library (http://gegl.org/).

In fact it implements a generalization of the idea of action lists by action graphs. The graphs can be saved as xml (http://gegl.org/gallery/index.html).
The Digikam editor could be a QT gui for Gegl graph editing.
Nodes in the graph can be file opening, saving, applying effects to one picture (contrast, lightness...) ,  applying effects to several picture (merging layers...).

Using this library would have the following advantages:
- it is already implemented
- it is used by Gimp, so we can I hope it is well maintained
- it can deal with 32 bits floating point pictures so it could be used to represent HDR pictures as well.

But porting the whole DigiKam editor to GEGL would be huge work.

If we look at GEGL 0.1.0 it already supports the following effects :
curve, levels, channels, brightness contrast gamma, hue saturation lightness,
stretch contrast, white balance, invert, basic bw conversion, unsharp mask, simple local contrast, gaussian blur, resize, crop, rotation, text

But it is missing : 
CIMG based : noise reduction, inpainting, restoration ... 
lens correction, Digikam filters menu...

My 2 cents,

Julien
Comment 35 Marcel Wiesweg 2011-02-04 20:56:11 UTC
With 2.0, all editing action store there set of parameters in an XML format which is saved to the image's metadata. The information is accessible from the right sidebar. Most image plugins are able to replay a stored action, a good part of them will give pixel-identical result.