Culling process in digikam

Hello, I am wondering if anyone uses digikam as main DAM tool. I really like digikam and I think it has a great potential but I can’t really use it as the only DAM software in my workflow because it is not capable of grouping RAW and JPG files. This feature is really handy for the culling process and I have to use another piece of software (Zoner) for that right now. When pressed DEL key Zoner even allows you to uncheck boxes so you can pick whether you want to delete both RAW and JPG or just one of them e.g. you can keep JPG but delete RAW.
Please let me know if you found a workaround.

In case you are interested in the subject, I found a solution:

I know that sounds confusing because RAW and JPG are actually different type but same file name but it actually works!

Since Digikam has an internal recycling bin it now works perfectly for my culling process because when I delete files from SD/USB drive they do not go to the OS’s recycling bin but instead being deleted permanently.

1 Like

You an add tags to the images and display images with the same tag.

For culling I like Geeqie. It is fast for browsing and groups raw and jpg files deleting both together. Also works fast for just raw as you can set it to read the embedded jpg. But for DAM digikam is the way to go.

1 Like

I apologize for a shameless plug, but you might find this article useful:

https://scribblesandsnaps.com/2015/03/31/digital-asset-management-with-digikam/

~Dmitri

Hello,
First,I would like to know DigiKam displays thumbnails of raw files by extracting the embedded jpgs (on camera processed jpgs) or thumbnails generated from the raw data using some default processing parameters.

Secondly, IMHO using either of them for culling is incorrect because they don’t show the real raw data,they show just one finished interpretation of raw data.

Third, for more info on this please go through these links .

and

and this also

Fourth, I am expecting some feed back on right way of culling raw images, the same issue I raised in one of my previous topic and got little response.

@KVSSetty I appreciate you response but this website is all about open source tools. Unless Fast Raw Converter is an open source software there is no point to mention it. Also, every photograher after 3-6 months of using his/her camera looking at SOOC jpeg can imagine how the actual unprocessed RAW image looks like. On top of that, only very bad shots and/or a series of same shots get deleted during initial culling.

1 Like

@Andrius Neither I am interested in FRV as its not open source, but I am referring only the concepts in the blog article and not the tool itself. And I really like to see something like FRV in FOSS Imaging tools.
I am no way connected to FRV or trying to market it for some gain, I am purely interested in the concept of culling and don’t mind where that article comes from.

I’m not sure what Digikam uses, but my guess would be the embedded jpg for thumbnail views?

There is no view of un-interpreted raw data. To view it usually requires that a minimum of a few “interpretations” are made.

Then what would you want it to display?

When I’m going through images, I really am just looking at the framing, large bits of composition, and exposure. It is a conservative effort, if it looks close to being a decent frame, keep it.

I don’t think there is any “right” or “correct” way to cull images; there is what works for you and that won’t always work for others.

In my mind, culling is unnecessary for the way I shoot. You can get a 6TB disk for $250, no need to delete anything :slight_smile:

@paperdigits One thing is sure what it should display, that is, histogram of raw data. From it we get some important clues on the scope for improvement.
And another thing surely it should not display a histogram of some jpg render.

Shooting RAW, and evaluating it based on a JPEG preview is akin to making a definite conclusion about the exact shape of an object based on its shadow on a wall.

The quote above is from the first article mentioned previously

@patdavid Even I was thinking on same lines that some interpretation is necessary to view raw data ,but after going through the second article mentioned above ,some of the points made me to rethink again.
I request you to go through that article,( infact all three) and throw some light on points raised there.

In fact I want every member here, to go through all the three articles and put forward there thoughts and opinions here in this topic.
Please note the issue is not the tools of that site.

I read the second article, and all it does is describing a basic raw processing. What others state here is still true. The article compares raw and jpeg as image formats. What he forgets is that jpeg is a standard, so the monitor image looks the same (the standard leaves some uncertainties, but we keep it simple here) modulo the color chain of your setup. On the other hand, there is not one raw format, but many: dng, cr2, nef, … Besides dng, none of thees is standardized in a way that there is a standard rendering of these files. Raw interpretation in free software is based on reverse engineering of the file formats. So most of the article states true facts, but draws a conclusion that makes sense to advertise his product, but is not helpful in general. Parts of the article are nonsense, too, e.g.: “However, JPEG is a recognized image format, and thus RAW also should be recognized as an image format.” As I wrote above, there is no such thing as “the raw format” but many different raw formats.

That said, of course in some situations it would be better to base culling on raw image renderings than the embedded jpegs, but this will likely be at the expense of speed. It will be hard to speed up the code to render the raw to the same range as jpeg rendering, since you would have to optimize not for 1 but hundrets of different file formats. Furthermore, jpeg is only 8 bit data while raw usually has a higher value resolution. This will limit speed as well.

In summary, to display a RAW image one needs to know the color space (white balance is a part of this), … , one must account for linear Gamma, …

These two particular things are subjective. There is no “correct” white balance to apply, nor is there some sort of “correct” gamma tone response curve to apply. This is why there’s not really a true “view” of a raw files that is not processed in some way (and in which case it’s not really any longer “raw”, but just an interpretation of the data - same as the camera produced jpg file…).

I read all three articles and is seems like a solution in search of a problem. I can agree about the raw histogram, but I certainly don’t want to start tweaking the raw image while trying to cull. They also seem to hold the latent opinion that clipping is unacceptable, and that’s not at all true.

The histogram is number one, and sharpness and noise at >=100% view number two, especially if the embedded jpeg is of low resolution. Did not find number 3 so far.

AFAIK thumbnails are created from embedded jpeg (after all it is a thumbnail, i.e. tiny and as such certainly not a basis for culling). In preview a raw file can be either displayed as its embedded jpeg or some kind of standard rendering (just look at confiugartion of preview). So whichever you want, digiKam can do both.

@paperdigits ,Tweaking raw images during culling is acceptable provided that the tweaking is applied only to preview and save tweakings if you need (exposure compensation,white balance etc.,) in a XMP file and pass on to a raw converter of your choice for better and faster processing.

@chris , The initial culling SW can aslo show raw data statistics like the percentage of underexposed raw pixles and over exposed raw pixles,(based on the dynamic range of the modren cameras and considering anything more than say,+4stops above the EV=0 as over expose and say anything less than -5 stops as under exposed).
Also an overlay of underexposed and over exposed pixles with two different colors with switches to toggle the same.Please note everything should be based on raw data and not some jpg render data.

@patdavid what you are telling is an issue of color management ( knowing color spaces of the camera and the display monitor )and the same is true irrespective of file format. even in jpg and tiff to see proper colors we need to know these things and resolve it to see proper colors and I think raw is noway different from this issue, please clarify me if I am wrong.