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

[Aaron Digulla]

------- 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         
           Summary: Simulate changes to images only
           Product: digikam
           Version: 0.8.1
          Platform: SuSE RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: digulla hepe com


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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-04-12 11:18 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Aaron Digulla]

------- 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 digulla hepe com  2006-04-12 12:06 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 martinrehn hotpop com  2006-05-25 19:18 -------
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?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

------- 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 glaurent telegraph-road org  2006-05-25 19:31 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Aaron Digulla]

------- 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 digulla hepe com  2006-05-28 22:19 -------
I can't find the article right now but I think many picture viewers/archivers like ACDSee and IrfanView can do this.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Image Editor
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-09-03 20:04 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joek pckconsult com



------- Additional Comments From caulier.gilles free fr  2006-09-05 20:58 -------
*** Bug 127039 has been marked as a duplicate of this bug. ***
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahuggel gmx net



------- Additional Comments From caulier.gilles free fr  2006-09-06 10:18 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

------- 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 glaurent telegraph-road org  2006-09-06 10:55 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- 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 marcel.wiesweg gmx de  2006-09-06 13:45 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

------- 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 glaurent telegraph-road org  2006-09-06 14:10 -------
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).
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- 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 marcel.wiesweg gmx de  2006-09-06 19:17 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- 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 ahuggel gmx net  2006-09-07 04:34 -------
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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-09-07 07:28 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- 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 arnd.baecker web de  2006-09-07 07:53 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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 caulier.gilles free fr  2006-09-07 08:01 -------
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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel