On 25 June 2020 at 18:38 tony Hamilton <[email protected]> wrote:
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]
____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
