Re: [darktable-user] Are their potential probelms when using iMatch with Darktable.

[Jozef Dassen]

 

 

I just did a thorough evaluation of IMatch to catalog all my legacy images. Workflow details will vary for everybody, but I can say this:

 

- DT is a good RAW processor but a lousy Catalog with virtually no metadata.

- IMatch is an excellent Catalog with excellent metadata handling.

- You can use any RAW processor to edit you images and export JPG. With a little smart folder organization import into IMatch will be very easy.

 

If your RAW processor adds metadata, then you have to make sure it matches the controlled value lists in IMatch. This can be a headache for legacy data coming from different sources. But IMatch helps to clean this up.

XMP files are standardized and as such provide an "open" interface to your metadata.

 

The only (major) problem with IMatch is that it is Windows only.

 

Cheers, Jozef dassen

 
 

Sent: Friday, June 19, 2020 at 9:16 AM
From: "Terry Pinfold" 
To: "Guillermo Rozas" 
Cc: "darktable forum" 
Subject: Re: [darktable-user] Are their potential probelms when using iMatch with Darktable.


If you are using windows or Mac you can download and use Adobe Bridge free of charge and this may help you organise your images. 
 


On Fri, 19 Jun 2020 at 12:01, Guillermo Rozas  wrote:


(please keep the answers on the mailing list so everybody can read them)
 

On Thu, Jun 18, 2020, 19:52 tony Hamilton  wrote:



I'm in the process of using LightRoom 6 for both its DAM and its raw processor functions. At the same time I am looking at replacements - one of the main reasons being that most of my raw images come from an X-Trans sensor; Lr 6 does not demosaic these well. DT seems to be a suitable replacement as a raw processor. But it's DAM functions are not ss good as Lr's (so I'm told).




I've never used LR, but that's probably true. DT DAM capabilities are quite basic.




 

So my workflow, were I to be using DT, would be as close as possible to that which I use with Lr: acquire images (with renaming if possible), triage the images using whatever facilities there are in DT (in Lr I mainly use the 'rejected' flag on a quick pass through the imported images), crop, perform tonal correction, lens corrections, sharpening and noise correction, add/update metadata information, especially keywording, then export to jpeg.




OK, DT can do all of that. However, you'll need to be more precise about your workflow to understand if using another DAM in conjunction with it will do what you want.

 

For example, DT exports to the JPG only the metadata it knows of. If you use an external DAM, you'll need for it to independently write the metadata into the JPG, not only to a sidecar file.




For the DAM and metadata editing/keywording I am quite keen on using iMatch because It has a design philosophy which will always allow me to have access to my data  - by writing .xmp files which could be read by an alternative should iMatch cease to become available. I am concerned that DT's use of a  special .xmp is a long term risk - but maybe I don't fully understand the implications.




DT xmp's files have nothing special, you can read them with any other program just as you can read the iMatch's ones (the only difference is the name convention). All the DAM info is stored in standard metadata fields in the xmp file. You can check it by yourself, just open the files with a plain text editor.

 

The main limitation is probably that DT doesn't support many metadata fields, only the most common (although with some extra work this can be expanded in the lasts versions).

 




And that bothers me: if the developers of DT decide tomorrow that they don't want to do this any more, am I locked out of any other offering being able to access my edited images?




No, because even if the current developers suddenly stop working on it, two things will happen:

- somebody else will pick up the code and start working on it (it's open source)

- even if nobody ever touches the code again, the program will keep working forever (or at least until your OS changes enough that it's not possible to compile and run it anymore)

 

> Orr would I have to re-apply all those edits, 

> using the replacement raw processor. I think I

> already know the answer: yes, re-edit - all 50+

> thousand of them. But that is probably no 

> different to any raw processor, including Lr, is

> it?

 

Exactly, that's not different from any other RAW processor.

 

But there is an important difference: as DT is open source, you can actually see what the code does so in principle it's possible to port the editions to another program (which doesn't happen with LR). In practice, however, this probably won't happen because every RAW developer has it's own set of algorithms and it's quite difficult to match them.

 

In any case, as I said before, I wouldn't worry about it for DT. In the worst case scenario you will end up running an old program in a virtual machine.




One of the other 

Re: [darktable-user] Can I invoke an external programme from DarkTable

[Guillermo Rozas]

> I find a frequent need to invoke Photoshop as part of my workflow when
> using LightRoom and assume this requirement might still exist if I
> switch to DarkTable. Is there a way to invoke any 'external' programme
> while working in DT ?
>

Short answer: no (or 'not yet')

Long answer:

DT has some local retouching tools (like cloning and healing) and a very
powerful masking system that allows you to apply any tool to very specific
portions of the image. This usually negates the need for an external
program like Photoshop for most people.

If you need to do retouching beyond DT's capabilities you currently have a
couple of options:

- some Photoshop-like programs (for example, Gimp and Krita) can use DT as
their RAW processor. This would be like calling LR from PS, the exported
picture ends up in the canvas of the caller program for further retouch

- you can always export from DT to a 16 or 32bit TIFF and edit that image
in your external program

Both these options are not ideal because there is an implicit order: you
can't intermix DT and the external program editions (unless you re-import
the result), and you need to keep track of them independently.

However, there is some work underway to add the LR->PS->LR workflow you are
asking for, specifically calling Krita from DT and including its editions
in the history of the file. This would make all editions fully reproducible
and non-destructive. See here:
https://discuss.pixls.us/t/wiring-darktable-with-krita-nsfw/14938

(by the way: I recommend you to check that forum, it's much more active
than this mailing list)

Best regards,
Guillermo


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

Re: [darktable-user] Can I invoke an external programme from DarkTable

[Pascal Obry]

Le vendredi 19 juin 2020 à 08:03 -0300, Guillermo Rozas a écrit :
> > I find a frequent need to invoke Photoshop as part of my workflow when 
> > using LightRoom and assume this requirement might still exist if I 
> > switch to DarkTable. Is there a way to invoke any 'external' programme 
> > while working in DT ?
> 
> Short answer: no (or 'not yet')

There is some Lua plug-ins to launch GIMP for example. This breaks the
workflow (as does Lr & Photoshop) but it exists.

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

Re: [darktable-user] Can I invoke an external programme from DarkTable

[Guillermo Rozas]

> > Short answer: no (or 'not yet')
>
> There is some Lua plug-ins to launch GIMP for example. This breaks the
> workflow (as does Lr & Photoshop) but it exists.
>

Ok. I was of the impression that the LR-PS integration was tighter and
didn't break the workflow (never used them). If they do, yes those Lua
scripts work like that.

Best regards,
Guillermo


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

[darktable-user] Can I invoke an external programme from DarkTable

[tony Hamilton]

I find a frequent need to invoke Photoshop as part of my workflow when 
using LightRoom and assume this requirement might still exist if I 
switch to DarkTable. Is there a way to invoke any 'external' programme 
while working in DT ?



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

Re: [darktable-user] Can I invoke an external programme from DarkTable

[Pascal Obry]

Le vendredi 19 juin 2020 à 09:23 -0300, Guillermo Rozas a écrit :
> Ok. I was of the impression that the LR-PS integration was tighter
> and didn't break the workflow (never used them). If they do, yes
> those Lua scripts work like that.

Maybe this has improved recently but last time I saw a demo there was
an export of the image from Lr, and import in Ps, some work done in Ps
and then a re-import as a duplicate in Lr (don't remember the Lr term
for this) with the Ps work in it.

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

Re: [darktable-user] Lens not recognized in Darktable 3.0.2

[Dusenberg]

  
  
I had the same problem on my Nikon when I bought a
  Tokina 24-70mm F2.8 AT-X Pro for it. The issue is that the camera
  doesn't recognise the foreign lens and so does not populate the
  necessary exif fields with the lens data. It's not a Darktable
  issue.
  
  This is my understanding of the situation. 
  
  The camera gets an id number from an attached lens( '141' in your
  case, '137' in mine)  and uses it to look up the lens data in it's
  internal table which it then includes in exif makers data in a raw
  file. Darktable (and many other photo apps) use exiv2 to query the
  exif data in a raw file and exiv2 returns the data as set by the
  camera.  However when a Nikon (and maybe other makes) identifies a
  foreign lens it seems to allocate an arbitrary id and marks it
  'Unknown (8D 54 68 68 24 24 87 02)' in exif. This is what exiv2
  reports to the application.  This means Darktable has no data
  which it can use to process the lens - so can't lookup the lens in
  lensfun for correction info.
  
  It's a camera manufacturer issue that manifests in exiv2, and is
  discussed here https://dev.exiv2.org/boards/3/topics/2782
  and described by exiv2 developer here: http://dev.exiv2.org/projects/exiv2/wiki/Lens_Recognition_in_Exiv2_v026_(and_later)/

  While you will be able to manually select the lens in Darktable
  Lens Correction module, I unfortunately couldn't because the lens
  wasn't in lensfun. At first I tried to use other lenses correction
  data but this wasn't satisfactory so I calibrated the lens, which
  is now in the latest lensfun db. I still had to manually select
  the lens in Darktable of course - which is a real pain if you
  process lots of images because you can't use an automatic preset
  to apply Lens Correction.

You will note the exiv2  fix is only
available for exiv2 0.26 on.  As of early 2020, I found hardly
any Linux distros that had/were planning to upgrade to that
version - OpenSUSE was one, I think Fedora the other.  Therefore
there may not be much you can do about it.  Upgrading exiv2 on a
distro . You may be able to upgrade exiv2 to 0.26 on your
platform and recompile Darktable to use it, but that will
break any graphics package that depend on the pre-upgrade
exiv2 version - which may or may not be an issue for you.
   
  I also lost the ability to add lens info to final image
  files. I scripted a workaround for this using exiftool to look for
  the bad id ('137' for me) in the LensID exif tag and then wrote
  the Tokina data into the LensMaker and LensModel tags.  This won't
  help the Darktable issue, however.
  
  Fortunately, I recently replaced my laptop with a workstation on
  which I chose to run OpenSUSE which as default has exiv2 0.27, so
  I can now use the workaround described in the exiv2 link, and the
  problem is solved.
  
  Good luck

On 15/06/2020 21:39, Michael Rasmussen
  wrote:


  Hi all,

Weird problem in Darktable where lens is not found although there are
lens corrections available in Darktable for the specific lens.

Darktable recognizes the lens as '141'

Hardware:
Nikon D600
Tokina 100mm F2.8 MACRO AT-X M100 PRO D

Software

dpkg -s libimage-exiftool-perl
Package: libimage-exiftool-perl
Status: install ok installed
Priority: optional
Section: perl
Installed-Size: 20932
Maintainer: Debian Perl Group
 Architecture: all
Version: 12.00-1

this is darktable 3.0.2+9~g5ac2260e3
copyright (c) 2009-2020 johannes hanika
darktable-...@lists.darktable.org

compile options:
  bit depth is 64 bit
  normal build
  SSE2 optimized codepath enabled
  OpenMP support enabled
  OpenCL support enabled
  Lua support enabled, API version 5.0.2
  Colord support enabled
  gPhoto2 support enabled
  GraphicsMagick support enabled
  OpenEXR support enabled

Linse info from exiftool
Lens Type   : D
Lens: 100mm f/2.8
Lens ID Number  : 141
Lens ID : Unknown (8D 54 68 68 24 24 87 02)
Lens Spec   : 100mm f/2.8 D

As can be seen Darktable uses 'Lens ID Number'.

Rawtherapee 5.8 correctly identifies the lens.






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

Re: [darktable-user] Re: Lens not recognized in Darktable 3.0.2

[Michael Rasmussen]

On Mon, 15 Jun 2020 22:54:22 +0200
Michael Rasmussen  wrote:

> On Mon, 15 Jun 2020 22:49:34 +0200
> Michael Rasmussen  wrote:
> 
> > It seems to be a problem with my own compiled version since the
> > official Debian sid 3.0.2 identifies the lens. The difference
> > between the 2 versions are that the Debian packaged version of
> > Darktable 3.0.2 is compiled against lensfun-1 while my own version
> > from Darktable git is compiled against lensfun-2?
> >   
> Wrong assumption, removing the xmp file before opening debian
> darktable showed the same behaviour so same weird thing in Debian's
> version too.
> 
> 

Nobody on the list who can help?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
https://pgp.key-server.io/pks/lookup?search=0xD3C9A00E
mir  datanom  net
https://pgp.key-server.io/pks/lookup?search=0xE501F51C
mir  miras  org
https://pgp.key-server.io/pks/lookup?search=0xE3E80917
--
/usr/games/fortune -es says:
Professional driver on closed track.


pgpKK0jmfuSAA.pgp
Description: OpenPGP digital signature

Re: [darktable-user] Can I invoke an external programme from DarkTable

[Terry Pinfold]

Regardless of LR or DT when you want to work in another editor such as PS
or GIMP the raw image must be exported as a new file with tiff being
superior to jpeg for this purpose. I would just like to see an easier
option to do this process. But currently I am scanning hundreds of old
images as tiff files, I open the tiff files in DT and perform certain
functions that darktable does really well including denoise, sharpen and
local contrast (save as a style). I then export the image and open the
image in GIMP and use the healing tool to remove dust and scratches (prefer
GIMP for this) and also might do some final tweaks for color, levels or
curves (yes these could have been done in darktable). The only advantage LR
has over DT is that it would track the export of the image and include it
in the catalog. Maybe if DT could do an export and automatically include
the image in its catalog that might be a minor improvement. But really DT
is not a great catalog system but an incredible raw editor. Great job done
by the developers with DT and the developers of GIMP.

On Fri, 19 Jun 2020 at 22:34, Pascal Obry  wrote:

> Le vendredi 19 juin 2020 à 09:23 -0300, Guillermo Rozas a écrit :
> > Ok. I was of the impression that the LR-PS integration was tighter
> > and didn't break the workflow (never used them). If they do, yes
> > those Lua scripts work like that.
>
> Maybe this has improved recently but last time I saw a demo there was
> an export of the image from Lr, and import in Ps, some work done in Ps
> and then a re-import as a duplicate in Lr (don't remember the Lr term
> for this) with the Ps work in it.
>
> --
>   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
>
>

-- 
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] Lens not recognized in Darktable 3.0.2

[Michael Rasmussen]

On Fri, 19 Jun 2020 17:26:07 +0100
Dusenberg  wrote:

> 
> Fortunately, I recently replaced my laptop with a workstation on
> which I chose to run OpenSUSE which as default has exiv2 0.27, so I
> can now use the workaround described in the exiv2 link, and the
> problem is solved.
> 
Thank's for the reply.

I build my own darktable from git using exiv2 so I should be covered.
exiv2 --version
exiv2 0.27.2

Package: libexiv2-dev
Status: install ok installed
Priority: optional
Section: libdevel
Installed-Size: 1435
Maintainer: Debian KDE Extras Team
 Architecture: amd64
Source: exiv2
Version: 0.27.2-8


-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
https://pgp.key-server.io/pks/lookup?search=0xD3C9A00E
mir  datanom  net
https://pgp.key-server.io/pks/lookup?search=0xE501F51C
mir  miras  org
https://pgp.key-server.io/pks/lookup?search=0xE3E80917
--
/usr/games/fortune -es says:
  If you fall and break your legs, don't come running to me. -Samuel
  Goldwyn


pgpIYUoSFEZtv.pgp
Description: OpenPGP digital signature

Re: [darktable-user] Can I invoke an external programme from DarkTable

[William Ferguson]

When you use the lua-script, gimp.lua to do the export, the result is
imported back in and grouped with the original file.

You could also use the retouch module in darktable which includes a healing
tool.  I used to go to GIMP for all my retouching, but now I seldom use it
because I can accomplish what I need in darktable.

On Fri, Jun 19, 2020 at 6:40 PM Terry Pinfold  wrote:

> Regardless of LR or DT when you want to work in another editor such as PS
> or GIMP the raw image must be exported as a new file with tiff being
> superior to jpeg for this purpose. I would just like to see an easier
> option to do this process. But currently I am scanning hundreds of old
> images as tiff files, I open the tiff files in DT and perform certain
> functions that darktable does really well including denoise, sharpen and
> local contrast (save as a style). I then export the image and open the
> image in GIMP and use the healing tool to remove dust and scratches (prefer
> GIMP for this) and also might do some final tweaks for color, levels or
> curves (yes these could have been done in darktable). The only advantage LR
> has over DT is that it would track the export of the image and include it
> in the catalog. Maybe if DT could do an export and automatically include
> the image in its catalog that might be a minor improvement. But really DT
> is not a great catalog system but an incredible raw editor. Great job done
> by the developers with DT and the developers of GIMP.
>
> On Fri, 19 Jun 2020 at 22:34, Pascal Obry  wrote:
>
>> Le vendredi 19 juin 2020 à 09:23 -0300, Guillermo Rozas a écrit :
>> > Ok. I was of the impression that the LR-PS integration was tighter
>> > and didn't break the workflow (never used them). If they do, yes
>> > those Lua scripts work like that.
>>
>> Maybe this has improved recently but last time I saw a demo there was
>> an export of the image from Lr, and import in Ps, some work done in Ps
>> and then a re-import as a duplicate in Lr (don't remember the Lr term
>> for this) with the Ps work in it.
>>
>> --
>>   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
>>
>>
>
> --
> 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
>


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