Versioning, but not editing in digiKam
Locked
Versioning, but not editing in digiKam
 
|
Is the versioning metadata structure expected to be usable for images
that are not edited within digiKam? What about merging of multiple images such as a panorama or simply getting all of your uncooperative pets into a single 'shot' digitally? Cheers, -kyle _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
> Is the versioning metadata structure expected to be usable for images > that are not edited within digiKam? We plan to allow adding such relation manually, that is connect original with result and allow a free-text description. There were some idea to provide a copy, start gimp on it, and add the relation automatically when gimp closed. > What about merging of multiple > images such as a panorama or simply getting all of your uncooperative > pets into a single 'shot' digitally? Yes, multiple parents is possible. In the easiest case, there is a list of source photos for a single image. It's a bit difficult to display that in a treeview, because it's no more a strict tree, but the backend should be prepared. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
On Fri, 2010-11-05 at 14:58 +0100, Marcel Wiesweg wrote:
> > > Is the versioning metadata structure expected to be usable for images > > that are not edited within digiKam? > > We plan to allow adding such relation manually, that is connect original with > result and allow a free-text description. > There were some idea to provide a copy, start gimp on it, and add the relation > automatically when gimp closed. > > > What about merging of multiple > > images such as a panorama or simply getting all of your uncooperative > > pets into a single 'shot' digitally? > > Yes, multiple parents is possible. In the easiest case, there is a list of > source photos for a single image. It's a bit difficult to display that in a > treeview, because it's no more a strict tree, but the backend should be > prepared. > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel I am very excited about the versioning feature. I think it is a very, very significant step towards being a complete tool for image workflows. For versioning with external tools such as the Gimp, I think the solution is obvious. Now we have the "Open with..." menu item. What we need is another item: "Open new version with...". This item simply creates a new version on disk before it opens it with the external editor. There is no need to do anything after the external editor closes. If I end up not making any changes in Gimp after all, I can just delete the new copy manually. I don't think that is a big deal. To try to do something after the external editor closes is unreliable. What if I close digikam first? Will my changes be lost? I have a few of use cases for versioning, that I hope you have already considered: 1. Most cameras are now able to create both RAW and JPEG files at the same time. I think digikam should be able to recognize that each RAW/JPEG pair is really just two versions of the same picture. Maybe it could happen while importing from camera, but there should also be an option to do automatic "version pairing" on existing folders. I have thousands of these images. 2. When I apply some keywords/tags/metadata, I want to apply them to all versions at the same time. That could be descriptions or keywords, author, copyright, etc. But sometimes I want to apply metadata or tags to only one specific version. Both should be possible. 3. Someone mentioned somewhere that all the different versions of an image are stored in the same folder. I hope that is not a strict rule. I like to keep a repository with original images and then keep my edited versions in a separate folder tree. That makes backups a lot easier to manage. At the moment, that sort of workflow makes it difficult to find the edited versions of the pictures, but the new versioning feature will make it really easy! Whoo hoo! Assuming that I can save a new version somewhere else. 4. Is it possible to save the versioning relationships in metadata? I am concerned that the relationships will be lost if I move files around or restore part of the files from backup or something like that. If each file had a unique ID, e.g. a checksum, and the version relationships referenced those IDs, then it would be possible to restore the relationships even if the files were moved to new locations. Thank you very much for your work on this feature. For my part, it is the most anticipated new feature in digikam ever! Best regards, Mikkel Christensen _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
Please note that we have built the infrastructure, and a basic feature set, but not everything is already implemented as it could be. The important part is that implementing such features is then only a matter of putting pieces together. > 1. Most cameras are now able to create both RAW and JPEG files at the > same time. I think digikam should be able to recognize that each > RAW/JPEG pair is really just two versions of the same picture. Maybe it > could happen while importing from camera, but there should also be an > option to do automatic "version pairing" on existing folders. I have > thousands of these images. It is not implement, but considered ;-) Yes, this is one of the most obvious features we need. > > 2. When I apply some keywords/tags/metadata, I want to apply them to all > versions at the same time. That could be descriptions or keywords, > author, copyright, etc. But sometimes I want to apply metadata or tags > to only one specific version. Both should be possible. Should that be decided by setup option, or do you have some UI suggestions for this differentiation? > > 3. Someone mentioned somewhere that all the different versions of an > image are stored in the same folder. I hope that is not a strict rule. I > like to keep a repository with original images and then keep my edited > versions in a separate folder tree. That makes backups a lot easier to > manage. At the moment, that sort of workflow makes it difficult to find > the edited versions of the pictures, but the new versioning feature will > make it really easy! Whoo hoo! Assuming that I can save a new version > somewhere else. I am planning to make this configurable, but I think Martin may correct me there is not much configurability atm. At least for automatic saving. Maybe we need a way to specify the file location of the saved file manually. > > 4. Is it possible to save the versioning relationships in metadata? Yes. At least, we spent a good amount of thought on this. > I am > concerned that the relationships will be lost if I move files around or > restore part of the files from backup or something like that. If each > file had a unique ID, e.g. a checksum, and the version relationships > referenced those IDs, then it would be possible to restore the > relationships even if the files were moved to new locations. The history steps are saved in metadata. Files created by those steps are referenced by a number of criteria. Most importantly, every new file created by digikam will have assigned a UUID, that is not a checksum, but a random number. There are some other criteria, like a file hash, or simply the file path, but that's mostly for backup for files which dont have a UUID. Of course, externally editing a picture will not change the UUID, but that can't be helped (could be solved in the "gimp" scenario described above) Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
In reply to this post by Marcel Wiesweg
On Fri, Nov 5, 2010 at 09:58, Marcel Wiesweg <[hidden email]> wrote:
>> Is the versioning metadata structure expected to be usable for images >> that are not edited within digiKam? > > We plan to allow adding such relation manually, that is connect original with > result and allow a free-text description. > There were some idea to provide a copy, start gimp on it, and add the relation > automatically when gimp closed. > >> What about merging of multiple >> images such as a panorama or simply getting all of your uncooperative >> pets into a single 'shot' digitally? > > Yes, multiple parents is possible. In the easiest case, there is a list of > source photos for a single image. It's a bit difficult to display that in a > treeview, because it's no more a strict tree, but the backend should be > prepared. Thanks, clear and concise answers but, better yet, the ones I wanted to hear. :] Keep up the good work. Cheers, -kyle _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
In reply to this post by Marcel Wiesweg
On Fri, 2010-11-05 at 16:56 +0100, Marcel Wiesweg wrote:
> Please note that we have built the infrastructure, and a basic feature set, > but not everything is already implemented as it could be. The important part > is that implementing such features is then only a matter of putting pieces > together. > I know, and I understand. I just wanted to give you my input at this stage to make sure that the infrastructure can support the features at a later stage. I am a software developer myself, so I understand the complexity (although my contribution to digikam source has only been very small so far). > > > > 2. When I apply some keywords/tags/metadata, I want to apply them to all > > versions at the same time. That could be descriptions or keywords, > > author, copyright, etc. But sometimes I want to apply metadata or tags > > to only one specific version. Both should be possible. > > Should that be decided by setup option, or do you have some UI suggestions for > this differentiation? > Good question. For dialogs, I think that there should be to buttons: "Apply to this version" and "Apply to all versions" For things without dialogs (like tags), there should be a setup option for the default behaviour. The tags sidebar could also have 2 "Apply" buttons as well, but normally I don't use the "Apply" button for tags. Maybe I will, when we get versioning. Alternatively, it could be implemented in the selection mechanism. There could be different selection modes, e.g "select only the top/visible version" or "select all versions". Then the selection would determine which versions the attributes are applied to. > > 3. Someone mentioned somewhere that all the different versions of an > > image are stored in the same folder. I hope that is not a strict rule. I > > like to keep a repository with original images and then keep my edited > > versions in a separate folder tree. That makes backups a lot easier to > > manage. At the moment, that sort of workflow makes it difficult to find > > the edited versions of the pictures, but the new versioning feature will > > make it really easy! Whoo hoo! Assuming that I can save a new version > > somewhere else. > > I am planning to make this configurable, but I think Martin may correct me > there is not much configurability atm. At least for automatic saving. Maybe we > need a way to specify the file location of the saved file manually. It would be good to be able to set up a default save location for the digikam editor. That way one would easily be able to keep the entire original folder tree strictly read-only. I am very happy with all your answers. It sounds like you have already thought of everything that I was concerned about! Thank you again for your work. Mikkel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
In reply to this post by Marcel Wiesweg
>> 2. When I apply some keywords/tags/metadata, I want to apply them to all
>> versions at the same time. That could be descriptions or keywords, >> author, copyright, etc. But sometimes I want to apply metadata or tags >> to only one specific version. Both should be possible. +1 to the request ;) > > Should that be decided by setup option, or do you have some UI suggestions for > this differentiation? I would think about having per-image-version option "Enable version-specific meta-data", and with option to copy meta-data from parent items (or it is copied by default but an be cleared by single button click). In ideal world copy/clear could be configured, like "copy tags but not exif data" Gert _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
In reply to this post by Marcel Wiesweg
On Fri, Nov 5, 2010 at 16:56, Marcel Wiesweg <[hidden email]> wrote:
True. I still haven't looked into this one yet, though. Marcel, how can we detect if the RAW + JPEG are actually a pair? By filename is not enough, so I suppose by some metadata, right (because the camera itself also display the pair as one image)?
As someone already proposed, two buttons in the sidebar would be great if we're working with versioned image - Assign only to this image / Assign to whole version branch (some better captions of course) - otherwise display one like now. I'll implement this. Should be fairly easy.
Yes, there was an idea for that, but I dropped it later, because of switching the images. If you move any image from the relation anywhere else, you still have it in the sidebar among the available versions, but you can't switch to it, because it would need to switch the album as well. Also it would break the concept of "current-version" that we had back then. Now when you can have more than one "current" image, it could be done I suppose. Actually, this could also be achieved kinda easily. But - What do you think, is switching albums ok? I mean you select a version from the sidebar which is not in current album, so the album will change and you will have selected the desired version. I'm just afraid that this could seem a little chaotic to some users (suddenly all the pictures are gone and they see some bunch of other images etc).
Martin _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
> True. I still haven't looked into this one yet, though. Marcel, how can we > detect if the RAW + JPEG are actually a pair? By filename is not enough, so > I suppose by some metadata, right (because the camera itself also display > the pair as one image)? Hm, not sure. We can ask in this list: How does your camera do it? I'll need to check with mine. I'd assume that for files a (RAW) and b (JPEG) to form a pair, - the same basename, only different suffixes, when downloading from the camera, is sufficient - the exact same creation date is necessary, but not sufficient if there are other pictures with the same date+time - same value in one of some metadata fields implemented as a UUID or click counter is sufficient (see DMetadata::getImageUuid for potential candidates, but the intention there is different) Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Versioning, but not editing in digiKam
|
|
In reply to this post by Martin Klapetek
On Fri, 2010-11-05 at 22:53 +0100, Martin Klapetek wrote:
> On Fri, Nov 5, 2010 at 16:56, Marcel Wiesweg <[hidden email]> > wrote: > > > 1. Most cameras are now able to create both RAW and JPEG > files at the > > same time. I think digikam should be able to recognize that > each > > RAW/JPEG pair is really just two versions of the same > picture. Maybe it > > could happen while importing from camera, but there should > also be an > > option to do automatic "version pairing" on existing > folders. I have > > thousands of these images. > > > It is not implement, but considered ;-) > Yes, this is one of the most obvious features we need. > > > True. I still haven't looked into this one yet, though. Marcel, how > can we detect if the RAW + JPEG are actually a pair? By filename is > not enough, so I suppose by some metadata, right (because the camera > itself also display the pair as one image)? > I think that filename matching is good enough for now. The matching doesn't have to happen automatically for the entire database. For me it would be okay to have to apply a "Pair RAW/JPEG" operation manually for each album. It is easy for me to ensure that the filenames match within an album. A more automated system would be great, but the semi-automatic version solves 99% of any cases I can imagine for myself. After we finish applying versioning to our existing images, it could be an option to do it automatically during import from camera. During import I think that file name matching would be guaranteed to work. > > > > > 3. Someone mentioned somewhere that all the different > versions of an > > image are stored in the same folder. I hope that is not a > strict rule. I > > like to keep a repository with original images and then keep > my edited > > versions in a separate folder tree. That makes backups a lot > easier to > > manage. At the moment, that sort of workflow makes it > difficult to find > > the edited versions of the pictures, but the new versioning > feature will > > make it really easy! Whoo hoo! Assuming that I can save a > new version > > somewhere else. > > > I am planning to make this configurable, but I think Martin > may correct me > there is not much configurability atm. At least for automatic > saving. Maybe we > need a way to specify the file location of the saved file > manually. > > > Yes, there was an idea for that, but I dropped it later, because of > switching the images. If you move any image from the relation anywhere > else, you still have it in the sidebar among the available versions, > but you can't switch to it, because it would need to switch the album > as well. Also it would break the concept of "current-version" that we > had back then. Now when you can have more than one "current" image, it > could be done I suppose. Actually, this could also be achieved kinda > easily. But - What do you think, is switching albums ok? I mean you > select a version from the sidebar which is not in current album, so > the album will change and you will have selected the desired version. > I'm just afraid that this could seem a little chaotic to some users > (suddenly all the pictures are gone and they see some bunch of other > images etc). > As I see it, switching albums is not a problem. When I get versioning, I probably won't even be looking at my pictures in album view. Most of the time I would probably be using the Tag view instead. In that case, no switching would be visible, because all versions would probably have the tag that I use to select them. > Martin Thank you very much for your work on this! Mikkel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |