FWIW, I just use a simple script that copies my images from the SD card to a Year/Month/Topic directory in my hard drive and renames the directory in the SD card to something that includes today's date. Then I use DT's import.
Juan On Thu, Jun 25, 2020 at 10:54 AM Simon Wren <si...@thewrens.co.uk> wrote: > My (limited) understanding of the import function of darktable is that > it's not for effectively copying images from one location to another (i.e., > from a camera memory card to a hard disk) but rather for copying details > about images which exist on some medium (e.g., a hard disk). Such that it's > importing not the files themselves, but details about the files. > > I'm mostly using Linux these days so do use Rapid Photo Downloader, but > when I used LR and Windows (many moons ago) I used Downloader Pro quite > successfully to copy images from cards onto hard drives: > > https://www.breezesys.com/solutions/breeze-downloader/ > > On 25 June 2020 at 18:38 tony Hamilton <shaky.st...@ntlworld.com> 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 > darktable-user+unsubscr...@lists.darktable.org > > > > > ____________________________________________________________________________ > darktable user mailing list to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
