This is an update after a few days of intense, all-day, reading and
experimentation with the import function of DarkTable 3.0.2. What I am
going to write here is at considerable length and will not be well
received by the Darktable development team. It is my personal opinion;
it reflects my skill as a programmer (essentially non-existent) and the
experience using DT on my system. This caveat is not a cop-out: the
major cause of my problems with Darktable import looks like a Windows
problem (compounded by a design decision by the DT development team.).
This means that some Windows systems will behave as expected; mine do not.
I find the import function in Darktable to be essentially dis-functional
and dangerous In my environment: there is the risk of loss of data which
is more probable than when using any of the other raw processors I am
considering, with the exception of RawTherapee. For my circumstance
there is no way that I will use the import function in DT (or
Rawtherapee) even for those limited cases where the function works at all.
I have 4 computers running Win 10; 2 of them dual boot to Linux Mint
19.3 (Cinnamon and XFCE). Most of my comments apply to the Windows
configuration. I would prefer to run DT in Linux, but a key requirement
I have – a robust and functionally adequate DAM – is currently met by a
Windows-only product: iMatch.
There is no Windows configuration in which I can safely import either
from a media card in a reader or with a camera USB connected to the PC.
I have 2 cameras: Canon and Fuji. When using a card reader, the reader
is never discovered when I scan for connected devices. The media card is
however identified as a folder, with a drive ID. This is fatal: DT now
regards this drive as part of the database, so the included images
become unavailable as soon as the reader is removed from the PC. But
worse – much worse -is that DT will write on this device as soon as it
is selected as a folder. This awful: here is the scenario: you have
taken some valuable photos. Until you have been able to COPY them into
your photo processing system, the ONLY place they exist is on the media
card. But now DT writes data on that card, over which you have no
control (which explains why DT was able to load 72 of 52 images I
thought I had on my card). This is absolutely unacceptable to me. None
of the other raw processors I am testing (Lightroom, Capture 1,
Exposure, DXO, OnOne, DigiKam) will do this (Rawtherapee does). They
will explicitly ask for permission to change the media in any way –
usually to delete images that have been ingested. DT (and RT) are unique
in their inability to differentiate between importing via Copy and
importing via making a link.
The reason DT treat it as a folder is because the card reader is
assigned a drive letter, being Automounted. Google shows that many
people have asked how to stop this. But more worrying is that there are
even more people who have asked why the techniques to prevent automount
do not work in Win 10. There is no resolution from Microsoft to date for
this problem. The best they can offer is to do trouble shooting, which
requires use of the Group Policy Editor. That is, if you want to find
more data to help MS solve the problem, you have to buy the professional
version of Win 10. I’m not going to do that to solve a problem in DT!
The implication from MS’s position is that this problem does not occur
on every PC – so your system my be OK. None of mine are.
But is gets worse: if you attempt to disable automount, this actually
works for real hard drives. This knocks out my key backup devices – a
set of large USB drives in a grandfather/father/son usage model. There
is no way I am going to commit updates to my DAM without a functional
backup. So the advice I have received from this mailing list, to disable
automount, is not advice I will follow.
A not dissimilar situation exist when trying to import directly from the
camera: under windows only one of my computers running DT discovers and
then only my Fuji camera and then only as a folder – so the images are
not available when the camera is disconnected.. ALL of the other raw
processors, plus other key apps. like FastStone Image Viewer, Xnview,
Irfanview, Rapid Photo Downloader, iMatch, can ‘see’ an attached camera.
There is one case where an attached card is discovered as a ‘scanned
device’ and that is when a media card is inserted into the embedded card
reader on my very old Dell Studio PC. It is recognised as a ‘media
camera’ (or words to that effect) and allows an import via copy to a
destination set in preferences. This function works cleanly and quickly.
Sadly this works only under Linux on the Dell, which other wise has
insufficient resources to run DT – and cannot run iMatch at all.
The bottom line then is that if I want to use DT as a replacement for my
LightRoom 6 (which requires that I use iMatch and hence that I must run
under Windows) then I must use other software for ingesting images.
There is a candidate which stands above all the others; Rapid Photo
Downloader. It does not run in Windows. I have tried running it in a
Virtual box, but the integration with my windows-based DAM is not
working, for reasons within virtual box which are beyond my understanding.
So I failed at the first step in trying to use DT and I don’t yet see an
effective, smooth, low hassle way to get beyond that first step, making
me question whether DT is the best solution for my use case.
On 23/06/2020 17:16, Guillermo Rozas wrote:
The basic principle (of create pointers to images; those images remain
untouched) is very much what I thought/expected DT to do, based on my
user-experience with LightRoom over the last 14 years or so.
Sorry, I've never used LR and I was under the impression that it
copied the files to its own file structure, hence my assumption you
were expecting the same.
But the
end-user design and human factors characteristics of DT, as it stands
today, confuses the user on this principle - specifically the difference
in action between reading an SD card in a camera and reading it in a
card reader. To a non-IT specialist like myself these appear to be
identical operations but result in very different actions.
Yes, it's a confusing non-distinction, I'm not a DT developer so I
don't know why "camera import" was included there.
In general all the problems I have had are firmly in the classification
of 'user error': this then is a criticism I have of the DAM functions of
DT: it should prevent me from making so many errors - a well known
principle in design.
Maybe the problem lies at the origins of DT: for many years it was
more of a niche program, Linux only. It's only in the last couple of
years that its user number has skyrocketed, specially since the
introduction of the Windows version, and there are many points in both
in the UI and in the manual that shows that "less than polished"
situation. It simply has grown too fast, and when that happens and
there are too few hands, the first parts that suffer are usually
those.
The only solution to that is that more users get into the conversation
and point to these problems (in a polite and constructive way). If
you're interested, I suggest you raise those points in the forum
(https://discuss.pixls.us/c/software/darktable/19) and/or in the
github repository (https://github.com/darktable-org/darktable).
Best regards,
Guillermo
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to [email protected]
