It’s been long since my last post. I was busy with other things and, to tell you the truth, i haven’t find anything to write about.
Let me explain this a bit. When i started this blog my intention was to write about solutions. Color management was a grateful issue. The idea is simple yet the implementation is very complicated. I tried to synthesize all the information i found on the web and in books, and write a guide that has the necessary technical background, but in the same time is easily understandable. I don’t know if i succeded or not, but the articles were read quite a few times.
And that is what i tried to do with other things as well. The geotagging, and the panorama posts were not howto-s, but rather reviews or short guides. I don’t want to write howto-s or step by step tutorials for certain software, becasue i neither like to read nor to write them. Naturally i read them sometimes when i’m searching for a solution to a particular problem, but i better like to explore things myself. (Beseides, a month ago i found Joel Cornuz’s blog, who is writing excellent howto-s and application reviews reguarly, about just the same software i would write about, if i would.)
My intention was to guide the attention of the interested people to certain areas and let them find the solution that fit them best by themselves.
But on the other hand i can only write about things that interests me. The problem occured when i tried to port my workflow to linux. My former workflow consisted of theese few steps: selection, metadata-editing, developing, rating, cataloging, archiving and printing. On linux i only found a few suitable software for selecting and developing. I googled a while for finding software for the above mentioned tasks, but failed.
My cataloging and archiving method relies on metadata. When i wanted to find a certain photo, i entered a few keywords, people i was looking for, event, or whatever. So what i was looking for is a metadata-editor that focuses on IPTC and XMP, and can handle DNG files, has a gui and shows at least thumbnails. Further i was looking for a cataloging application, that is customizable, focuses on IPTC and XMP metadata, can handle DNG files. And preferably theese two shall be separate applications.
I always enter metadata to the DNG-s, to avoid editing metadata twice (for original and derivative files). This is the first step (ok, the second, after trashing the photos that worth no more than that). So i was not able to port the first step. For developing raw files and postprocessing images there are quite a lot of applications, that would go easy, if i could overcome the first problem. Cataloging would be another hard issue i fear, but i nevert tried it yet, because how to catalog if there is no metadata?
This made me so dejected, i even made fewer photos lately (and even those are undeveloped yet). I only have hope on the next release of f-Spot and Digikam. Maybe, who knows. I love linux, but from a photographers point of view, the applications available are very few. This can be well understood. Developers are making software they are interested in (in general). This is why there are image-editors and -viewers, but no asset-management, or workflow software. The latter few are mainly used by professional photographer, who are unlikely to be developers (actually, this may not be true, for i am not a professional, but i use them, and so may be a lot of other people). I think that this situation will change, and in two years (i hope) there will be both sophisticated metadata-editors as well as asset-management applications.
Currently i am learning python and pyGtk in my spare time. That is the other reason for not writing to this blog. I want to develop a GUI wrapper for exiftool. If there is no application that suits my needs, than i have to write it myself. I have some programming knowledge (not much, unfortunately), and I am curious what i will be capable of. I don’t think that it will ever be a full featured product, as my goal is to make it capable to fit in my workflow, but i will upload the source, once there will be something to upload.
If i find anything interesting meanwhile, i will post about it. Hope it will be soon.
November 21, 2007 at 6:30 am
Hi,
The only way to support DNG files in writting mode under linux, and especially with digiKam is to have the Adobe DNG SDK published under Open-Source compatible license and with full linux support. Currently the SDK can be only compilled under M$ and MAC.
http://www.adobe.com/support/downloads/dng/dng_sdk.html
Why Adobe do not publish this SDK under BSD licence like it have done with XMP SDK ???
http://www.adobe.com/devnet/xmp/
DNG is a tiff based file format, but use a JPEG lossless compression on image data supporting 16 bits color depth.
We cannot use libtiff for that. This compression algorithm is only available on DNG SDK. Also look licence in DNG SDK, you will understand why this code is not backported outside in opensource…
Alternative to this JPEG Loss Less compression is to use a linear storage of decompressed RAW image data. I have already done few code in this way for digiKam, but size of DNG file in this case are very huge. This is have no sence to use it instead original RAW image data from camera witch provide a small files size…
About metadata, digiKam team work on Exiv2 library project to support tiff writting mode. So the future is here. Writting DNG metadata will be possible (and normally with all RAW files format based on TIFF spec)
About XMP metadata support in digiKam, current implementation dedicaced to KDE4 support it !
Best
Gilles Caulier
digiKam project coordinator
November 21, 2007 at 8:21 am
Thanks for the explanation. i did not know that the dng sdk was released with that kind of license.
I’m quite disappointed, because if i understood your comment right, there won’t be a solution soon to write dng-s.
Anyway, i think it’s high time for me to try digiKam 0.9.3-beta 2 (currently i’m running 0.9.2).
Thanks again, all the best
-vivosz-
November 21, 2007 at 10:01 am
digiKam 0.9.3-beta3 is just out:
http://www.nabble.com/digiKam-0.9.3-beta3-release-t4842825.html
Best
Gilles
November 21, 2007 at 11:19 am
Thanks, but I already downloaded it yesterday. Currently i’m having some issues with configuring, hopefully will solve it soon.
November 22, 2007 at 6:46 am
2 blogs entries about new features. More will become later…
http://www.digikam.org/?q=node/265
http://www.digikam.org/?q=node/269
Gilles Caulier
November 22, 2007 at 8:51 am
Finally successfully installed digiKam 0.9.3.!
To tell you the truth I haven’t tested the app thoroughly so far, but i will definitely do it in the next few days!
November 22, 2007 at 9:25 am
About IPTC/XMP metadata, with KDE4 digiKam and kipi-plugins port, XMP is supported everywhere. A new XMP editor have been implemented, and IPTC editor have been very improved.
Look screenshots at this url :
http://digikam3rdparty.free.fr/Screenshots/MetadataEditor/
Gilles Caulier
November 22, 2007 at 2:16 pm
Hmmm…. I think i will have to download the latest version from svn 😉
November 22, 2007 at 4:20 pm
Warning. XMP support is only available with KDE4 implementation (trunk in svn)
KDE3 branch do not support XMP. Perhaps i will backport code from KDE4 to KDE3 at 0.9.4 release.
I don’t recommend to use the KDE4 yet in production. Code still not finalized or uncomplete. Stable and robust code still in KDE3 branch…
Gilles
November 24, 2007 at 5:54 pm
I think I need some clarification on a comment …
In Gilles Caulier first comment, he says that the DNG SDK needs to be released with an open-source license in order for DNG to be supported. Is that true? Does the SDK need to be licensed, or just the specification? Ie: if the spec is openly publicized/licensed, then anyone can write tools that can write DNG files that meet the specification.
Gilles, am I missing something?
November 25, 2007 at 1:59 pm
Well, I don’t know much about licensing issues, nor about the using/implementing of sdk-s, so looking forward reading Gilles’ clarification.
November 26, 2007 at 6:45 am
Well, It’s simple. Look DNG sdk web page, licensing is readable :
http://www.adobe.com/support/downloads/dng/dng_sdk_eula_win.html
From an open-source user (or developper), you accept or do not accept the licence ???
This one is fully uncompatible with open-source world of course…
This situation been the same with XMP SDK in past. Since one year now Adobe have changed the restrictive licence to BSD:
http://partners.adobe.com/public/developer/en/xmp/sdk/XMPlicense.txt
My question is why Adobe do not use BSD licence with DNG SDK ???
Gilles Caulier
November 27, 2007 at 2:09 am
Vivosz, according to the Wine AppDB, the Adobe DNG Converter works 100% under Wine.
http://appdb.winehq.org/objectManager.php?sClass=application&iId=5645
November 27, 2007 at 7:11 am
yes, its work (:=)))… but it a little bit old. New RAW file formats from recent camera are not supported. This program sound like not updated.
For example, digiKam (witch use dcraw internally) supports around 280 RAW file formats. Adobe DNG converter only 150…
Like i use always RAW files in my photo workflow (Minolta Dynax 5D), i will explain how i work :
– Picture are imported in digiKam in RAW file (MRW format)
– RAW decoding in set to 16 bits color depth.
– Color Management is set on using Minolta Camera ICC profiles.
– I use digiKam Light Table to choose the right pictures from my collection.
– When i want to edit a picture, i use digiKam image editor witch supports 16 bits color depth and can fix 90% of picture problems ! Gimp only support 8 bits color depth and is unadapted to photo editing (i hate Gimp interface) !!! For advanced edition, i use krita witch support 16 bits color depth too.
– In digiKam image editor, when picture is corrected, i save it to PNG format. PNG support 16 bits color depth, use a lossless compression algorithm, support ICC color profile, and can save EXIF/IPTC and XMP metadata. It’s a perfect file format for photograph under LINUX (better than TIFF). All my pictures are stored in RAW (backup) and PNG (editing).
– For publishing, i use of course JPEG (8 bits color depth only, not lossless, take a care). For that, Batch converter from digiKam (a kipi-plugin) is used to transform PNG to JPEG (ImageMagick is used in background). Nothing is lost, excepted color depth of course. JPEG are temporary files.
Gilles Caulier
November 27, 2007 at 8:22 am
>J Dickon Glanville Says:
>November 27, 2007 at 2:09 am e
>Vivosz, according to the Wine AppDB, the Adobe DNG >Converter works 100% under Wine.
Thanks, I know. My problem is not to convert my photos, but rather how to develop them after conversion 🙂
November 27, 2007 at 8:28 am
Gilles, where does digiKam store the data about the alterations a user make on raw files? In its database or in sidecar files? I was unable to find any info about it in the documentation.
The biggest reason of my insisting on DNG is because it contains the information about raw file editing. It’s portable. When i open it in another editor/cataloger/whatever, it looks the same and i won’t loose the previous work on the file.
November 27, 2007 at 11:09 am
>Gilles, where does digiKam store the data about the alterations a user >make on raw files? In its database or in sidecar files? I was unable to >find any info about it in the documentation.
digiKam do not yet store pictures alteration list somewhere (Image Editor Actions List). There is a file in bugzilla about this subject, and it’s planed to host this list in :
– Database to be able to perform search for ex, and to apply same changes in others pictures (by drag & drop for ex.). This require a changes of Database witch is already done in digiKam for KDE4 (0.10.0)
– In pictures metadata : XMP (as a duplicate of list from database). This require XMP support witch is implemented in digiKam fro KDE4. Also, currently Exiv2 library do not yet support TIFF file writting mode. It’s planed to do it for next major release (>0.16.0). Like this we will be able to save list in RAW file based on TIFF spec.
– In Sidecar file if picture do no support metadata, as an export option. Not yet implemented. Using XMP metadata is always the better way about portability…
>The biggest reason of my insisting on DNG is because it contains the >information about raw file editing. It’s portable. When i open it in >another editor/cataloger/whatever, it looks the same and i won’t loose >the previous work on the file.
Really. Each photo management program witch host alteration list in RAW pictures use a private TAG for that. There is no interoperability issue here. For ex, try to use Nikon RAW capture program, and edit a NEF image. All changes are store in NEF file as an editor action list in a private area…
DNG will not solve interoperability issue here. Sure, it will give a standardized way to add metadata to a RAW file (DNG is standardized, all others RAW file no). But the editor actions list data added aren’t standardized. At least, if program is right, it will use XML format (XMP based)…
Gilles
November 28, 2007 at 12:40 pm
> But the editor actions list data added aren’t standardized. At least, if program is right, it will use XML format (XMP based)…
Well i didn’t know that editor actions list, or alteration information is not standardized in DNG.
But, after thinking it over, no two applications have similar toolkit (except the apps based on dcRaw, naturally), and even if they woud have the same options, they would likely to implement slightly different algorythms to achieve similar results.
In the end, even if metadata on actions were standardized, opening an edited raw image in an other editor would result in a slightly different image.
It seems to me now, that the raw workflow’s foundation stone is to choose an application wisely, and stick to it till the end.
I understand that i will need to change my workflow, maybe abandon dng. But then how will i be able to rebuild my catalog of my several thousand dngs under linux?