[Digikam-devel] [Bug 125387] Simulate changes to images only

Julien Narboux Julien.Narboux at inria.fr
Wed Sep 6 08:22:36 BST 2006


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=125387         




------- Additional Comments From Julien.Narboux inria fr  2006-09-06 09:22 -------
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.



More information about the Digikam-devel mailing list