* tony Hamilton <[email protected]> [06-26-20 09:03]: > 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.
The "function" works, that you disagree with the definition of "works" is entirely *your* problem. There are many people currently using that disagree with your chosen workpath. > 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. simply, dt does not fit your spefications. Use something else, or change your workpath. > 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. > > and all of these problems are are because you are trying to utilize an application which does not fit your *chosen* workpath. > 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] I refuse to correct your top posting and inconsiderate full quoting. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
