Bug 151232 - Support workflow with multiple folders and linked files/pictures
Summary: Support workflow with multiple folders and linked files/pictures
Status: CONFIRMED
Alias: None
Product: digikam
Classification: Unclassified
Component: Albums-MainView (show other bugs)
Version: 0.9.2
Platform: Ubuntu Packages Linux
: NOR wishlist with 56 votes (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-23 13:41 UTC by Christian Mayer
Modified: 2017-08-01 12:41 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Mayer 2007-10-23 13:43:23 UTC
Version:           0.9.2-final (using KDE KDE 3.5.8)
Installed from:    Ubuntu Packages

I'd like to work with this process:

1) download all new images in my "In Folder" (structure should be the same, date based, that is currently used)
2) promote the good JPGs and developed RAWs into my "Work Folder" (aim is to have an folder with all pictures that I'm ready to show someone). "Promote" should technicaly create an link to the original picture in the "In Folder" when it's identical. When the picture is modified (e.g. cropped or a JPG that was developed from an RAW) the new file is directly placed in the "Work Folder" - but digikam should know the relationship of the two pictures (actually that's an 1:n relation, as one source image can be used for several new images that e.g. have different crops)
3) create actual collections out of the pictures in the "Work Folder" that are stored in the "Out Folder". E.g. the best pictures from my last holiday would land there (as my holiday was several days long, that source pictures are from several subfolders in the "Work Folder" but now land in the same target folder). As these pictures are identical to those in the "Work Folder" only links should be generated.

Pictures in the "Out Folder" now can be easily selected for an slideshow or for burning them on an CD.

The technique required for that whish is basically: create links between pictures instead of blindly copy them (note: the source of an image wouldn't change with this setup, so there aren't any side effects...). And it's important that digikam keeps track of the relationship between the pictures.
Comment 1 Christian Mayer 2007-10-23 14:11:43 UTC
It would be great if this also supports "Bug 114539: Wish: Offline manager for Digikam"
But how the linked files are handled then would need an deeper thought first.
Comment 2 Arnd Baecker 2007-10-23 14:12:21 UTC
I think everything in your wish can be done using tags.
Have you tried those already, and if yes, what is missing?
Comment 3 Christian Mayer 2007-10-23 14:19:14 UTC
I'm missing the representation of that on my harddisk that represents that structure w/o digikam.

I want to open my CD burning application and drag the corresponding directory in my "out folder" on the disk to burn just e.g. my holiday pictures (to annoy my relatives ;)
Or use the slide show application of my choice (the ususally only work for an specified directory)
Or use an bash script, or, or, or...
Comment 4 caulier.gilles 2007-10-23 14:26:33 UTC
>I want to open my CD burning application and drag the corresponding directory in >my "out folder" on the disk to burn just e.g. my holiday pictures (to annoy my >relatives ;) 

Open K3b and drag and drop virtual Tag Folder content to a K3b project. It's work.

> Or use the slide show application of my choice (the ususally only work for an >specified directory) 

This is work with digiKam slideshow or Kipi-plugin Slideshow (OpenGL). What do 
you  want anymore...

> Or use an bash script, or, or, or... 

Use Drag & Drop between digiKam virtual Tags folders and a Konsole where you want to run a script: All physical files path are added to the command line...

Your workflow is interressing, but can be complex to implement as well in digiKam. Try to use a more universal way provided by virtual Tag folders...

Gilles Caulier
Comment 5 Christian Mayer 2007-10-23 14:34:26 UTC
Addition: tags are an way to classify the content of an picture (car, flower, holiday 2007, Mr. Jon Doe, ...)

but I'm looking for an workflow / process of image handling (take picture -> download in digikam -> in -> work -> out). So the basic image stays the same, but has reached different processing steps.
Just think of an image that I take (only) as RAW of an flower during my holidays.

The "In Folder" would contain the RAW file. There it gets tagged e.g. with "Flower", "Sunflower" and "Holiday 2007" as well as an rating of 5 stars.
Then I'll generate an JPG out of it and it'll gets stored in my "Work Folder".
Lastly I'll create two albums in the "Out Folder":
- one named "Holiday 2007" (it consists out of a selection(!) of images with an high rating as well as the corresponding tag)
- the other named "Flower Exhibition 2007" where I'll just put my 10 best flower pictures.

In the end I want to burn 2 CDs, one with my holiday pics and the other for the exhibiton...
Comment 6 Christian Mayer 2007-10-23 14:38:49 UTC
>>I want to open my CD burning application and drag the corresponding directory in 
>>my "out folder" on the disk to burn just e.g. my holiday pictures (to annoy my >relatives ;)
>
>Open K3b and drag and drop virtual Tag Folder content to a K3b project. It's work.

But this will work only under Linux... I've got an dual boot machine with Windos...

>Your workflow is interressing, but can be complex to implement as well in 
>digiKam. Try to use a more universal way provided by virtual Tag folders...

I'll try if I can get closer to my favored workflow by using more tags :)

I know that this is my most complicated whish to implement of the few I've just posted :)
Thanks for the good work so far!
Comment 7 Arnd Baecker 2007-10-23 14:57:05 UTC
 > But this will work only under Linux... I've got an dual boot machine with Windos...


Hmm, but if everything which needs to be done to your images can
be done on linux, then why switch back to Windows?

> >Your workflow is interressing, but can be complex to implement as well in
> >digiKam. Try to use a more universal way provided by virtual Tag folders...
>
> I'll try if I can get closer to my favored workflow by using more tags :)
>


> I know that this is my most complicated whish to implement of the few I've just posted :)


Well, I think the suggested approach with symlinks does not correspond
to the way digikam works.
The central concept for organization are tags and
virtual folders (including the date view and searches).
Therefore, anything which is not possible
should be improved within this framework
(for example grouping of images is planned for the future
and many other things, which will be possible after the
transition to KDE4 and the new database scheme).

Of course, code contributions to any of your wishes
are very welcome!

Best, Arnd
Comment 8 Christian Mayer 2007-10-23 16:15:38 UTC
> Hmm, but if everything which needs to be done to your images can
> be done on linux, then why switch back to Windows?

When all my word processing tasks can be done with M$ Word, why should I switch to OpenOffice?

That argument doesn't count.

It's actually the other way round:

I want the flexibility of tools. I don't want to be locked in one tool set. I allways want to be able to change to another tool. That's what open source is really about: freedom.

BTW: what makes you so sure, that all I want to do with my pictures can be done under Linux?
I'm still missing a good HDR tool and dcraw also doesn't allways fit my needs. GIMP is great - but also sometimes seems a bit cryptic to me...

digikam has 95% of the features I want (and many more features I'm not using but that are important to lots of other people), for the last 5% I've just written the whishes that would make digikam perfect for me :)
Keep up the good work!
Comment 9 Arnd Baecker 2007-10-23 16:40:12 UTC
> When all my word processing tasks can be done with M$ Word, why should I switch to OpenOffice?
>
> That argument doesn't count.


Indeed, we are not talking about word-processing here...

> BTW: what makes you so sure, that all I want to do with my pictures can be done under Linux?


Nothing. Note the *if*!

> I'm still missing a good HDR tool


qtpsfgui is coming along nicely.
Comment 10 Bro 2007-10-23 16:54:06 UTC
Hi,

Let's say I took 4 pictures (from 2 to N), I then made a panorama using Hugin. Using tags to keep track of the original 4 pictures in the final diaporama is not ,IMHO, optimal, is-it? What if I am a panorama fan, how many tags should I create?

It is nowdays, time to give feeling about new DB design. So what about a n:n relationship between pictures (related), or even better, a picture could have n parents, and n children (more precise than related). I think this cannot easily be done using tag.

Keep going the great job.


Bruno D.
Comment 11 Arnd Baecker 2007-10-24 08:08:47 UTC
Hi Bruno,

for panorama shots I use "ForPano" and "Panorama" as tags
for the images out of which a panorama is composed and "Panorama"
for the final panorama.
By using a file name for the resulting panorama, which
is composed of the file name of the first and last image
and by using as exif  time the time of the last image + 1 second,
the images get properly ordered on display and their relation
is made clear.

For digikam >0.10 it is planned to allow for grouping of images, 
http://bugs.kde.org/show_bug.cgi?id=121310

> It is nowdays, time to give feeling about new DB design. 

The new database design (which is being implemented for digikam 0.10, 
which uses the upcoming KDE 4) has been discussed 
at several occasions, both on the digikam-users and digikam-devel
mailing lists, see eg.
http://mail.kde.org/pipermail/digikam-users/2007-October/004232.html
and more via google.
A list of ideas has also been collected in the wiki, 
  http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion
The reference for the new schema is
http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=log

Still, I would suggest to keep further comments on 
this bug report to the issue of the proposed workflow using links.
Other ideas about the database should be either given at the
corresponding wishes in the tracker, or in a new entry, if appropriate.

HTH, Arnd
Comment 12 Ariel Garcia 2009-05-03 13:22:42 UTC
Hi, I fully second the comment #5 from Christian.

No, i don't think everything can be done using tags (or it gets way too awkward). I find that some built in support for even -part- of the workflow described in the first posting would make things much easier and enjoyable :) A first step in that direction could be IMHO the following suggestion:

- add a built in concept of "original image" and automatically "relate" images that are derived of that one. Tags are here not enough, i don't want to add a new different tag for each image! And tagging all original images with "original" doesn't help much.

When i tag  
    pic123.jpg or pic123-lowres.jpg
with ***** i want that automatically the related
    pic123.nef (raw) or pic123-hires.jpg
gets tagged also.

Same of course with HDR/Panorama fotos, it would be great to be able to select the full set and "mark as related". Then when you later find one of the photos of the set and say "what the crap, why did i take this photo?" and want to delete it, digikam warns you "this pic is part of a 10 photo set, R u really sure?" ;-)

BTW, Digikam is awsome, thanks for the great work! :-)
Comment 13 Juergen Flosbach 2009-06-18 10:16:06 UTC
Hallo every body
This topic is actually what I was looking for.
May I explain what I try to do and how I think I could solve my problem ?

I have many pictures from my last vacation and want to generate a slide show.
I wold then go through my images and link the interesting ones to my slidshow folder
In slidshow folder I now can rename to the order I want my pictures for the dlide show. Or I deleted files I don't want in my slideshow by deleting the link, so without touching the original ones and I don't wast extra disk space.
I then would edit the remaining images ( crop, resize, .. ) BUT if I save the processed image the link gets replaced by the changed image and the original in the fare away folder stays untouched.

That are my thoughts about how I would do it. I know the first 2 steps I could do with tags. BUT I would always work with my originals what's dangerous. If we can link images to another place and say that any change to the image cuts the link to the original and the new image can be saved as a separate one in the place where I rigt now.

What do you think about that ?

Your Digikam lover ;) Juergen
Comment 14 Roman Prots' 2010-01-14 14:07:28 UTC
*** This bug has been confirmed by popular vote. ***
Comment 15 Roman Prots' 2010-01-14 14:11:22 UTC
Summarizing:

Usually after RAW images are getting converted (whether using digikam or external tools) we will receive JPEG files with the same name in the same directory.


What we may want to have:
* ability to have files with the same name (these can be .raw, .jpg and .ufraw) and the same directory to be linked automatically. Whenever I rate JPEG file and set tags on it this setting is synchronized with RAW and any other linked file.
* when jpeg file is moved in the other directory ask whether user wants to move all linked files also.
* when I delete JPEG or RAW ask whether user wants to delete all linked files also.
Comment 16 caulier.gilles 2014-08-30 22:05:54 UTC
Roman,

The feature to group items together available in AbumGUI is not enough to solve this file ?

Gilles Caulier