Re: [darktable-user] Import: I'm failing at step 1; advice please

[Michael]

Not true. A copy of a CSV import into a spreadsheet is not made until the user 
executes the "Save As" command. At least that is true of the five different 
spreadsheet programs I have used over the last 35 years.


On June 25, 2020 9:46:50 PM UTC, Robert Krawitz  wrote:
>On 6/25/20 1:55 PM, Pascal Obry wrote:
>> Le jeudi 25 juin 2020 à 13:48 -0400, Jason Polak a écrit :
>>> Here "Import" really means just open the folder.
>> 
>> No, it really means "import" as the pictures are indeed added as
>> references into the database. The "import" as in say Python really
>> means the same think, make it available, bring it "there" for being
>> workable.
>
>Think about this from a non-developer perspective.  If I'm using a
>spreadsheet, and I import a CSV
>file, I'm actually making a copy of it, not simply referring to it. 
>There are ways of creating a
>reference, such that the spreadsheet is updated when the reference is,
>but they're not called
>"import".  But even from a developer perspective, if I'm doing database
>work, I think of data import
>as import by value, not by reference.
>
>> I would certainly see "open the folder" as far more confusing.
>
>But that's exactly what it does, if one looks at it from the standpoint
>of a file manager (Dolphin,
>Finder, what have you).
>
>darktable user mailing list
>to unsubscribe send a mail to
>darktable-user+unsubscr...@lists.darktable.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Patrick Shanahan]

* Robert Krawitz  [06-25-20 18:12]:
> On 6/25/20 1:55 PM, Pascal Obry wrote:
> > Le jeudi 25 juin 2020 à 13:48 -0400, Jason Polak a écrit :
> >> Here "Import" really means just open the folder.
> > 
> > No, it really means "import" as the pictures are indeed added as
> > references into the database. The "import" as in say Python really
> > means the same think, make it available, bring it "there" for being
> > workable.
> 
> Think about this from a non-developer perspective.  If I'm using a 
> spreadsheet, and I import a CSV
> file, I'm actually making a copy of it, not simply referring to it.  There 
> are ways of creating a
> reference, such that the spreadsheet is updated when the reference is, but 
> they're not called
> "import".  But even from a developer perspective, if I'm doing database work, 
> I think of data import
> as import by value, not by reference.
> 
> > I would certainly see "open the folder" as far more confusing.
> 
> But that's exactly what it does, if one looks at it from the standpoint of a 
> file manager (Dolphin,
> Finder, what have you).

and dt is *definitely* not a file manager nor does it pretend to be such.

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Patrick Shanahan]

* Jason Polak  [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 thatbut 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 

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Robert Krawitz]

On 6/25/20 1:55 PM, Pascal Obry wrote:
> Le jeudi 25 juin 2020 à 13:48 -0400, Jason Polak a écrit :
>> Here "Import" really means just open the folder.
> 
> No, it really means "import" as the pictures are indeed added as
> references into the database. The "import" as in say Python really
> means the same think, make it available, bring it "there" for being
> workable.

Think about this from a non-developer perspective.  If I'm using a spreadsheet, 
and I import a CSV
file, I'm actually making a copy of it, not simply referring to it.  There are 
ways of creating a
reference, such that the spreadsheet is updated when the reference is, but 
they're not called
"import".  But even from a developer perspective, if I'm doing database work, I 
think of data import
as import by value, not by reference.

> I would certainly see "open the folder" as far more confusing.

But that's exactly what it does, if one looks at it from the standpoint of a 
file manager (Dolphin,
Finder, what have you).

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Why does Darktable import more images than exist on my SD card?

[tony Hamilton]

Hi Terry,

I had not considered this option (as you can see from my long posting 
just a few minutes ago), but what you say makes good sense to me - I see 
you share my concern about the security of images on the SD card. That 
factor really gave me the heebie-jeebies when I realised what DT was 
doing - shudder... I'll examine this in more detail.


Tony

On 24/06/2020 02:49, Terry Pinfold wrote:

Hi Tony,
      since you have LR use that program to import and organise your 
files. It is well designed and excellent at that task. It also does 
good editing of Raw files, but DT is more sophisticated in the edits 
you can do. I own LR and use it as a catalog, sometimes to do panorama 
stitching and sometimes HDR images. But I love DT editing far more 
than LR editing usually. Focus on what DT does great, which is editing 
not cataloging. BTW, the extra images may be JPG files associated 
(embedded) with Raw files but I am not sure. I also recommend never 
letting the computer delete images from your camera's SD card. I have 
seen this as a cause of problems with my photography students in the 
past. I recommend copying images from the Sd card. Ensuring you have a 
minimum of two copies of the original on separate drives. Then, and 
only then, format the card in the camera to clean up the card.  I 
would format rather than delete all images. Hope that helps.


On Tue, 23 Jun 2020 at 21:30, tony Hamilton > wrote:


In addition to the difficulties I am having with import (the
subject of
an earlier posting) I now find that DT imports  more images than
there
are on my SD card. The camera tells me my card has 52 images; Windows
tells me my card has 52 images. Lightroom finds and imports 52
images.
iMatch tells me there are 52 images and adds them to its database
as I
expect. DigiKam does likewise. DT, uniquely, finds 72 of these 52,
providing sometimes as many as 8 images with the same file name. What
causes this strange behaviour and how can I trust that DT is also not
'losing' some images on import, in addition to 'creating' some?


darktable user mailing list
to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org




--
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 darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Import: I'm failing at step 1; advice please

[tony Hamilton]

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 

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Terry Pinfold]

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  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 thatbut 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 

Re: [darktable-user] Import: I'm failing at step 1; advice please

[August Schwerdfeger]

Agreed, "open folder" is an inaccurate description for the import operation.

However, there might be some greater distinction made between the
'gphoto2'-based device import, which does move images according to the
patterns in the session options, and the other two, which leave them in
place.

--
August Schwerdfeger
aug...@schwerdfeger.name

On Thu, Jun 25, 2020 at 12:56 PM Pascal Obry  wrote:

> Le jeudi 25 juin 2020 à 13:48 -0400, Jason Polak a écrit :
> > Here "Import" really means just open the folder.
>
> No, it really means "import" as the pictures are indeed added as
> references into the database. The "import" as in say Python really
> means the same think, make it available, bring it "there" for being
> workable.
>
> I would certainly see "open the folder" as far more confusing.
>
> --
>   Pascal Obry /  Magny Les Hameaux (78)
>
>   The best way to travel is by means of imagination
>
>   http://www.obry.net
>
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>
>
> 
> 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

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Juan Navarro]

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  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  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 

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Simon Wren]

 
 
  
   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  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, 

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Šarūnas]

On 6/25/20 1:38 PM, tony Hamilton wrote:
> ...
> 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, ...

Copy RAW files from cameras or external storage into your computers
using OS file managers.

Use RAW processing software for processing RAW files into something else.

-- 
Šarūnas Burdulis
math.dartmouth.edu/~sarunas



signature.asc
Description: OpenPGP digital signature

Re: [darktable-user] Import: I'm failing at step 1; advice please

[Jason Polak]

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 thatbut 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 

[darktable-user] Tag search

[David Vincent-Jones]

If I have a tag set 'Italy|Rome|Forum' I am able to correctly recover 
those Forum items simply using '%Forum' but if I use '%Italy' none of 
the lower classes of imagery are shown. Is this how it should be 
working? I was expecting that all of my Italy material would be shown.


David



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org