[Bug 142056] New: Save changes of raw

------- 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=142056         
           Summary: Save changes of raw
           Product: digikam
           Version: 0.9.0
          Platform: SuSE RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: peter.mueller_1955 yahoo com


Version:           0.9.0 (using KDE KDE 3.5.6)
Installed from:    SuSE RPMs

Canon 300D, raw picutres

If I modify a raw picture it wants to save a picture to disk - as jpeg, etc.

What I would like to see is that the changes I have done are stored in some xml-config, db, or what ever so that I keep them when I open digikam the next time. Then I need an option when I export that picture to tiff, jpeg, etc. if I want to export the original picture or the modified one. (or export always the modified one, I can reset the modifications).

Last but not least if you do this to a jpeg you really have to overwrite the original. I never would overwrite my original pictures. Don't do that!! Keep the changes digikam internal.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- 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=142056         
caulier.gilles gmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Image Editor
_______________________________________________
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=142056         
caulier.gilles gmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |the.original.booner gmail co
                   |                            |m



------- Additional Comments From caulier.gilles gmail com  2007-05-05 08:01 -------
*** Bug 145057 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=142056         
sami_cokar hotmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sami_cokar hotmail com
_______________________________________________
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=142056         




------- Additional Comments From casta xwing info  2007-08-14 19:12 -------
Yes !

For me, this is the most wanted feature missing in digiKam : saving the history of modifications for raw files, in an external XML/txt/watherver file
_______________________________________________
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=142056         




------- Additional Comments From arnd.baecker web de  2007-08-21 21:18 -------
For completeness, see also the discussion in
  http://bugs.kde.org/show_bug.cgi?id=103350
  http://bugs.kde.org/show_bug.cgi?id=125387
_______________________________________________
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=142056         
caulier.gilles gmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thorsten.schnebeck gmx net



------- Additional Comments From caulier.gilles gmail com  2007-08-24 22:10 -------
*** Bug 103350 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=142056         
steinar skagemo net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
      everconfirmed|0                           |1



------- Additional Comments From steinar skagemo net  2007-12-19 07:07 -------
*** This bug has been confirmed by popular vote. ***
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- 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=142056         
caulier.gilles gmail com changed:

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

[Jisakiel]

------- 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=142056         
jisakiel yahoo es changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jisakiel yahoo es
_______________________________________________
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=142056         
kde-2 dotancohen com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Save changes of raw         |Save changes of image
                   |                            |modifications with
                   |                            |Versioning.



------- Additional Comments From kde-2 dotancohen com  2008-07-15 13:03 -------
There are several dupes of this bug, and many dupes of the dupes. The basic feature that most people are asking for is versioning:
1) User has an image file
2) User modifies the image file with Digikam's Image Editor
3) User saves his modifications as a new file, which is stored alongside the original file and has the original file's metadata (Tags, XMP / IPTC data). The filename could be something like originalFilename-mod1.jpg
4) When browsing images, the user only sees the modified file. However, when selecting the modified file the user can pick which version of the file to see / save / etc.

Note that other photo management programs have this ability, notably F-Spot (http://f-spot.org/Features). I last tried this feature in F-Spot two years ago when I switched to Digikam, but it is a remarkable feature that literally adds another dimension to photo management. Instead of being frightened to modify photos, users can fire at will and interact with their photos.
_______________________________________________
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=142056         




------- Additional Comments From kde-2 dotancohen com  2008-07-15 14:33 -------
Created an attachment (id=26146)
 --> (http://bugs.kde.org/attachment.cgi?id=26146&action=view)
Screenshot showing F-Spot Versioning selection dropdown

I looked through the F-Spot implementation of Versioning and I find it very
intuitive. The Image Editor is part of the View GUI, encouraging the use of
photo-enhancing tools (especially Crop, Redeye, and a few other tools). The
Versioning selection dropdown is available in the sidebar. The modified file is
stored in the same folder as the original with the text " (Modified)" added
right before the filename extension. I found myself naturally improving photos
left and right and having a blast. It's so good that I don't want the wife to
see it, lest she pester me about moving back to F-Spot!
_______________________________________________
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=142056         




------- Additional Comments From martinrehn hotpop com  2008-08-03 04:22 -------
Since Dotan argues so nicely for the F-Spot approach, I'll duplicate my summary of how that works from bug 103350 here:
 
 1) You can never edit the original image -- any initial edit creates a new "Image1234 (Modified).jpg" file.
 
 2) The "Modified" version gets overwritten by subsequent edits, but the user can also manually choose to create new named versions.
 
 3) Only one of the versions of an image is active -- meaning it is the one that is affected by edits and also the only one that is shown in the album view. This allows you to edit images and to preserve the originals, all while not cluttering your album. The user may select which version is to be the active one.
 
 4) To revert to the original, just select that version to be active. (File->Version->Original). The modified version is kept. If you now edit the image again, a new version "Modified (2)" is automatically created so that the previous version ("Modified") is not overwritten.
 
 5) The user can delete or rename a version of a file, but not the original. (Of course images can be completely deleted, but not from the version-related menu.)
 
 In my opinion this is a very nice functionality; the user may never be aware that there is any version management going on until the day when she realizes that she just accidentally destroyed an important picture, desperately searches through the menus for a cure and to her delight finds that the original picture is sitting right there, under File->Version->Original.
 
 An additional functionality, which should be easy to implement would be to keep track of the parent of each image version, so that revisions can be presented in a tree-like fashion.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Jisakiel]

------- 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=142056         




------- Additional Comments From jisakiel yahoo es  2008-08-03 11:48 -------
It might be better, if feasible (I don't know), to do it the Aperture / Lightroom way. As far as I remember, these programs don't store modified copies of the photo, but only change sets (mask this zone, change brightness, blur something, etc). Aperture, particularly, applies the changes using the GPU for its preview to be instantaneous (but Lightroom doesn't AFAIK, so it's doable only on the CPU).

Caching some sort of thumbnails would also be an option to make it speedier (say, after applying the effect on the CPU, a thumbnail on that zoom level and the general thumbnail for picture browsing, or whatever).

This way, even if the original image is heavy on disk (say, a RAW), you can have as much modified copies as you want, as each one only take some hundred of k's.
_______________________________________________
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=142056         




------- Additional Comments From kde-2 dotancohen com  2008-08-03 16:12 -------
 Jisakiel: The problem with storing the change sets is in rendering time. Each time you want to view the image, it must be rerendered. Disk space is generally considered rather cheap, while processing time is not.
_______________________________________________
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=142056         




------- Additional Comments From ugarro gmail com  2008-08-03 17:29 -------
Well, the problem with raw management in showfoto is that it first imports the whole image (loosing raw information indeed) and then processes it at 100%.  Each time a value is changed, the whole image is processed. Each time a change is done, or undone, the whole image is saved/restored. Each time you tweak a value, the whole image needs to be re-rendered.. you see the problem?
commercial and other opensource raw processors don't process the whole image, they process a preview of it, and only when you press okay, generate the jpeg. that's why they are faster and more effective.

But this requires long changes in the way showfoto works with raws.
_______________________________________________
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=142056         




------- Additional Comments From ugarro gmail com  2008-08-03 17:47 -------
 Jisakiel & Dotan Cohen:
The only way I can see of implementing this the way Jisakiel said, would be through a kipi plugin which would do basic (or even advanced in the future) processing by loading a set of images, and doing it the way raw processors do:

load each of the images, but show a smaller preview (whatever fits on screen)
a toolbar on the right hand would allow tweaking brightness, levels, contrast... in an easy manner.
the preview would change each time the settings are changed, and each of those setting changes goes to an xml file
once done, you press okay, and all images are processed to jpeg, but xmls are kept for new reprocessing.

It's what Tools->Raw Image Converter should do except it should do history and batching. And well, current version of the converter doesn't seem to work at all here, so it needs quite a bit of fixing

What do you think?
_______________________________________________
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=142056         
ugarro gmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ugarro gmail com
_______________________________________________
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=142056         




------- Additional Comments From martinrehn hotpop com  2008-08-05 00:46 -------
I thought it might be useful to have these cross-references:

What Jisakiel suggests in #9 is the subject of bug 125387. In that bug (as well as in the now closed bug 103350) there has already been a bit of discussion on versioning vs. simulated modifications. Also related to versioning is keeping track of images that are derived from other images, such as raw and jpeg versions of the same image, or panoramas derived from more than one image. This was suggested in bug 151232.

So, for versioning: bug 142056 (this one), simulated changes: bug 125387, image relationship graphs: bug 151232.

Of course, the three ideas have lots of interactions, so the discussion on how they go together, and on the merits on versioning vs. simulated changes, has its place in more than one of the reports.
_______________________________________________
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=142056         




------- Additional Comments From kde-2 dotancohen com  2008-08-05 10:24 -------
Some people here seem to be confused between versioning and editing undo. Versioning is not the "undo" button that one has available when editing. Versioning is the concept where an edited photo is saved IN ADDITION TO the original photo, not overwriting it.

No matter what edits are done to a photo, by the mechanisms currently possible in Digikam, Digikam should provide the option to save the new photo ALONGSIDE the original photo, with a suffix added. To be compatible with F-Spot, we could use the suffix " (Modified)", so "dscf3252.jpg" would be edited, and when the user is done with his edits (redeye, crop, whatever) he saves the photo and Digikam writes the edited photo as "dscf3252 (Modified).jpg" which is a new file. The Digikam Thumbnail mode would only show the thumbnail of the modified photo, and in View mode one could choose which version to see.

F-Spot currently has this versioning feature and it is not only very useful, it is also very fun. The user can edit - interact - with his photos without fear of damaging the original file. The file names F-Spot uses go like this:
dscf3252.jpg
dscf3252 (Modified).jpg
dscf3252 (Modified(2)).jpg
dscf3252 (Modified(3)).jpg

I also do not like the use of space and the use of parenthesis, however, as Linux accepts them as valid filenames and an established photo organizing tool already uses this convention, I recommend that we adopt it in the name of interoperability.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel