[Bug 142056] New: Save changes of raw

[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         




------- Additional Comments From caulier.gilles gmail com  2008-08-05 10:32 -------
Dotan,

Thanks for this analys from F-Spot.

Note than using capitalized char in filename is a problem under win32 filesystem. M$ manage very bad this point. So, like we will port digiKam under win32, i recommend to not use capitalized char here.

Also, i don't like very well this file name annotation.

We will working on versioning after than 0.10.0 will be released. we need to patch again database version to add these informations and make the versionning interface as well. We need to wait to stabilize the new database interface before to implement versionning. After that, all will be more simple.

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




------- Additional Comments From kde-2 dotancohen com  2008-08-05 10:49 -------
Very good, Gilles, as I don't like the way F-Spot does it either. In my original comment I suggested the annotation "-modN" so that the filenames would become:
dscf3252.jpg
dscf3252-mod1.jpg
dscf3252-mod2.jpg

Is that acceptable to you? Or is the whole idea of filename annotation unacceptable to you? If so, then the modified files would have to be kept separately, which I do not think is a good idea.
_______________________________________________
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-05 10:57 -------
If I understand correctly, these files are saved by user interaction,
right? Ie, it's the user that requires storing the version with
something similar to "save" button.

The disadvantage of saving .jpg files versus an .xml with changes ( as
suggested by the reporter) is that if you save a jpeg file you cannot go
again to that version 1 month later and change parts of what was done.
The jpeg doesn't contain the history of changes. So you have to redo the
image from the very beginning.  I understand it's much more simple to
implement though.
_______________________________________________
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         




------- Additional Comments From caulier.gilles gmail com  2008-08-05 11:00 -------
Dotan,

Using a suffix as versionning of file is always better, like this original filename and extension is preserved and we don't need to make a wrapper to extract it. Using standard Qt API will work like QFileInfo::fileName().

So something like that is better:

dscf3252.jpg
dscf3252.mod1.jpg
dscf3252.mod2.jpg
...

With Qt API we are able to extract the last extension suffix as well ("jpg"), or the complete one ("mod2.jpg"). extracting the revision annotation is easy to implement.

Gilles
_______________________________________________
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         




------- Additional Comments From caulier.gilles gmail com  2008-08-05 11:04 -------
Unai,

I always don't to use sidecar file. It will bloat hard drive.

Also, we have a database for that. So search all revision 2 of all modified files is possible for exemple. You cannot do it easily and speedly using sidecar.

Note : it's the same for all XMP sidecar file. I work very hard to support metadata writting with Exiv2. Currently JPEG, TIFF, PNG and JPEG2000 are implemented. Still all RAW files format to host as least XMP at the right place (like exiftool do).

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




------- Additional Comments From ugarro gmail com  2008-08-05 11:19 -------
I agree Gilles, sidecars can be very annoying, but I like storing 3
versions of 3MB jpeg files even less.

Now that I was looking at this movie from you, about the raw importer,

http://digikam3rdparty.free.fr/TourMovies/0.9.5-rawimporttoolforeditor.ogv

Maybe there's an even more simple way to store the image without
creating .jpeg files and not altering the raw file.
That raw importer applies all settings each time the raw file is processed.
Wouldn't it be safe and simple to store the settings of the importer in
database? Just the settings, no files, no versions.

Next time the user goes to edit the raw file, it loads the settings to
the importer, and the user can tweak it again.
The problem is it only works for changes done in the importer, but it's
the best I can think of :/
_______________________________________________
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         




------- Additional Comments From caulier.gilles gmail com  2008-08-05 11:27 -------
Unai,

This can be done only in KDE4 version. In KDE3, we will don't touch database schema.

Gilles
_______________________________________________
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 mikmach wp pl  2008-08-05 20:53 -------
Unai, problem with changes stored in some special file is that each time
you will open photo they have to be applied. For photos with long
history it could take insane amount of computer power. Some solution
would be saving original image *and* last, and only last modification
version.

I know that hard disk space nowadays is cheap but with each camera
generation files are bigger and storing all that data on HD...
_______________________________________________
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-05 21:04 -------
 Mikmach

Yes, processing the whole image is very cpu costy. That's why I was
suggesting to use it only for the raw importer tool. Raw files are
always processed from scratch anyway, so this isn't an issue, and
there's no need to store the whole history of changes.

What I don't know is how other raw processing apps manage to do this in
real time. Processing only the view on screen might help, which can be
600-800kpx only versus the full image which is 10Mpx. Which is around
10-15 times faster. But then each time the image is scrolled, they need
to be reprocessed, and some tools cannot be applied unless they are done
over the whole image.
_______________________________________________
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 21:09 -------
 Gilles: I agree that the .presuffix like you mention is the best idea. As we are now over 20 comments, I will summarize:

1) Versioning is not the same as Edit Undo.
2) Versioning will be implemented as an additional stored .jpg file, where filename.jpg is turned into filename.modN.jpg for the Nth modified file.
3) Noteworthy info is found in comment #8: http://bugs.kde.org/show_bug.cgi?id=142056#c8
_______________________________________________
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         




------- Additional Comments From caulier.gilles gmail com  2008-08-05 21:21 -------
Dotan,

>2) Versioning will be implemented as an additional stored .jpg file, where >filename.jpg is turned into filename.modN.jpg for the Nth modified file.

Why storing versionning file as JPG which lost quality by compression ? Why not to  use PNG instead ? Nothing will be lost like this.

Note: this remark is valide for others image format to version, as RAW and TIFF for ex. PNG support color management, 16 bits color depth, XMP, Exif, IPTC metadata. It's the perfect image container...

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




------- Additional Comments From ugarro gmail com  2008-08-05 21:30 -------
 Gilles,

Yes, very clever. Saving once and again to jpeg only destroys quality.
For raw I prefer processing always from scratch though, since extra
information will be lost of png is used.

@ Dotan,

I don't think the guy actually refers to versioning in the report. He
says he wants to recover the status of the picture without saving to
jpeg. I think he's thinking raw processors there, not jpeg editors.
I think that's the source of the confusion. Versioning is one thing, and
I think the report is another ;)

As a sidenote. What's the difference between the proposed jpeg
versioning and "save as" option currectly available?
I fail to see the advantage
_______________________________________________
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 mikmach wp pl  2008-08-05 22:04 -------
> As a sidenote. What's the difference between the proposed jpeg
> versioning and "save as" option currectly available?
> I fail to see the advantage


1. You don't have to remember to hit "save as" not "save". I lost sooo
   much data in that way :)))
2. "Save as" clutters album view (you have visible all versions, with
   versioning old versions will be hidden).
_______________________________________________
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-06 01:22 -------
So, having all available versions of a photo somehow "related" to the original one in the GUI would definitely help with the usability.

Regarding how other apps do the effects processing in real time, Aperture from Apple does use the OSX 10.4++ CoreImage API, which IIRC uses the LLVM backend (sort of JIT for any code parsed by the gcc frontend) to generate code targeting the GPU present in the system, or if it isn't powerful enough, the SSE extensions available. That, of course, limits the color precision to that available from the GPU (used to be so powerful only in single mode).

I don't know how Lightroom (as of 1.0) does it, as it doesn't seem to depend so much on a powerful GPU. I'd bet on decoding the images, processing them and storing the final results hidden from the user; it wouldn't use *more* space than saving an additional un-lossly-compressed copy of the RAW, However further processing from that snapshot would not hurt quality (it's RAW -> effect set 1 -> effect 2 vs raw -> effect set 1 (mmap-saved file?) -> effect 2). Only if you wanted to selectively undo effects would the image have to be regenerated from the original raw, which could be a case uncommon-enough.
_______________________________________________
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-06 14:31 -------
 Gilles: Yes, png is better. Agreed. I mentioned jpg with the [bad] assumption that the original would be jpg, and that the user would prefer the same format as the original.

 Unai: I agree that the original request here does not seem to be versioning. However, my own and other versioning request bugs were duped to this bug, so I take my arguments and interest here.

> What's the difference between the proposed
> jpeg versioning and "save as" option
> currectly available?

The versioning feature lets the new image 'replace' the original in the Thumbnail and View modes. Think of the case where you took an otherwise excellent photo of your wife, but the frame is crooked and she has redeye. With versioning you can straighten the photo and remove the redeye, without ever altering the original image. During normal use the user only sees the altered image. However, in View mode the user can select a previous version of the photo (the original as it came from the camera) and view or alter it as he sees fit. As Mikolaj pointed out, with versioning the older versions do not clutter the album.

 Jisakiel: you are thinking about Edit Undo, not versioning. The current method of editing and undoing will not be changed. The only change with versioning will be that the revised image will be saved in addition to the original, not overwriting the original.

Regarding disk space:
The disk space used with versioning will grow as O(n) with usage. This is ideal, and keeps disk space used on the same order of magnitude as without versioning. If your disk has not enough space for versioning, then it has not enough space for normal growth due to the addition of new photos anyway. If this is not familiar to you, then please read a bit about space complexity: http://en.wikipedia.org/wiki/Computational_complexity_theory#Time_and_space_complexity
_______________________________________________
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-07 00:06 -------
Thanks for the summaries, Dotan! What remains to be figured out, as far as I can tell, is whether it is possible to come up with either a fixed naming scheme for the images, or some other way to locally store the version relationships such that other programs can interoperate with Digikam.

Using the F-Spot naming convention (but perhaps using png:s instead of jpeg:s) is one idea, but IIRC it would not in itself suffice to achieve interoperability with F-Spot, since that program uses its database to actually store the version relationships. Also, the F-Spot-style file names do not tell you which version of the file is the current one.

Perhaps it is not possible to do this? But it would indeed be nice if the Digikam albums were easily browseable with file managers, viewers and other photo managers, rather than the user having to employ an "export" feature each time she wants to get her pictures out of Digikam.

The idea would be that e.g. Gwenview, dolphinpart and KPhotoAlbum would have an option to show only the current version of an image, if that is available, and perhaps even to allow the user to switch versions of an image. Just to get started, here is a suggested naming scheme, based on Gilles' comment in #18:

Suggestion 1:
img1234.jpg <- original
img1234.current.png
img1234.mod1.png
img1234.mod2.png

Here, if I create a new version from "current", that would still be named current, but the old "current" would be renamed "mod3". It becomes slightly ugly if I then decide to revert to "mod1": "mod1" would then be renamed "current", and perhaps the old "current" would become "mod3" and there would be no "mod1" any more.

Suggestion 2:
As above, but "current" is a symlink to the current version, e.g. "mod2".

Avoids the above ugliness, but I hear there are platforms with no symlinks!?

Suggestion 3:
A local (hidden) text file specifies the version relationships.

Suggestion 4:
Give up making the version state locally interpretable; just store it in the database.

That last one is simpler, but it seems to really lock you in to using only Digikam. Anyway, this was just a first go at this.
_______________________________________________
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

[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         




------- Additional Comments From caulier.gilles gmail com  2008-08-07 06:12 -------
>Suggestion 3:
>A local (hidden) text file specifies the version relationships.

You know my viewpoint about sidecar file : i hate this idea...

Using image Metadata is always better, especially XMP... We have an digiKam XMP namespace for that.

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




------- Additional Comments From martinrehn hotpop com  2008-08-07 07:20 -------
Re: #31

Yes, I agree, and I was going to get into metadata, but felt that my comment was already too long :-) So, is there a good way to do this with metadata? Maybe you'd tag the variant files something like:

VersionOfFileName: img1234.jpg
VersionOfUID: 0xF00BA8
VersionOfImageHash: 0x123456 (likely to be overkill)
ActiveVersionAsOf: 2008-08-06 13:42

Here the VersionOf tags all refer to the original image, the idea being that even if some files are renamed or removed we still have a chance to figure out the relationships. The "current" file to show would be the one with the most recent ActiveVersionAsOf tag. (Reverting to the original while keeping the variants, as F-Spot lets you do, would be a special case though, since we may not want to touch the original file at all?)

Or would one need something else or more sophisticated? I don't know; I am just trying to raise this for discussion by more knowledgeable people...
_______________________________________________
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-07 08:34 -------
 Martin:
> What remains to be figured out, as far as I can tell, is whether
> it is possible to come up with either a fixed naming scheme for
> the images, or some other way to locally store the version
> relationships such that other programs can interoperate with Digikam.

The naming scheme as proposed by Gilles will be used:
dscf3252.jpg
dscf3252.mod1.jpg
dscf3252.mod2.jpg

The 'current' photo information will be in the database, not in the filename.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel