Photo-Workflow in Linux with Digikam

Well, this is not for Digi­k­am alo­ne.

You should con­sider this as a gui­de­line on how you can orga­ni­ze your digi­tal pho­tos in Linux (and the other one as well 😉 ) I am far from say­ing that this is the only way to do it, but I can assu­re you that it works and has pro­ven to be effi­ci­ent.

Some peo­p­le copy their files from the came­ra or the chip to a fol­der on the hard­dri­ve – and that’s it. Some even don’t bother to work on copies of their ori­gi­nal pho­tos and alter the ori­gi­nals direct­ly. To do that you must be eit­her very good – or very stu­pid, becau­se every mista­ke is fatal. And if you don’t app­ly non-des­truc­ti­ve pro­ce­du­res the­re is no way back. Never.

But even if you have lear­nt the hard way that copies and back­ups (on exter­nal dri­ves pre­fer­a­b­ly) are good, you may won­der how to orga­ni­ze your pos­si­bly gro­wing coll­ec­tion. If you don’t take more than 10 shots a year, don’t was­te your time, but if you shoot a lot more, plea­se read on.

This is not going to be a tuto­ri­al on mana­ging tags and key­words and Exif- and IPTC-data. I just decri­be my way of orga­ni­zing my files on file­sys­tem-level. This is only the first step. Of cour­se I also tag my files and use the various tools in Digi­k­am to sort, sel­ect, gather pho­tos by dif­fe­rent cri­te­ria. But even if I did not have the­se, I’d still be able to find quick­ly what I am loo­king for.

Three things are important:

1. I keep my raw data apart from the work-data. I even have them on phy­si­cal­ly dif­fe­rent dri­ves, so that in case on HD kicks the bucket, the other files are not con­cer­ned. I make sepa­ra­te back­ups of them.

2. I keep the sql-data­ba­se of Digi­k­am apart from both the raw-files and the work-files and do not save it on the same dri­ve. I make a sepa­ra­te back­up of it as well.

3. Once my raw pho­tos are copied to a disk, they are untoucha­ble. I always work with copies.

Yes, this means that I »was­te« some space on my hard­dri­ves. But hey, if the­re is one thing that has beco­me real­ly cheap, it is disk-space. And red­un­dan­cy is your fri­end. It means safe­ty.

[pullquote author="Me"]SESO! Save early, save often![/pullquote]

Also I like to sort my files not only by year/date, which is suf­fi­ci­ent for the ori­gi­nals, but addi­tio­nal­ly by the inten­ded use: web, print etc., as this also deter­mi­nes, in which size/resolution/fileformat I save them. Again this means that seve­ral varia­ti­ons of a file exist side by side – but in dif­fe­rent sub­fol­ders. It makes sen­se, as for exam­p­le the gal­lery in my blog requi­res a dif­fe­rent width/height than that on Devi­ant­art or Flickr. For some I add frames, for others not. And of cour­se prints need a much hig­her resolution/dpi than pic­tures for mere web-use. You get the idea…

To make the hand­ling in Digi­k­am easier, I pre­fer not to main­tain one big coll­ec­tion with all files in it, but crea­te seve­ral collections/albums accor­ding to what the pho­tos are used for.

Sounds com­pli­ca­ted? It isn’t, I assu­re you. The fol­lo­wing dia­gram should be easy to read and under­stand.

Don’t worry, if you use the import-tool of Digi­k­am to down­load the files from your came­ra, it can crea­te all neces­sa­ry folders/subfolders for you auto­ma­ti­cal­ly. Real­ly easy.

ps. When I used the term »raw«, I did not only think of unedi­ted pho­tos, but had the tech­ni­cal for­mat of the files from your came­ra in mind. If it allows you to I urge you to set your came­ra to raw-mode and not rely on jpg. Yes, the indi­vi­du­al file will be a lot lar­ger and it takes addi­tio­nal steps to edit them, but the results are worth it. Think of a raw-file as a »nega­ti­ve« like in the good old days. It con­ta­ins all the data available – and not only tho­se an engi­neer from your came­ra-fac­to­ry thinks to be neces­sa­ry.

Ques­ti­ons? Feel free to ask…

12 Kommentare

  • Thank you for an insi­de look of your pho­to work­flow. Very hel­pful for many & much app­re­cia­ted.

    • you’­re wel­co­me. I’m glad I could help.
      Oh, Greeks need any help they can get any­way 😉

  • I do have back­up at two dif­fe­rent loca­ti­ons in order to safe­guard against the ine­vi­ta­ble. But sin­ce the­re is less space on the inter­nal hdd of my lap­top I pre­fer having only some of the albums / fol­ders / direc­to­ries on it. So can you give me some tips of how to orga­ni­se par­ti­al red­un­dan­cy?

    • I think the easie­st way to deal with the limi­t­ed HD-space on most lap­tops is to use the lap­top as a »sluice«.

      The data are pum­ped through it and your favou­ri­te editing soft­ware, tag­ged, cate­go­ri­zed etc. and saved to an exter­nal HD. Or, which is my pre­fer­red solu­ti­on, to a NAS (Syn­o­lo­gy, QNap, Buf­fa­lo…).
      This exter­nal HD or NAS can then be backed up again, so your are on the safe side.

      After­wards you sim­ply sym­link the dirs that you want to see on it to your lap­top. That way you don’t »was­te« any space.

  • You got me! I asso­cia­te ›work­flow‹ with the pro­ces­sing of RAW files, editing, clo­ning, crop­ping, etc., not with how to store them.

    • 😉

      Actual­ly I am going to descri­be my »work­flow« (the way you under­stand it) soon.

      • I agree that Lucky­Back­up is a ter­ri­fic uti­li­ty to use for file coll­ec­tions.
        I think that L/B is a »front end« rather than a »back end« for rsync. One laun­ches L/B, does the goo-ey (GUI) thing, and then L/B will crea­te the rsync com­mands to accom­plish wha­te­ver you asked for. In gene­ral L/B first … rsync fol­lows. I think that a »back end« would use »rsync first … L/B fol­lows«.
        ~~~ 0;-Dan

  • My work­flow is simi­lar. I sepa­ra­te my raw pho­tos and ori­gi­nal jpgs from a working fol­der bro­ken down by date. I then use rsync to back­up my who­le /home fol­der to an exter­nal dri­ve.

Schreibe einen Kommentar