Re: [darktable-user] Can I invoke an external programme from DarkTable
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
Re: [darktable-user] Lens not recognized in Darktable 3.0.2
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
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] Re: Lens not recognized in Darktable 3.0.2
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] Lens not recognized in Darktable 3.0.2
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] Can I invoke an external programme from DarkTable
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
[darktable-user] Can I invoke an external programme from DarkTable
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
> > 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
Re: [darktable-user] Can I invoke an external programme from DarkTable
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
> 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] Are their potential probelms when using iMatch with Darktable.
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 Rozaswrote: (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