* Jason Polak <[email protected]> [06-25-20 13:59]: > 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]
No, "Import" is just that, Import into library/db. If you expect more, you will be unhappy. dt is not a file manager, it is a raw photo editor. -- (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]
