I agree with Jason. Respectfully, I feel Tony is expecting the import function to copy and place the images from the card onto his computer. This is his interpretation of what import means and many would expect this as other programs use the term import to describe such actions. However, DT's action with import is just to record the folders location, generate thumbnails and generate XMP files. The XMP files will be placed in the folder with the images. In the case of an SD card this means on the SD card. I personally would never point DT to my SD card. I would move the images onto my computer and then use the import function in DT to locate the folder and generate the thumbnails.
DT is not LR. Lightroom is a great program for professional studio photographers. It is an all in one solution for importing (copying) images from SD cards to computer storage, cataloging and keywording images, basic edits, and finally publishing the images to print or websites. Adobe has made a great product here. But there is no free program out there that does everything LR does. That does not make DT inferior to LR it just makes it different. Firstly DT doesn't cost a monthly subscription. DT is a great image editor and I use it in preference to LR. I also use GIMP in preference to PS. BTW, I have access to the full suite of Adobe Creative Cloud products but prefer the open source DT and Gimp for the bulk of my work. You can download Adobe Bridge free of charge and use this for cataloging and sorting your images. I actually use LR for this function but do my edits in DT. My humble advice to the DT team is maybe do not use the term import as this means different functions to different people. On Fri, 26 Jun 2020 at 03:49, Jason Polak <[email protected]> wrote: > Interesting read. I am not a developer, just a user. But I have seen > many threads on how the import function is confusing to many people. > Personally I think import function is a little misleading in some ways. > Some people expect import to bring the photos into some kind of > database. What it does is record the location of the photos and create > XMP files, generates thumbnails and puts that into a database of some > kind (not sure if the thumbnails go in). But you get the point. > > Here "Import" really means just open the folder. So, I think the button > would be more accurate to say "Open Folder". Darktable is not a photo > downloader, and it expects the user to copy the files themselves to the > location that they want, and then open them in darktable once they have > already been organized on the filesystem by the user. > > I really have no problem with that....but I agree it is confusing. > > Jason > > On 6/25/20 1:38 PM, tony Hamilton 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] > > -- Dr Terry Pinfold Cytometry & Histology Lab Manager Lecturer in Flow Cytometry University of Tasmania 17 Liverpool St, Hobart, 7000 Ph 6226 4846 or 0408 699053 ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
