Re: [darktable-user] Building dt
What I do is cmake make sudo make install with no compiler directives for install directory. It then installs as if from a .deb, in the correct directories. For the record, I use Ubuntu, and always compile from source, since the Ubuntu repo is usually behind current development, and often does NOT include all features. YMMV with other distributions. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sat, 5 Nov 2022 at 19:23, Jean-Luc wrote: > Le 04/11/2022 à 21:58, Bernhard a écrit : > > > > Bernhard schrieb am 04.11.22 um 21:54: > > > > Jean-Luc schrieb am 04.11.22 um 17:49: > > > > So, my question : how can I manage to install it as if it were done frome > repo ? > I searched and could find with /wereis/ that it currently uses the > following directories : > > darktable: /usr/bin/darktable /usr/lib/x86_64-linux-gnu/darktable > /usr/libexec/darktable /usr/share/darktable > /usr/share/man/man1/darktable.1.gz > > > You know these instructions? > https://github.com/darktable-org/darktable#building > > It tells you to do this > > mkdir build/ > cd build/ > cmake -DCMAKE_INSTALL_PREFIX=/opt/darktable/ .. > make > sudo make install > > Hello Bernhard, > However, I notice that then the maintainer of the repository from which I > installed did follow the instructions, since dt appears in > /usr/bin/darktable instead of /opt/darktable/. > At this point, what would you advise me to do ? Backup my config and > >- unsinstall dt, erase everything related to it in the directories >above and build as described in github, or >- use cmake -DCMAKE_INSTALL_PREFIX=/usr/bin/darktable .. > > Rgrds, > > J.-Luc > > > 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
[darktable-user] xmp metadata and language
Not entirely certain of this, but here is my understanding of the language tag and the title/description (etc.) fields. There can be several title/description fields; one for each language. A language field set as “default” means, “Use this title/description when no language is given by the viewer, or if the viewer's preferred language is not present.” Any field with a specified language means, “use this title/description if the viewer's preferred language matches this one.” E.g., if I have English (non-specific) language title listed as, “Bread & Wine Festival”, French language title as, « La fête du pain et du vin », and default language title as, “Trinidad September Celebration”, then anyone with their language set to anything but French or English will see, “Trinidad September Celebration,” while someone with their language set to English or French will see the appropriate title, (and the French will see the accent in « fête »). This will mean that, if I only had one language title set up, default, with, « La fête du pain et du vin », and the circumflex shows up as tofu, changing my language to French is not necessarily going to make the ‘ê’ suddenly show up. Why Gimp is showing an empty string is that you had a default language title, in Arcen, then *added* a second language title in Arcen-Schlossgärten to the file, without adding the new title. So when your viewer language is set to, “Arcen. Schlossgärten,” Gimp correctly shows you the appropriate title field, which is empty, instead of the “default/Arcen” title field, in Arcen-Schlossgärten language. So one wants to change the metadata encoding of the XMP metadata to UTF-8 so that one gets the accents instead of tofu, (which, I understand, is possible for XMP data but not for IPTC data), but also add a title in Arcen-Schlossgärten, (or change the default language from “default:Arcen”, to “default:Arcen-Schlossgärten”). IIRC,the default encoding for XMP data is, indeed, UTF-8, which is more than adequate for most non-CJK languages —which need UTF-16-cs, I understand,— and that the default —and only— encoding for IPTC is Latin-1. I may be wrong on this. The long and short is that some accented characters may not show up in IPTC title fields, and adding a title language in metadata will only show up if the new title is also added along with the language. Please, others correct what I may have incorrect here. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 29 Sept 2022 at 13:14, Volker Lenhardt wrote: > But I'm sorry, but to include iptc tags doesn't seem to have any effect > on the xmp tags. I do get xmp.dc.title and xmp.dc.description, but gimp > shows an empty string whenever there is a special character within. I'm > not sure if it is a gimp problem, but I cannot find the trick to tell it > to use utf-8 with metadata. I hope that dt exports them as utf-8. > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] AVIF version 0.10.1 is working… on DT ver 4.1.0
So, —as we say in Jamaica— story come to bump! A few days ago, I saw that darktable 4.0.1 was finally out. I, naturally, will be doing my usual build/upgrade. Then last night as I was about to go do my usual, it occurred to me,… “wait…! Do I not already have darktable version 4.0.1?!?” So I start my darktable and lo & behold!… …I have darktable version 4.1.0! Nope! Not a typo! 4.1.0! Not only did I have the “master” of AVIF, but also the “master” of darktable. Go big or go home, am I right? Good news! So far I only found one bug in it. All recent images of myself appear at least ten pounds heavier. Aside from that, everything seems to be fine thus far. Nevertheless, since this is my production machine, I will be downgrading to 4.0.1, (and try to figure out how I got two downloads incorrect 😉 ) Sincerely, Karim Hosein Top Rock Photography 754.999.1652 P.s., I should probably check if I am running Linux kernel 5.15 or 6.0 while I am at it. 😊😉😁😀😄 On Wed, 7 Sept 2022 at 00:46, Top Rock Photography < ka...@toprockphotography.com> wrote: > SO, it seems that there is no problem, or rather, the problem was me. > Instead of compiling avif 0.10.1, I compiled from master/main, which is > prepping for version 1.0.0, (coming at some point in the future). > > Version 0.10.1 has no change to the avifImageYUVToRGB library.(Version > 1.0.0 will, with three parameters instead of two, but that is not even an > issue now). > > After downloading the actual version 0.10.1 of AVIF, and compiling it, > darktable compiled just fine, ran just fine, as did Gimp. > > Nothing to see here folks! My apologies. > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > >> >> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] AVIF version 0.10.1 (& maybe 0.10.0) is working just fine
SO, it seems that there is no problem, or rather, the problem was me. Instead of compiling avif 0.10.1, I compiled from master/main, which is prepping for version 1.0.0, (coming at some point in the future). Version 0.10.1 has no change to the avifImageYUVToRGB library.(Version 1.0.0 will, with three parameters instead of two, but that is not even an issue now). After downloading the actual version 0.10.1 of AVIF, and compiling it, darktable compiled just fine, ran just fine, as did Gimp. Nothing to see here folks! My apologies. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 2 Sept 2022 at 23:05, Patrick Shanahan wrote: > * Top Rock Photography [09-02-22 16:42]: > > A couple of errata > > > > > >1. That is AVIF version 0.10.1 (not 10.0.1), and version 0.10.0 (not > >10.0.0) > >2. The library is avifImageYUVToRGB, (not libavifYUBtoRGB) > > > > Sorry about the mistake. Still, the solution is to not upgrade AVIF > beyond > > version 0.9.3, or, if one already did, simply downgrade to version 0.9.3. > > Again, version 0.10.0 was not tested (by me). > > > > …And, yes, a bug report has been filed. > > > > Sincerely, > > > > Karim Hosein > > Top Rock Photography > > 754.999.1652 > > > > > > > > On Fri, 2 Sept 2022 at 15:03, Top Rock Photography < > > ka...@toprockphotography.com> wrote: > > > > > AVIF version 0.9.3 still does. > > > > > > I just upgraded my system to the lanes of everything that darktable > needs, > > > including EXIV2, EXIFTool, et al. > > > > > > This upgrade included all the AOMedia stuff such as dav1d, rav1e, HEIF, > > > ISOBMFF, AVIF, etc. > > > > > > Before, I had AVIF version 0.9.3. My upgrade included AVIF ver 10.0.1. > > > Darktable would not build. it claimed that libYUVtoRGB (or was it, > > > libRGBtoYUV???) requires two arguments, but the library was claiming > “two > > > few arguments.” Apparently, it requires four. > > > > > > Well, since it would not build, I just thought that I would try my old > > > build, —still the same version, 4.0.0, but built with all the previous > > > libraries before the upgrade— and everything worked, except export to > AVIF, > > > which crashed darktable. > > > > > > I tried building darktable version 4.0.1 but it had the same error. I > then > > > downgraded AVIF back to version 0.9.3 and my old build worked again. I > then > > > rebuilt darktable (4.0.0) with all the other new stuff, (but still AVIF > > > 0.9.3), and it all works, (but encodes AVIF a little faster). > > > > > > Anyway, this is NOT a bug report, (I know where and how to file those), > > > and this is not a request for help, (I solved my problem for now). > This is > > > just informative that for those on darktable versions 4.0.0 and 4.0.1, > (and > > > probably earlier), AVIF version 10.0.1 does not work, but AVIF 0.9.3 > does. > > > (I did not try AVIF version 10.0.0). > > > > > > Therefore, if you attempt to upgrade AVIF to 10.0.1 and darktable AVIF > > > export does not work, do not be alarmed. A change in libYUVtoRGB (or > was it > > > libRGBtoYUV???) is causing incompatibilities for now. > > > > > > Sincerely, > > > > > > Karim Hosein > > > Top Rock Photography > > > 754.999.1652 > > > > > > > > > > > > > darktable user mailing list > > to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > > > see my answer to your issue report. > > > -- > (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri > http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc > > > 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
[darktable-user] Re: AVIF version 10.0.1 (& maybe 10.0.0) not working
A couple of errata 1. That is AVIF version 0.10.1 (not 10.0.1), and version 0.10.0 (not 10.0.0) 2. The library is avifImageYUVToRGB, (not libavifYUBtoRGB) Sorry about the mistake. Still, the solution is to not upgrade AVIF beyond version 0.9.3, or, if one already did, simply downgrade to version 0.9.3. Again, version 0.10.0 was not tested (by me). …And, yes, a bug report has been filed. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 2 Sept 2022 at 15:03, Top Rock Photography < ka...@toprockphotography.com> wrote: > AVIF version 0.9.3 still does. > > I just upgraded my system to the lanes of everything that darktable needs, > including EXIV2, EXIFTool, et al. > > This upgrade included all the AOMedia stuff such as dav1d, rav1e, HEIF, > ISOBMFF, AVIF, etc. > > Before, I had AVIF version 0.9.3. My upgrade included AVIF ver 10.0.1. > Darktable would not build. it claimed that libYUVtoRGB (or was it, > libRGBtoYUV???) requires two arguments, but the library was claiming “two > few arguments.” Apparently, it requires four. > > Well, since it would not build, I just thought that I would try my old > build, —still the same version, 4.0.0, but built with all the previous > libraries before the upgrade— and everything worked, except export to AVIF, > which crashed darktable. > > I tried building darktable version 4.0.1 but it had the same error. I then > downgraded AVIF back to version 0.9.3 and my old build worked again. I then > rebuilt darktable (4.0.0) with all the other new stuff, (but still AVIF > 0.9.3), and it all works, (but encodes AVIF a little faster). > > Anyway, this is NOT a bug report, (I know where and how to file those), > and this is not a request for help, (I solved my problem for now). This is > just informative that for those on darktable versions 4.0.0 and 4.0.1, (and > probably earlier), AVIF version 10.0.1 does not work, but AVIF 0.9.3 does. > (I did not try AVIF version 10.0.0). > > Therefore, if you attempt to upgrade AVIF to 10.0.1 and darktable AVIF > export does not work, do not be alarmed. A change in libYUVtoRGB (or was it > libRGBtoYUV???) is causing incompatibilities for now. > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] AVIF version 10.0.1 (& maybe 10.0.0) not working
AVIF version 0.9.3 still does. I just upgraded my system to the lanes of everything that darktable needs, including EXIV2, EXIFTool, et al. This upgrade included all the AOMedia stuff such as dav1d, rav1e, HEIF, ISOBMFF, AVIF, etc. Before, I had AVIF version 0.9.3. My upgrade included AVIF ver 10.0.1. Darktable would not build. it claimed that libYUVtoRGB (or was it, libRGBtoYUV???) requires two arguments, but the library was claiming “two few arguments.” Apparently, it requires four. Well, since it would not build, I just thought that I would try my old build, —still the same version, 4.0.0, but built with all the previous libraries before the upgrade— and everything worked, except export to AVIF, which crashed darktable. I tried building darktable version 4.0.1 but it had the same error. I then downgraded AVIF back to version 0.9.3 and my old build worked again. I then rebuilt darktable (4.0.0) with all the other new stuff, (but still AVIF 0.9.3), and it all works, (but encodes AVIF a little faster). Anyway, this is NOT a bug report, (I know where and how to file those), and this is not a request for help, (I solved my problem for now). This is just informative that for those on darktable versions 4.0.0 and 4.0.1, (and probably earlier), AVIF version 10.0.1 does not work, but AVIF 0.9.3 does. (I did not try AVIF version 10.0.0). Therefore, if you attempt to upgrade AVIF to 10.0.1 and darktable AVIF export does not work, do not be alarmed. A change in libYUVtoRGB (or was it libRGBtoYUV???) is causing incompatibilities for now. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Ubuntu 22.04.1 and OpenCL
Mikael, I am one who always compiles darktable myself. I usually watch the output during cmake. It often says things such as, *Looking for libopencl-clang ≥ 12* *Suitable version not found* *Found libopencl-clang version 11.1.23. Requires version ≥ 12.* *Darktable will be built without optional OpenCL support.* …or something to that effect. The *cmake* will complete, the *make* will complete, the *sudo make install* will complete. When I find these warnings in the cmake phase, I immediately stop the compile, install the missing libraries/dependencies, clean the [build] directory, and start over. I find every now and then, when a new version of darktable comes out, they are built against newer libraries, probably for improved optimisations or to avoid bugs in older libraries. This behaviour is normal. Ubuntu will often upgrade certain toolboxes to the latest iteration of the version you have, but not to a new version, since it may break other projects on which you are currently working. For example, it may update Python3 from version 3.10.4 to version 3.10.6, or even to version 3.12.0, but if Python4 comes out, it will still only update you to Python 3.12.2, and not Python4 version 4.0.2. This is because you may still have applications dependent on Py3, and that Py4 may be incompatible. Sometimes one can install multiple versions of a toolbox, and specifically invoke the version you want. *python3 foo.py* *python4 bar.py* Anyways, now you know for future reference. Hope I was helpful. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 17 Aug 2022 at 13:12, Mikael Ståldal wrote: > I did not have that, installing libopencl-clang13 solved my problem, > thanks! > > Is this documented somewhere? > > > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] An issue with watermarks under Linux Mint
Unfortunately, Ubuntu and Mint are going in the direction of flatpaks. I
dislike that. I go through the trouble of ensuring that everything on my
system is uptodate so that I get the very latest that darktable (or any
other software) has to offer, only to find that the flatpak is using an
older version of this or that library (or missing a library altogether).
E.g., I do not think that the Ubuntu flatpak has support for the AVIF
filetype.
I download the source and compile it. The { cmake ] process actually tells
you everything which is not uptodate, and why certain features may not
work. E.g., “libdav1d-dev ≥ 0.8.9 not found. Darktable will compile without
AVIF support.” (If any version was found, it will tell you what version was
found). In that case, install/update all the AVIF files, clear the build
directory, and run cmake again. It has come to pass, from time to time,
that my distro's repository does not have a recent enough version of a
library, and so I have to download, compile, and install (usually three
simple steps), the latest library then go back to the darktable compiling.
Flatpaks are supposed to solve that problem by having everything we need in
them, and all the right versions. In theory, that works. In practice, it
often does not.
Just compiled darktable version 4.0 today. Had to update my CLang from
version 13 to 14. (The cmake spat out a warning that darktable would
compile but without support for OpenCL). CLang 14 was in the repository,
so, not a problem. Did the CLang update with Synaptic. Darktable 4.0
compiled, and is working just fine, with OpenCL support.
Having compiled, and not used the flatpak, the directories you initially
mentioned would be where to look. With the flatpak, everything is expected
to be within the flatpak directories.
Sincerely,
Karim Hosein
Top Rock Photography
754.999.1652
On Tue, 12 Jul 2022 at 12:57, Richard Hobday wrote:
> On 12/07/2022 15:28, Willy Williams wrote:
> > The version of darktable that I currently have (v 4.0) came as part of
> > the Linux Mint distro. It was not an after-initial-load add-on. I am
> > and have been quite familiar with the standard location for watermarks,
> > given a couple of years experience with Ubuntu until the 22.04 LTS mess.
> > The best part of this debacle is that I managed to find a workable
> > location for the watermarks. Almost every other app installed with
> > Linux Mint is working well. The good news out of all of this is that I
> > have darktable working well on all my machines, both Win 10 and LM. My
> > thanks to all that offered helpful advice.
> >
> > Willy Williams
> Hello Willy,
> I'm sure you will be aware of this but just to clarify for others.
> See the attached screen shot.
>
> The current 20.3 version of Linux Mint offers darktable 4.0 only as a
> flatpack in the Software Manager, although there is an outdated 3.0.1
> listed as a full install option - from Software Manager or Synaptic.
>
> H.T.H
> R.
>
>
>
>
> > *
> >
> > On 7/12/2022 at 6:22, Guillermo Rozas wrote:
> >>
> >> > >
> >>
>
> /var/lib/flatpak/app/org.darktable.Darktable/x86_64/stable/[long-ass-number]/files/share/darktable/watermarks
> >>
> >> > the *normal* location is ~/.config/darktable/watermarks
> >>
> >> The former (/var) sounds like the system location (for Mint), the
> >> latter
> >> (~/.config) for user-configurable files, which is surely what you
> >> want.
> >>
> >>
> >> /var/lib/flatpak indicates that you've installed the flatpak version
> >> of darktable, not the one coming from the .deb package from the apt
> >> repositories. In that case, the user configuration files are
> >> inside ~/.var/app
> >>
> >>
> https://unix.stackexchange.com/questions/697213/where-does-flatpak-packages-store-their-configuration-files/697214
> >>
> >> Regards,
> >> Guillermo
> >>
> >>
>
> >> 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
>
>
>
> 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] Question regarding .svg watermarks comparing Windows and Ubuntu Linux
No, Patrick. Not at all. First, There was a bug in darktable. I never did anything about it because I find that the excellent darktable team is usually very quick to fix bugs without my intervention, so I simply waited. (Usually when I go to make a bug report, one has already been filed, examined, and closed, so I do not actually have to do much of anything, except to either wait on the new subversion to be published, or pull the updated source code and recompile. Occasionally I make additional comments in the bug report for my particular use case if it seems that the discussion seems to miss critical points, e.g., someone suggests it is a bug limited to RH when I have the same issue on Ubuntu, or a KDE issue when I have the issue in GNOME). Second, Having waited so long, and the bug is still there, and in light of Pascal giving a workaround which does not work in all cases, (certainly not my cases), I have decided to go ahead and make that bug report after all. The first is a testament to how wonderful the darktable team has been in the past. The second (and the first) is an admission that they are only that wonderful because people like me make bug reports. Your statements keep suggesting that I want someone else to file a bug report on my behalf. Not at all the case. I was merely pointing out the facts that ① The issue is neither that the SVG was created in Windows, nor missing fonts. ② Converting the text to curves is not a workaround which everyone can use. ③ I have been aware of the bug for quite some time. ④ I did not make a bug report because I presumed the magnificent team would have caught it. ⑤ It is high time that I make that bug report. Not once did I suggest, or request, that anyone do something about it save for myself. Points ①-③ is germane to the thread, and statements made therein by others, including the OP. Points ③-⑤ goes to the fact that I will get on this, by filing a formal bug report. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 4 May 2022 at 17:10, Patrick Shanahan wrote: > * Top Rock Photography [05-04-22 16:40]: > > Thank you, Michael. I also thought that was clear. > > > > To respond to the other two and give clarity; the penultimate paragraph > > says, “I should have made a bug report….” > > > > That suggests that the last paragraph is referring to me making that bug > > report, to make the amazing team aware of the problem, (and why it needs > a > > fix and not a workaround). > > > > Sincerely, > > > > Karim Hosein > > Top Rock Photography > > 754.999.1652 > > > > > so you want a bug report but cannot be bothered? > > > -- > (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri > http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri > Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc > > > 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] Question regarding .svg watermarks comparing Windows and Ubuntu Linux
Thank you, Michael. I also thought that was clear. To respond to the other two and give clarity; the penultimate paragraph says, “I should have made a bug report….” That suggests that the last paragraph is referring to me making that bug report, to make the amazing team aware of the problem, (and why it needs a fix and not a workaround). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 4 May 2022 at 16:15, Michael wrote: > Gee I read that as he was going to issue a report. > > On Wed, May 4, 2022 at 3:19 PM Remco Viëtor > wrote: > >> On mercredi 4 mai 2022 02:38:36 CEST Top Rock Photography wrote: >> > The issue has nothing to do with Windows, nor fonts, and everything to >> do >> > with darktable. >> > I have only used Linux for the last umpteen years, and I had created >> some >> > watermarks —in Linux— to use with darktable. Everything was fine until >> the >> > 3.x branch. (may have been earlier). >> > >> > All my text, which looks great in any other SVG viewer, and used to look >> > great in darktable, now has overlapping characters. Converting the text >> to >> > a curve does not work, since the majority of my text is dynamic. $Title, >> > $Description, $date, $sequence-number, etc. >> > >> > I should have made a bug report, but, due to the excellent team at >> > darktable, I kept telling myself, “no problem, boss, dem soon fix dis.” >> > >> > Well, I think that it is time for a bug report. >> >> Then what's stopping you? >> >> *We* cannot do it for you, as we don't know exactly what you did/didn't >> do, >> nor do we know your system. >> >> And your mail certainly doesn't give enough info for a decent bug >> report... >> >> Remco >> >> >> >> >> darktable user mailing list >> to unsubscribe send a mail to >> darktable-user+unsubscr...@lists.darktable.org >> >> > > -- > :-)~MIKE~(-: > > > 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] Question regarding .svg watermarks comparing Windows and Ubuntu Linux
Both previous images were created in darktable; one in 2017, the other just now. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 3 May 2022 at 20:38, Top Rock Photography < ka...@toprockphotography.com> wrote: > The issue has nothing to do with Windows, nor fonts, and everything to do > with darktable. > I have only used Linux for the last umpteen years, and I had created some > watermarks —in Linux— to use with darktable. Everything was fine until the > 3.x branch. (may have been earlier). > > All my text, which looks great in any other SVG viewer, and used to look > great in darktable, now has overlapping characters. Converting the text to > a curve does not work, since the majority of my text is dynamic. $Title, > $Description, $date, $sequence-number, etc. > > I should have made a bug report, but, due to the excellent team at > darktable, I kept telling myself, “no problem, boss, dem soon fix dis.” > > Well, I think that it is time for a bug report. > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Git build failure
I always end up building darktable from scratch, myself, but I use the darktable-org git repository, here…. > git clone --recurse-submodules --depth 1 > https://github.com/darktable-org/darktable.git > cd darktable > git fetch --tags > git checkout tags/release-3.8.1 or I download the tarball from the website, here…. > > https://github.com/darktable-org/darktable/releases/download/release-3.8.1/darktable-3.8.1.tar.xz Now, regarding, “wherami,” the README.MD file states,… > Note that [LibXCF](https://github.com/houz/libxcf.git), [OpenCL]( > https://github.com/KhronosGroup/OpenCL-Headers.git), [rawspeed]( > https://github.com/darktable-org/rawspeed), [whereami]( > https://github.com/gpakosz/whereami) and [LibRaw]( > https://github.com/LibRaw/LibRaw) are tracked via git submodules, so > after checking-out darktable, you need to update/checkout the submodules > too: > > *bash* *git submodule update --init* > so that when you do… > ./build.sh --prefix $yourBinOrOpt/DarktableDirectoryHere --build-type > Release --install --sudo everything is handled. I actually handle most dependencies myself, building the following; exiftool, exiv2 gphoto2, libraw, libYUV, OpenEXR, WebP, AOM, HEIF, & AVIF. Other dependencies I tend to get from my distos —Ubuntu— repositories, being careful to also mark the, [dependency-dev] files. I then do the build using [cmake ..], [make -j16], & [sudo make -j16 install], watching the output to see what I may have missed. After upgrading to 22.04 from 21.10, my darktable 3.8.1 stopped working, so I just finished a new build. Few errors I had to fix, (and some warnings which I ignored), but everything eventually went off smoothly. I had no issues with, “whereami”. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 29 Apr 2022 at 00:39, David Vincent-Jones wrote: > I am building a new system from scratch and have the following failure: > > Cloning into bare repository > '/var/tmp/pamac-build-david/darktable-git/whereami'... > fatal: unable to access 'https://github.com/gpakosz/whereami/': Could not > resolve host: github.com > ==> ERROR: Failure while downloading whereami git repo > Aborting... > Failed to build darktable-git > > Any ideas? > > > 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] How to add more black
Yes, mostly. Floating-point zero will map to integer zero, and floating-point one will map to integer 255 or 65,535, (8-bit, or 16-bit), all other numbers will map somewhere in between, when exported to an 8-bit or 16-bit integer image format. I say, mostly, because during the pipeline, some values may rise above one due to one module, then fall below one in another. Likewise, some values may become negative by one module, then made positive again by another. At the end of the pipeline, ideally, all values ought to be between zero and one, but that is not always true. When it is not, some algorithm will then take care of either clipping, (making all negative numbers equal to zero, and all numbers greater than one equal to one), normalising, (setting the lowest number to zero, the highest number to one, and fitting all the other numbers in-between), or some other method of remapping, then do the export to an 8-bit or 16-bit integer format. I hope I made sense. There also exists some floating-point image formats such as the de facto industry standard, OpenEXR, (*.exr), Open Raster, (*.ora), nVidia's NV format, (a.k.a., half-precision), and, to a lesser extent,Radiance HDR, (*.rgbe). There are also 16-bit & 32-bit floating-point specifications for TIFF images. Most of these image formats are not used for final images, but as intermediaries for further processing by someone else, in some other studio. These formats preserve the floating point values, and for some formats will even preserve the values which are out-of-gamut. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 26 Jan 2022 at 03:05, Terry Pinfold wrote: > I > -- > I have never understood floating point. But if I follow what has been > written here the darkest pixel is assigned a value of 0 and the > brightest pixel is assigned 1. Then all the other pixel values fall between > 0 and 1 until you export as a 8 or 16 bit image. Am I understanding this > correctly? > > > 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] How to add more black
> > >…the image seems to be just fine at the end of my pixel pipeline. > (Truth be told, I do not actually know what would happen IF I dropped the > blacks into the negative). I just did some experimentation, and I found out that some really bad stuff happens when the numbers go negative, (depending on how the image is exported), when I examine the areas outside my subjects which were clipped into negative values. As WebP, all the negative values seem to clip at zero. Any number that was not negative has a real, non-zero value. The result is that, as one approaches the darker part of the image, there is a sudden change from nearly black to pitch black. As AVIF, this phenomenon seems to disappear almost entirely in 8-bit mode, and virtually gone in 12-bit mode. As JPEG-JFIF, the issue affects more than just near-black to black, but also other hues in the shadows, making sudden jumps from, say, a dark shade of green, to perhaps a dark shade of maroon, to pitch black . This, of course, may be because the JPEG-JFIF compression algorithm favours colour accuracy in the highlights versus the shadows. Nevertheless, crushing the blacks into negative values may have undesired consequences. I may not have noticed before due to one or more of the following 1. the clipping was never on my subject, so not really noticed. 2. I mostly export to WebP 3. Our eyes see more details in the midtones/highlights, and our brains filter-out/fills-in the details of the shadows, so the phenomenon is not noticed. I must say, though, on the JPEG-JFIF, it was obvious to me. (On the others, I had to specifically study the shadows to notice). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 26 Jan 2022 at 00:45, Top Rock Photography < ka...@toprockphotography.com> wrote: > >> > Whatever the reason, so long as I do not end up clipping (crushing) my > shadows in the [exposure] module into negative values, the image seems to > be just fine at the end of my pixel pipeline. (Truth be told, I do not > actually know what would happen IF I dropped the blacks into the negative). > >> >> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] How to add more black
> The proper point to clamp black and white in scene-referred is filmic RGB.
>
Correct to some extent, in scene-referred pipeline. The “why” is important,
though, and not relevant to non-filmic pipelines.
…could eventually produce problems in other parts.
With a floating-point pixel pipeline, we do not have the general problems
which come with an integer pipeline as in Ps/Lr. They have integers which
MUST be between 0 & 255/65,535 (8-bit/16-bit). If at any point in the
pipeline, the number falls below or above those values, it clips to the
extreme value. That leads to banding in the shadows/highlights.
With floating-point, the colours are represented by 0 for blackest black,
and 1 for whitest white. If at any point, the number falls below or above
those values, they remain at whatever the value is, until another module in
the pipeline adjusts it again. At the end of the pipeline, before
exporting, there are three ways to handle ‘out-of-gamut’ values.
1. clip any value below zero or above one.
2. normalise the values to fall within the range. (The lowest value
becomes zero, the highest value becomes one, and all other values are
squeezed in.
3. I cannot recall.
The problem with the filmic module is that it uses a log function, and
there is no log defined for a negative number. Therefore, the filmic module
might crash or give incorrect interpretations for negative numbers. There
are several ways to fix that.
1. clip negative numbers before the filmic module.
2. normalise negative numbers before the filmic module.
3. replace the log function with trigonometric substitution, or
something, where negative numbers can be handled.
4. I am really not sure. I would really have to think about it.
Currently, I have tried to switch my workflow from LabCIE to FilmicRGB,
and, despite the warning, have still been sometimes adjusting my black
level with the [exposure]→[black level correction] slider. So far, the
[filmic rgb] module has not crashed out on me, nor messed up my subject.
One reason may be that, because I use the {clipping indication} to ensure
that no part of my subject goes too far beyond that 2% margin, (actually,
in 3.8, it is -12.27 EV), very few pixels, if any, (in the subject), goes
into the negative. I suppose I could use the {gamut checking} option
instead of the clipping option for a more certain outcome, but the end
result is more or less the same; no negative values to worry about.
Another reason may be that the [input colour profile] module —which has
options for handling out-of-gamut colours— comes AFTER the [exposure]
module and BEFORE the [filmic rgb] module.
A third reason could be great error-handling routines in the [filmic rgb]
module to handle the log of negative numbers.
Whatever the reason, so long as I do not end up clipping (crushing) my
shadows in the [exposure] module into negative values, the image seems to
be just fine at the end of my pixel pipeline. (Truth be told, I do not
actually know what would happen IF I dropped the blacks into the negative).
If one is NOT using [filmic rgb], —or any other module which does functions
where the result of a negative number input is NAN,— then using
the [exposure]→[black level correction] slider is not really a problem.
Sincerely,
Karim Hosein
Top Rock Photography
754.999.1652
On Tue, 25 Jan 2022 at 11:33, Guillermo Rozas wrote:
>
>
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Lua menu not showing
I almost always compile darktable on my computer, and this time was no exception. I do have all the Lua executables, and all the Lua*-dev headers installed, yet, during compiling, I got the, “Lua not found” error. This is the first time that I am getting that error message in many years, and many versions. Since I do not typically use any add-ons or macros, I was not too worried about it, but it is obviously a problem for those who do. Something is causing the compiler to not detect Lua. My system is Ubuntu 2021.10. I have both GCC 10 & 11 installed, but I think cmake/configure defaulted to version 10. I may be wrong about that. My Lua version is 5.4.3. It may be the OS, it may be the compiler, it may be compiler options. I did not make any attempt to fix the issue beyond ensuring that I did have all my Lua files installed. I suppose that I am of no help, save to let you know that you are not alone. 😉😊 Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Mon, 24 Jan 2022 at 17:14, David Vincent-Jones wrote: > I think that I went through this problem a while ago but totally forgot > how it was solved. > > After a recent update of the git version I find that the Lua menu system > has 'vanished' although it is fully installed. Can somebody provide a hint > on this .. please. > > David > > > 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] How to add more black
You can use the [exposure] module to do so, with the [black level
correction] slider. Use gingerly. I would use it with {clipping indication}
toggled on, and stop increasing when the blacks in the subject* start to
indicate clipping. I.e., that area is within 2% (by default, but
adjustable), of being clipped, or already clipped.
*What constitutes, “subject” of your image is entirely up to you.
Sincerely,
Karim Hosein
Top Rock Photography
754.999.1652
On Tue, 25 Jan 2022 at 07:58, Hieke van Hoogdalem <
hieke.vanhoogda...@gmail.com> wrote:
> Hmmm… I'm really looking for only some extra blacks.
>
>
>
>
>
> Hartelijke groet,
>
> Hieke van Hoogdalem
>
>
>
> [image: signature_1966045321]
>
>
>
> *Van: *Hieke van Hoogdalem
> *Datum: *dinsdag 25 januari 2022 om 13:44
> *Aan: *Michael Below , >
> *Onderwerp: *Re: [darktable-user] How to add more black
>
>
>
> Tnx! Will try.
>
>
>
>
>
> Hartelijke groet,
>
> Hieke van Hoogdalem
>
>
>
> [image: signature_649737511]
>
>
>
> *Van: *Michael Below
> *Datum: *dinsdag 25 januari 2022 om 13:41
> *Aan: *
> *Onderwerp: *Re: [darktable-user] How to add more black
>
>
>
> Hi,
> I would increase the black point in filmic.
> Cheers
> Michael
>
> Am 25. Januar 2022 13:05:21 MEZ schrieb Hieke van Hoogdalem <
> hieke.vanhoogda...@gmail.com>:
>
> Hi there,
>
>
>
> In the manual I couldn't find how to add more black to an image or how to
> increase the blacks a little bit. It's possible in Photoshop Elements and
> in Lightroom so I guess it should be possible here too, but I can't find
> how. I know about local contrast, but that's not what I mean.
>
>
>
> I hope you can help me out.
>
>
>
> Kind regards,
>
> Hieke van Hoogdalem
>
>
>
> [image: signature_1149525479]
>
>
>
> 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
>
>
> 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] Timestamp oddity
I think this is NOT a LInux issue (per se), and is MOSTLY a Nikon —and perhaps other manufacturers— issue, with a bit of legacy DOS for good measure. With my Linux system, everything is chris & curry. Here is my exiftool grep. ««« karim@*:~/Pictures/Pentax/K3/Weddings/CharlotteDevon/2021-10-08/K-3$ exiftool CharlotteDevon.k3p19414.2475.pef | grep 2021 File Modification Date/Time : 2021:10:08 19:16:41-04:00 File Inode Change Date/Time : 2021:10:10 15:22:52-04:00 Modify Date : 2021:10:08 19:16:37 Date/Time Original : 2021:10:08 19:16:37 Create Date : 2021:10:08 19:16:37 Date: 2021:10:08 karim@*:~/Pictures/Pentax/K3/Weddings/CharlotteDevon/2021-10-08/K-3$ exiftool CharlotteDevon.k3p19414.2475.pef | grep 2022 File Access Date/Time : 2022:01:22 00:32:16-05:00 »»» As you can see, the timezone offset is correct for when I was in EDT, (-04:00), and currently in EST, (-05:00). The only discrepancy is the 4 seconds between “Create Date, Date/Time Original, & Modify Date,” and “File Modification Date/Time.” Probably due to buffer writing, (which is WAY TOO LONG! I need a new SDCard). So, why the issues? 1. I use Pentax. Pentax stores time zones correctly, on an exFAT fs on the SDXCcards. 2. I use a 128GB SDXC card which use exFAT. (SDHC cards of 2+GB to 32GB use FAT32, while SD cards of 2GB or less use FAT12 or FAT16). 3. I use Linux. Linux can, and suggests, setting the Hardware clock, i.e., the BIOS/UEFI RTC, to UTC, and allowing the OS to set local time if it should ever change. (It may change according to DST/Standard time, or on a laptop moving through time zones, et al.). 4. My Linux has the RTC set to UTC, and the OS has local time set to EST/EDT (New York). 5. Windows®, by default, still resets the hardware clock everytime you change the time in the OS. It has to jump through many hoops, everytime there is a DST change. Two files saved an hour apart can have the same time stamp. Solutions: 1. If one is on Linux, set the RTC to UTC and let the OS handle local time changes. 2. Use an SDXC card, or, regardless of the card used, force format it to exFAT, (assuming that your camera can handle it). 3. If one dual boots into Windows®, either tell Windows that the local time is UTC, no DST, or tell Windows to not change the RTC. (Up to Windows 10, this cannot be done in the control panel. It requires registry changes. I know not about Widows 11). 4. Use a camera which saves time zone data. As I was typing this, it has occured to me that several “experts” on the web have been insisting to people to only use 32GB or smaller storage cards, forcing one to change cards in the middle of a shoot, so that if a card should fail, (as they ALL eventually do), one does not lose ALL the work they shot that day. Rubbish, if you ask me. I just use two cards at all times, and with 128GB, I NEVER have to change cards in the middle of a shoot. (I understand that some cameras only have one card slot, or cannot use cards over 32GB). IF one's card is 32GB or less, it will not store time zone data, and that may cause problems. If one does not have local time being kept correctly by the OS, that may cause problems. If one's camera does not save local time correctly, that may cause problems. The more I think about it, it may come down to FAT32 vs exFAT. Can the three people who demonstrated issues in this thread retry with media which they are certain are using exFAT, (i.e., 32+GB or more)? Sincerely, Karim Hosein Top Rock Photography > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] windows : darktable 3.4.1.1 ready
I think I got my answer. …we are preparing an hot-fix release for Windows only which will be tagged > as 3.4.1.1. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 10 Feb 2021 at 13:28, Top Rock Photography < ka...@toprockphotography.com> wrote: > I presume that this update is only relevant to Windows users, and that > Linux/Mac users with version 3.4.1 are binary equivalent to the new 3.4.1.1 > update. That is to say, that the darktable-3.4.1.1.tar.xz will compile > the same as darktable-3.4.1.tar.xz on Linux. > Am I correct? I do not want to have to re-compile again if I do not have > to do so 😉. > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] windows : darktable 3.4.1.1 ready
I presume that this update is only relevant to Windows users, and that Linux/Mac users with version 3.4.1 are binary equivalent to the new 3.4.1.1 update. That is to say, that the darktable-3.4.1.1.tar.xz will compile the same as darktable-3.4.1.tar.xz on Linux. Am I correct? I do not want to have to re-compile again if I do not have to do so 😉. …Well, at least not until after 2021-03-31 when Exiv2 version 0.27.4 RC1 is merged. 😁 Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 9 Feb 2021 at 07:20, Pascal Obry wrote: > > Ok, I didn't expected to have the new Windows binary so fast, but here > it is. > So if you are on Windows please make sure you download the new > installer named: darktable-3.4.1.1-win64.exe > > Here: > https://github.com/darktable-org/darktable/releases/tag/release-3.4.1 > > Regards, > > -- > 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] exiv2, darktable, AVIF, metadata, and ExifTool
Thank you for that information. Really appreciate it. GREAT NEWS! Looks like a possible 21st May release date for 0.27.4, but a 31st March date for RC1 to be integrated with darktable. Looking forward to it. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 9 Feb 2021 at 09:01, Milos Komarcevic wrote: > Hi again Karim, > > I also noticed from the thread there is some confusion about upcoming > exiv2 release plan. > > AFAIK, the upcoming 0.27.4 should support AVIF (and other ISO BMFF based > containers) later this spring: > > https://github.com/Exiv2/exiv2/milestone/6 > > 0.28 won't happen for quite some time... > > BR, > Milos > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2, darktable, AVIF, metadata, and ExifTool
Okay, so here is how QT/KDE works… to some extent. Image support is on a system-wide basis, not per application. To get AVIF support, I had to update ECM & Cmake, then install the qt5-avif-plugin. (This means compile all three). Well that did not work, so I compiled (again) Gwenview. Still did not work. [ASIDE] Ubuntu LTS can be a pain to have sometimes. By the time I am done with all my compiles, it will no longer be ubuntu! 😉😀😁 [/ASIDE] It turns out that the install script for the qt5 plugin did not put things in the places where they are supposed to be. So, I had to copy them manually to the correct locations. Voila!!! Gwenview works! …sorta kinda. No EXIF data since gwenview uses EXIV2 and not ExifTool. Exiv2 version 0.27.3 (and, if I understand correctly, version 0.28.0, when it comes out) does not have support for AVIF metadata. [ASIDE] I remember not so long ago, having to compile exiv2 version 0.27.x just so that I can see metadata in WebP files on my Ubuntu 18.04 LTS. [/ASIDE] Using ExifTool, I can see my EXIF and XMP metadata. (The XMP metadata, I had to copy into it from a JPEG JFIF file, using ExifTool). Thanks to Milos Komarcevic for pointing out that the only reason I have EXIF data in the AVIF files in the first place is because libavif handles the writing of the metadata to begin with, so Exiv2 is not involved. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 5 Feb 2021 at 15:26, Top Rock Photography < ka...@toprockphotography.com> wrote: > Thank you, Patrick. > > That made me investigate. There exists an AVIF plugin for QT5. This plugin > requires ECM version 5.70.0 or greater. Ubuntu LTS (20.04) has version > 5.68.0. > > So two more compiles to try; first, ECM (Extra CMake Modules) version > 5.70.0 (or higher), then the qt5 AVIF plugin. Then Gwenview may work…. > > …Except that I may also have to bring KF5 (and all its parts) up to > version 5.70.0 (or higher), also. Currently they are at versions 5.68.0. > > I will let you know how that works out. > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > > > On Fri, 5 Feb 2021 at 13:56, Patrick Shanahan wrote: > >> * Top Rock Photography [02-05-21 13:09]: >> > Okay, I compiled gwenview 20.12.2, and, during compilation, it seems >> that >> > it uses exiv2, and only recognises FITS, JPEG (JFIF/SPIFF ???), PNG, >> > SVG,TIFF, & WebP. No indication of AVIF support. >> > >> > Installed, and found no AVIF support. (& if it did, would not recognise >> the >> > metadata). >> > >> > Will try with Geeqie per Šarūnas Burdulis. >> > >> > Sincerely, >> > >> > Karim Hosein >> > Top Rock Photography >> > 754.999.1652 >> > >> > >> > >> > On Thu, 4 Feb 2021 at 20:24, Patrick Shanahan >> wrote: >> > >> > > * Top Rock Photography [02-04-21 >> 19:44]: >> > > > Ah! Another compile for me. Ubuntu 20.04 LTS has Gwenview 19.12.3, >> and it >> > > > does not recognise AVIF files. I see that version 20.12.2 is out. I >> have >> > > > just downloaded it, and will try to compile it tomorrow. >> > > > >> > > > Thanks. >> > > > >> > > > P.s., does it use Exiv2 or ExifTool for metadata? I do have the >> latest >> > > > ExivTool with AVIF support. ;-) >> > > > >> > > > Sincerely, >> > > > >> > > > Karim Hosein >> > > > Top Rock Photography >> > > > 754.999.1652 >> > > > >> > > > >> > > > >> > > > On Thu, 4 Feb 2021 at 17:18, Patrick Shanahan >> wrote: >> > > > >> > > > > >> > > > > >> > > > > gwenview displays avif files but not exif data. >> > > > > >> > > > > >> > > > >> > > >> > > appears libexiv2.so.27 (on openSUSE Tumbleweed). >> > > >> > > >> > > -- >> > > (paka)Patrick Shanahan Plainfield, Indiana, USA >> @ptilopteri >> > > http://en.opensuse.orgopenSUSE Community Member >> facebook/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 >> > > >> > > >> > >> > >> >> > darktable user mailing list >> > to unsubscribe send a mail to >> darktable-user+unsubscr...@lists.darktable.org >> > >> >> >> works fine on openSUSE Tumbleweed! >> -- >> (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri >> http://en.opensuse.orgopenSUSE Community Member >> facebook/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 >> >> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2, darktable, AVIF, metadata, and ExifTool
Thank you, Patrick. That made me investigate. There exists an AVIF plugin for QT5. This plugin requires ECM version 5.70.0 or greater. Ubuntu LTS (20.04) has version 5.68.0. So two more compiles to try; first, ECM (Extra CMake Modules) version 5.70.0 (or higher), then the qt5 AVIF plugin. Then Gwenview may work…. …Except that I may also have to bring KF5 (and all its parts) up to version 5.70.0 (or higher), also. Currently they are at versions 5.68.0. I will let you know how that works out. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 5 Feb 2021 at 13:56, Patrick Shanahan wrote: > * Top Rock Photography [02-05-21 13:09]: > > Okay, I compiled gwenview 20.12.2, and, during compilation, it seems that > > it uses exiv2, and only recognises FITS, JPEG (JFIF/SPIFF ???), PNG, > > SVG,TIFF, & WebP. No indication of AVIF support. > > > > Installed, and found no AVIF support. (& if it did, would not recognise > the > > metadata). > > > > Will try with Geeqie per Šarūnas Burdulis. > > > > Sincerely, > > > > Karim Hosein > > Top Rock Photography > > 754.999.1652 > > > > > > > > On Thu, 4 Feb 2021 at 20:24, Patrick Shanahan wrote: > > > > > * Top Rock Photography [02-04-21 > 19:44]: > > > > Ah! Another compile for me. Ubuntu 20.04 LTS has Gwenview 19.12.3, > and it > > > > does not recognise AVIF files. I see that version 20.12.2 is out. I > have > > > > just downloaded it, and will try to compile it tomorrow. > > > > > > > > Thanks. > > > > > > > > P.s., does it use Exiv2 or ExifTool for metadata? I do have the > latest > > > > ExivTool with AVIF support. ;-) > > > > > > > > Sincerely, > > > > > > > > Karim Hosein > > > > Top Rock Photography > > > > 754.999.1652 > > > > > > > > > > > > > > > > On Thu, 4 Feb 2021 at 17:18, Patrick Shanahan > wrote: > > > > > > > > > > > > > > > > > > > gwenview displays avif files but not exif data. > > > > > > > > > > > > > > > > > > > > appears libexiv2.so.27 (on openSUSE Tumbleweed). > > > > > > > > > -- > > > (paka)Patrick Shanahan Plainfield, Indiana, USA > @ptilopteri > > > http://en.opensuse.orgopenSUSE Community Member > facebook/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 > > > > > > > > > > > > > darktable user mailing list > > to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > > > > > works fine on openSUSE Tumbleweed! > -- > (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 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2, darktable, AVIF, metadata, and ExifTool
According to the Geeqie website, they only support… 3FR, ANI, APM, ARW, BMP, CR2, CRW, CUR, DNG, ERF, GIF, ICNS, ICO, JPE/JPEG/JPG, JPS, KDC, MEF, MPO, MOS, MRW, NEF, ORF, PEF, PTX, PBM/PGM/PNM/PPM, PNG, QIF/QTIF (QuickTime Image Format), RAF, RAW, RW2, SR2, SRF, SVG/SVGZ, TGA/TARGA, TIF/TIFF, WMF, XBM, XPM I think that I remember from before, that they did not support WebP. Currently, unless otherwise requested, my final images are in WebP format. Hence, Geeqie is not an option for me. In the future, my workflow may possibly end with AVIF files. That is why I am eager for things to advance in that direction. It may not happen, and that is just fine, but considering the huge collab which exists within AOM, it may be inevitable. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 4 Feb 2021 at 16:29, Šarūnas wrote: > On 2/4/21 4:13 PM, Top Rock Photography wrote: > > ... > > So, thank you, darktable developers, for giving me my EXIF data in my > > AVIF (and, of course, WebP) files. Now if I can only find a viewer > > —other than Chrome, Chromium, & Firefox— which can view an AVIF, and > > also, which can display its metadata. ;-) > Geeqie? > > -- > Šarūnas Burdulis > math.dartmouth.edu/~sarunas > > · https://useplaintext.email · > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2, darktable, AVIF, metadata, and ExifTool
Okay, I compiled gwenview 20.12.2, and, during compilation, it seems that it uses exiv2, and only recognises FITS, JPEG (JFIF/SPIFF ???), PNG, SVG,TIFF, & WebP. No indication of AVIF support. Installed, and found no AVIF support. (& if it did, would not recognise the metadata). Will try with Geeqie per Šarūnas Burdulis. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 4 Feb 2021 at 20:24, Patrick Shanahan wrote: > * Top Rock Photography [02-04-21 19:44]: > > Ah! Another compile for me. Ubuntu 20.04 LTS has Gwenview 19.12.3, and it > > does not recognise AVIF files. I see that version 20.12.2 is out. I have > > just downloaded it, and will try to compile it tomorrow. > > > > Thanks. > > > > P.s., does it use Exiv2 or ExifTool for metadata? I do have the latest > > ExivTool with AVIF support. ;-) > > > > Sincerely, > > > > Karim Hosein > > Top Rock Photography > > 754.999.1652 > > > > > > > > On Thu, 4 Feb 2021 at 17:18, Patrick Shanahan wrote: > > > > > > > > > > > gwenview displays avif files but not exif data. > > > > > > > > > > appears libexiv2.so.27 (on openSUSE Tumbleweed). > > > -- > (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 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2, darktable, AVIF, metadata, and ExifTool
Ah! Another compile for me. Ubuntu 20.04 LTS has Gwenview 19.12.3, and it does not recognise AVIF files. I see that version 20.12.2 is out. I have just downloaded it, and will try to compile it tomorrow. Thanks. P.s., does it use Exiv2 or ExifTool for metadata? I do have the latest ExivTool with AVIF support. ;-) Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 4 Feb 2021 at 17:18, Patrick Shanahan wrote: > > > gwenview displays avif files but not exif data. > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2, darktable, AVIF, metadata, and ExifTool
On trying to get metadata into my AVIF files, I discovered a few things…. The AVIF files which darktable version 3.4.0 (compiled from source on Ubuntu 20.04 LTS) produces do have EXIF metadata. They do not appear to have IPTC —I may be wrong on that— nor XMP metadata. (Indeed, the WebP files which darktable produces also seem to lack IPTC/XMP metadata, although they do have EXIF metadata). Exiv2 vesion 0.27.3 cannot read nor write metadata to nor from an AVIF file —which makes me wonder how the metadata got into the AVIF files which darktable writes. Exiftool version 11.86, (library version 11.88, WTDickens?!?), does read, write, and copy metadata in/out of AVIF files, including, apparently, IPTC, and XMP metadata, (although I did not actually check on IPTC data yet, it does copy XMP data for certain). I mention this because I had previously suggested that ExifTool does not r/w/c metadata to/from AVIF files. So, thank you, darktable developers, for giving me my EXIF data in my AVIF (and, of course, WebP) files. Now if I can only find a viewer —other than Chrome, Chromium, & Firefox— which can view an AVIF, and also, which can display its metadata. ;-) Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 29 Jan 2021 at 14:10, Top Rock Photography < ka...@toprockphotography.com> wrote: > My only concern is that, although AVIF is not patent encumbered, he > refused to add the reading/writing of metadata data to AVIF, until he > speaks to a lawyer. That has been quite a long time ago and so, my AVIF > files made by darktable seem to have no metadata. > … > > Currently, Exiftool is no better (in that regard). Worse yet, aside from > the most popular browsers, (Firefox, Chrome/Chromium), I cannot find a > viewer for AVIF files. > > I have other issues on AVIF support, but this is not the thread for that. > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > > > >> >> a: How will this affect DT? >> b: Supplementary question: Would exiftool be an alternative for DT? >> >> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2 and darktable
Forking does not contribute to the project. It contributes to a new project, which darktable may not necessarily adopt. Then I have to also fork darktable, which means that I have now solved my problem, and my problem only, until my fork of exiv2 is merged back into the original project, which is guaranteed not to happen if the lawyers do not get back to the project leaders. I was actually told that someone already forked EXIV2 0.27 to include AVIF, but that fork will not be merged in EXIV2 0.28, which Mills is currently working on, —his last involvement before someone else takes control of the project,— and as far as I can tell, is a one man effort. I have to trust that one man, to trust that one fork. [ASIDE] Also, I understand that his fork uses dav1d, and not aomd, which is what I use, and that may just mean a little more work for me. Not that it is a big deal; currently I compile my own exiv2, aom, avid, gthumb, gphoto, and darktable anyway, so as to get full WebP support and partial AVIF support, but dav1d requires a different set of compile tools, which , again, not a big deal. [/ASIDE] So, forking the project helps me, and me only, (for now), not the project, or others who use it. As I said, my biggest problems are lawyers failing to communicate. Had they done that, better programmers than I would have had AVIf support in exiv2 long ago, as more capable programmers were already willing to do the work. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 29 Jan 2021 at 21:20, Patrick Shanahan wrote: > * Top Rock Photography [01-29-21 21:14]: > > My only demand is that the lawyer gets on the phone and speak to the AOM > > people. It has been almost one year! IANAL…. > > > > …But I have read the AOM license,, and I have studied the case of Nokia > vs > > the other members of AOM, and HEIF. In that case, all the other lawyers > > claim that a) Nokia never held a patent on the parts of HEIF used in > > AV1/AVIF, and, whatever patent they claim to have would have already > > expired. > > > > That leaves all remaining patents within the powers of AOM and their > > licensing. > > > > The issue was not coding, but waiting to hear from the lawyer…. for > almost > > a year. Robin Mills was willing to work on the code at one point, but > > several people kept claiming that, despite the publicly available > license, > > and the work done by clothes, (including Exiftool), that Mills cannot put > > any code which reads the metadata (forget about even writing it), into > > exiv2. It ended with him running out of time, because no lawyer got back > to > > give the go-ahead, (or to affirm that it could not be done). Ergo, it > will > > not be done for exiv2 version 0.28. > > > > Well, that is what the closed, feature request thread says. (It does not > > say, “about a year,” but it has been over a year since the > thread/response > > was started, and mills giving his stance on 0.28 was almost a year ago). > > > > Sincerely, > > > > Karim Hosein > > Top Rock Photography > > 754.999.1652 > > > > > > > > On Fri, 29 Jan 2021 at 17:19, Martin Straeten > > > wrote: > > > > > Why don’t you take over the responsibility for the project? And be > fully > > > accountable for a possible copyright or patent infringement? > > > It is presumptuous to demand something from others that you are not > > > willing to contribute yourself. > > > > > > Am 29.01.2021 um 20:11 schrieb Top Rock Photography < > > > ka...@toprockphotography.com>: > > > > > > > > > My only concern is that, although AVIF is not patent encumbered, he > > > refused to add the reading/writing of metadata data to AVIF, until he > > > speaks to a lawyer. That has been quite a long time ago and so, my AVIF > > > files made by darktable seem to have no metadata. > > > > > > Currently, Exiftool is no better (in that regard). Worse yet, aside > from > > > the most popular browsers, (Firefox, Chrome/Chromium), I cannot find a > > > viewer for AVIF files. > > > > > > Does one really need a lawyer to work for over one year to decide that > the > > > reading/writing of metadata in an AVIF does NOT violate any patents not > > > covered by the open license? Is his lawyer billing him at US$20,000 > per day? > > > > > > I am confident that the exiv2 project will be taken over. I just hope > that > > > whoever takes it over has a lawyer who knows how to make phone calls > and/or > > > write letters. > > > > > > I have other issues on AVIF support, but
Re: [darktable-user] exiv2 and darktable
My only demand is that the lawyer gets on the phone and speak to the AOM people. It has been almost one year! IANAL…. …But I have read the AOM license,, and I have studied the case of Nokia vs the other members of AOM, and HEIF. In that case, all the other lawyers claim that a) Nokia never held a patent on the parts of HEIF used in AV1/AVIF, and, whatever patent they claim to have would have already expired. That leaves all remaining patents within the powers of AOM and their licensing. The issue was not coding, but waiting to hear from the lawyer…. for almost a year. Robin Mills was willing to work on the code at one point, but several people kept claiming that, despite the publicly available license, and the work done by clothes, (including Exiftool), that Mills cannot put any code which reads the metadata (forget about even writing it), into exiv2. It ended with him running out of time, because no lawyer got back to give the go-ahead, (or to affirm that it could not be done). Ergo, it will not be done for exiv2 version 0.28. Well, that is what the closed, feature request thread says. (It does not say, “about a year,” but it has been over a year since the thread/response was started, and mills giving his stance on 0.28 was almost a year ago). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 29 Jan 2021 at 17:19, Martin Straeten wrote: > Why don’t you take over the responsibility for the project? And be fully > accountable for a possible copyright or patent infringement? > It is presumptuous to demand something from others that you are not > willing to contribute yourself. > > Am 29.01.2021 um 20:11 schrieb Top Rock Photography < > ka...@toprockphotography.com>: > > > My only concern is that, although AVIF is not patent encumbered, he > refused to add the reading/writing of metadata data to AVIF, until he > speaks to a lawyer. That has been quite a long time ago and so, my AVIF > files made by darktable seem to have no metadata. > > Currently, Exiftool is no better (in that regard). Worse yet, aside from > the most popular browsers, (Firefox, Chrome/Chromium), I cannot find a > viewer for AVIF files. > > Does one really need a lawyer to work for over one year to decide that the > reading/writing of metadata in an AVIF does NOT violate any patents not > covered by the open license? Is his lawyer billing him at US$20,000 per day? > > I am confident that the exiv2 project will be taken over. I just hope that > whoever takes it over has a lawyer who knows how to make phone calls and/or > write letters. > > I have other issues on AVIF support, but this is not the thread for that. > > >> > > 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] Usage and modifying description/title metadata fields
Several tools in ubuntu —GNU/Linux in general— use those fields, but they may not show by default. Also, as Patrick said, (piwigo ….and most other) web albums can and do use those fields. Again, maybe not showing them by default. When doing a workshop, using the style option in the export module to put relevant data on the image (by way of the watermark module, and possibly the frame module), is quite useful. I do find however that, for most clients, they do not care much about metadata as I do. One thing I do notice is that tools which use Exiftool may not treat certain metadata the same as some tools which use Exiv2. That is to say, all tools can show the relevant data when asked to show all data, but when asked to show a brief summary, may consider “Description” to be important, while “Comment” is not, and the other vice versa. Ergo, I fill in as much metadata as possible. When it comes to photojournalism and stock photography, I strongly suggest that one fills in as much IPTC data as possible, (in addition to the usual EXIF/XMP data). Many stock photography sites and news organisations look there first. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Mon, 18 Jan 2021 at 10:41, Niranjan Rao wrote: > I exported a image with description and title. None of the tools on > Ubuntu showed it me though exiftool showed it to me. I was thinking > there is some other use for these fields. > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] exiv2 and darktable
My only concern is that, although AVIF is not patent encumbered, he refused to add the reading/writing of metadata data to AVIF, until he speaks to a lawyer. That has been quite a long time ago and so, my AVIF files made by darktable seem to have no metadata. Currently, Exiftool is no better (in that regard). Worse yet, aside from the most popular browsers, (Firefox, Chrome/Chromium), I cannot find a viewer for AVIF files. Does one really need a lawyer to work for over one year to decide that the reading/writing of metadata in an AVIF does NOT violate any patents not covered by the open license? Is his lawyer billing him at US$20,000 per day? I am confident that the exiv2 project will be taken over. I just hope that whoever takes it over has a lawyer who knows how to make phone calls and/or write letters. I have other issues on AVIF support, but this is not the thread for that. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 > > a: How will this affect DT? > b: Supplementary question: Would exiftool be an alternative for DT? > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Re: GPU vs OSL vs pure CPU
ARCHHH!!! Wrong mailing list Sorry guys. My bad. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Mon, 11 Jan 2021 at 16:20, Top Rock Photography < ka...@toprockphotography.com> wrote: > To add a little detail, turning on OSL (on the new system) made my rendes > about 10% slower. > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > > > On Mon, 11 Jan 2021 at 16:08, Top Rock Photography < > ka...@toprockphotography.com> wrote: > >> My old setup: >> AMD Phenom II X6 1055T at 2400 MHz, 32 GiB DDR3 RAM at 1200 MHz, (1600MHz >> when SPD works), nVidia GTX 760. Nothing overclocked. GPU render was about >> 3× faster than CPU (with or without Open Shading Language, which did not >> always work). Nothing over clocked. The GPU is a PCIe 3.0, but the MB is a >> PCIe 2.0. >> >> New setup: >> AMD Ryzen 7 3800X, 32 GiB DDR4 RAM at 3200 MHz (with SPD, normally 2400), >> same GPU, but now in a PCIe 4.0 MB. Nothing overclocked. (Yes, I replaced >> my ten year old MB and CPU, thus had to also get new RAM). >> >> All else equal. —OS on SATA III SSD, data on 4× HDD RAID5, SATA III, OS >> (Ubuntu 20.04 LTS) et al. No surprise, CPU render is now faster than GPU >> render. In fact, it is about 3× faster. What I found surprising is that >> GPU+CPU render is slower than plain old CPU, and plain old CPU is faster >> than CPU with OSL. >> >> I thought that a car being pushed by four strong guys will go slower than >> a car being pushed by four strong guys and one weakling, thus, adding the >> slower GPU would still speed up the render. Apparently not. I also recall >> on my old system, that GPU+CPU was also slower than just plain GPU. In >> other words, the slower guy slows down the faster guy, either way. >> >> I do not think it was supposed to work that way. >> >> Second, I thought that OSL accelerated surface/volume scattering when >> doing physics-based rendering, (my normal MO). I cannot ever remember >> actually timing it on the old system, but I do remember getting the >> perception of it taking longer whenever OSL crashed Blender. Very >> non-scientific. >> >> Does using OSL slow us down as a trade-off for better render. or does it >> accelerate the system?. Should GPU+CPU be faster than just one or the other? >> >> Old system was Blender 2.90.1, compiled from source. New system is >> Blender 2.91.0, also compiled from source. (I also re-compiled some of the >> dependencies after the upgrade to ensure any new available compile options >> are used to optimize for the new platform). >> >> Sincerely, >> >> Karim Hosein >> Top Rock Photography >> 754.999.1652 >> >> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Re: GPU vs OSL vs pure CPU
To add a little detail, turning on OSL (on the new system) made my rendes about 10% slower. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Mon, 11 Jan 2021 at 16:08, Top Rock Photography < ka...@toprockphotography.com> wrote: > My old setup: > AMD Phenom II X6 1055T at 2400 MHz, 32 GiB DDR3 RAM at 1200 MHz, (1600MHz > when SPD works), nVidia GTX 760. Nothing overclocked. GPU render was about > 3× faster than CPU (with or without Open Shading Language, which did not > always work). Nothing over clocked. The GPU is a PCIe 3.0, but the MB is a > PCIe 2.0. > > New setup: > AMD Ryzen 7 3800X, 32 GiB DDR4 RAM at 3200 MHz (with SPD, normally 2400), > same GPU, but now in a PCIe 4.0 MB. Nothing overclocked. (Yes, I replaced > my ten year old MB and CPU, thus had to also get new RAM). > > All else equal. —OS on SATA III SSD, data on 4× HDD RAID5, SATA III, OS > (Ubuntu 20.04 LTS) et al. No surprise, CPU render is now faster than GPU > render. In fact, it is about 3× faster. What I found surprising is that > GPU+CPU render is slower than plain old CPU, and plain old CPU is faster > than CPU with OSL. > > I thought that a car being pushed by four strong guys will go slower than > a car being pushed by four strong guys and one weakling, thus, adding the > slower GPU would still speed up the render. Apparently not. I also recall > on my old system, that GPU+CPU was also slower than just plain GPU. In > other words, the slower guy slows down the faster guy, either way. > > I do not think it was supposed to work that way. > > Second, I thought that OSL accelerated surface/volume scattering when > doing physics-based rendering, (my normal MO). I cannot ever remember > actually timing it on the old system, but I do remember getting the > perception of it taking longer whenever OSL crashed Blender. Very > non-scientific. > > Does using OSL slow us down as a trade-off for better render. or does it > accelerate the system?. Should GPU+CPU be faster than just one or the other? > > Old system was Blender 2.90.1, compiled from source. New system is Blender > 2.91.0, also compiled from source. (I also re-compiled some of the > dependencies after the upgrade to ensure any new available compile options > are used to optimize for the new platform). > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] GPU vs OSL vs pure CPU
My old setup: AMD Phenom II X6 1055T at 2400 MHz, 32 GiB DDR3 RAM at 1200 MHz, (1600MHz when SPD works), nVidia GTX 760. Nothing overclocked. GPU render was about 3× faster than CPU (with or without Open Shading Language, which did not always work). Nothing over clocked. The GPU is a PCIe 3.0, but the MB is a PCIe 2.0. New setup: AMD Ryzen 7 3800X, 32 GiB DDR4 RAM at 3200 MHz (with SPD, normally 2400), same GPU, but now in a PCIe 4.0 MB. Nothing overclocked. (Yes, I replaced my ten year old MB and CPU, thus had to also get new RAM). All else equal. —OS on SATA III SSD, data on 4× HDD RAID5, SATA III, OS (Ubuntu 20.04 LTS) et al. No surprise, CPU render is now faster than GPU render. In fact, it is about 3× faster. What I found surprising is that GPU+CPU render is slower than plain old CPU, and plain old CPU is faster than CPU with OSL. I thought that a car being pushed by four strong guys will go slower than a car being pushed by four strong guys and one weakling, thus, adding the slower GPU would still speed up the render. Apparently not. I also recall on my old system, that GPU+CPU was also slower than just plain GPU. In other words, the slower guy slows down the faster guy, either way. I do not think it was supposed to work that way. Second, I thought that OSL accelerated surface/volume scattering when doing physics-based rendering, (my normal MO). I cannot ever remember actually timing it on the old system, but I do remember getting the perception of it taking longer whenever OSL crashed Blender. Very non-scientific. Does using OSL slow us down as a trade-off for better render. or does it accelerate the system?. Should GPU+CPU be faster than just one or the other? Old system was Blender 2.90.1, compiled from source. New system is Blender 2.91.0, also compiled from source. (I also re-compiled some of the dependencies after the upgrade to ensure any new available compile options are used to optimize for the new platform). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] DT 3.4 no longer has zone system module (gone!)
FUN with The Zone System I have been intrigued with the zone system since the summer of 1980. By the time I got into my first darkroom in 1981, sheet film had been replaced as the de facto by 35 mm roll film (after 120 roll film, of course). Doing the zone system became harder. Then I was introduced to Ilford Multigrade paper, and, with a great deal of pre-planning, the zone system became a little easier. With digital photography, it became that much easier, as once again, photographs can be treated differently on a frame by frame basis, instead of a roll by roll basis. The zone system and swing/tilt-shift/lift lens standard were the only two things drawing me towards view cameras, and now, with high resolution digital cameras and the digital darkroom, (such as darktable), I no longer need a view camera for either one. (Well, a swing/tilt-shift/lift lens standard would still be awesome!!!) One of the first things I had noticed, and was eager to try, when I first looked at darktable as an alternative to RawTherapee, was the zone system module. I tried using it to get the results I wanted, and found that it was much easier to use curves, or something else to achieve the goal. With the filmic RGB module, I find it so much easier (and more precise) than the zone system module ever was. If one understands precisely what the zone system is all about, then using the filmic module to achieve the goal is so much easier than attempting it any other way. The idea is to pick the greatest highlights and deepest shadows in which one desires to capture details, then expose and develop for it accordingly. This means from a practical DSC pov, expose the sensor such that the* highlights on the subject *in which one wants to retain detail is not near clipping, (so as to capture as much detail in the shadows, without losing details in the highlights, a.k.a., *expose the subject* to the right, or ETTR), then use the filmic module (ar any other appropriate module) to adjust the subjects highlights and shadows accordingly. The dynamic range scaling feature is absolutely a marvel with this. [ASIDE] For negative film, the zone system can be summarised as —and this is a huge oversimplification— expose for the shadow (get enough light so as to capture detail, or in other words, get enough density on the negative), and develop for the highlights (do not get too much density in the highlights), a.k.a., still expose to the right. This may mean over exposing and under developing, —pulling the film— when the shadows are too dark, or under exposing and over developing —pushing the film— when the shadows are too bright. Nothing has really changed with digital photography. [/ASIDE] Whereas the zone system module made it easier to indicate what parts of the *subject *fell into what zones, it did not add any value outside of such visualisation, (IMNSHO). The same can be achieved by using the clipping indicator, by setting the threshold values accordingly, and *observing the subject*. Not only so, but the tooltip of the new clipping indicator helps one make the adjustment based on the intended medium, including print. (It was sometimes a pain to get an image just right, then, after sending to the printers, realised that it had to be adjusted majorly). I recommend that those interested in the zone system first understand what the zote system was attempting to achieve, then learn how one can achieve the same results in the filmic module. Linear RGB is basically the zone system on steroids! (IMNSHO). That is my 2¢. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] dt 3.4 - a mighty tool!!
«Have a plan and keep and log. take a scientific, methodological approach. Logging failures and mistakes is important too.» This! When I taught photography, I had to keep insisting to everyone the importance of putting everything down in the darkroom logbook, even the failures. Nay! Especially the failures. Also, the importance of detailed logs. Saying, “Sunday → Did normal exposure/development. Results were good, Jimmy Jim” was not at all helpful. A better entry would have been, “1994-04-17, 17:30 EST → Based on enlarger light-meter and test sheet, exposed my FP4, (‘Castleton Gardens,’ Roll 2, frame 23A, ‘Gladiolia by the Cascades’ with proper exposure), on Hasselblad 23C enlarger at 45 cm (18 inches) with the 50 mm lens at f/11 on 12×8 in Ilford Ilfospeed RC Deluxe Glossy grade 3 paper on the 11×14 adjustable easel, for ten seconds. Developed in 1 litre fresh Ilford multigrade developer, 1:14 dilution, at 24°C for 3 min. Results: Exposure came out perfect, and the tone was quite neutral. Blacks properly saturated, and no fogging in the highlights. Went on to make eleven more prints of this frame, (12 total), then one print each of frames 4A, 6A, 12A, 17A, 21A, 29A, and 33A, with the same settings. All results as the first. Not happy with contrast of 33A, ‘Babling Brook.’ Will retry another day with higher contrast paper. Used developer stored, labeled and documented, (20 12×8 in prints, including initial test sheet) in the refrigerator. Fixer was used, and previous logs, plus bottle documentation, indicated it was near exhaustion. Tested, and was adequate, but recommend a fresh batch. Left note for DR manager, and on fixer bottle. James ‘Jimmy Jim’ Matthersen.” In our case, it was extremely vital, as it was a shared darkroom, but it was also a huge time saver when one comes back in four days to retry frame 33A on higher grade paper. It makes reproducing results far easier, especially when one gets several more requests for prints of “Gladiolai by the Cascades,” Having a plan before entering the darkroom is also a huge time-saver. None of this changes for the digital workflow, save that a great deal of the logging is done automatically. One still has to enter their own comments on the results, (and not have to worry about other users, or chemicals being exhausted). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 30 Dec 2020 at 10:26, Anton Aylward wrote: > > On 29/12/2020 10:16, Dr. A. Krebs wrote: > > > > > > dt seems to require quite a bit studies to find out the appropriate > steps to image > > processing. As we can see, there are people searching for a > beginners-type GUI. > > > > For me some type of such "beginners workflow" helped a lot; however, > there should > > be a physical / arithmetical backup for such workflows. > > Yes that makes more sense than a beginners-type GUI. > No matter the GUI, it is the ability to use it that really matters. > > > > Overall, there might be some type of knowledge-system in the background > to analyse > > a selected pic. From there he system could offer a questionnaire to > concrete the > > targets and, at last, suggest some reasonable steps to improve a pic. > > HO! What you are asking for is a AI like scene recognition and > classification. > Yes they exist, online. Many exist. Some do things like 'sharpening' and > colour > balancing and correcting skin colour. But they require more resources > than you > have on your PC or laptop. > > However yu DO have a tool that can do scene recognition etc etc and do the > correction the way you want not according to some algorithms in the AI > determines > by a means even the original programmer wouldn't know. > > It's called 'natural intelligence'. > It's called taking the time to learn tool. > > If the idea proposed by some pundits that it will take 10,000 hours of > practice to > fully master that craft puts you off, well the answer isn't "suck it up!'. > It's much simpler than that. It's like using a vacuum cleaner. You keep > pushing > forward in the direction you care about bit by but, 'sucking up' little by > little > as you go along. You don't need to master it all. What you do need to > master you > don't need to master all in one go. > > > Any image is unique, and if you are anything like me, any film roll with > have a > number of different types & style of image. > > Dealing with every possible image in the way you ask is too much for this > list. > It gets back to the AI situation. > > > All of the above ignores the fact that anything you do is not set in stone. > You can always re-edit the same image at a later date as your knowledge > grows. > Even in o
Re: [darktable-user] Exporting to AVIF format
I was using libavif-0.8.1 on Ubuntu 20.04 with Darktable 3.2.1, and no success. When I attempt to export as AV1F, it seems to be working, but then fails at what seems to be the very end. This lends credence to what Remco said, that it is failing during the writing of the metadata, and that the problem may lie with EXIV2. I really never bothered to troubleshoot it. I just thought I would wait until libavif improved. I suppose I was waiting for the wrong thing to improve. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: Fwd: Fwd: [darktable-user] Linux question
Yeah, I cannot make time to find anything either. It is easier to just consider it lost and order a new one from Amazon. ;-) Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 24 Nov 2020 at 19:29, Michael wrote: > yeah I am just a simple guy... that is too complicated for me! > Let's see find -maketime ? type file -deletefile > > see, too complicated! > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Database Problem
It seems to me that it may be sorting by ‘last access’ or ‘last modified’ date, instead of ‘created’ date, or ‘EXIF → taken’ date. Since you are using a development build, you ought to report this to the developers, (after confirming that that is what is actually happening). This is the [Darktable-User] list, not developers list, (and I am not sure which method is recommended to report development bugs, but GIt will tell you). Bernhard, are you also on a development build, or master branch? I am using 3.2.1 master build on Ubuntu 20.04 (compiled myself) and not having this issue at all. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 15 Oct 2020 at 15:25, ternaryd wrote: > On Thu, 15 Oct 2020 12:11:34 -0700 > David Vincent-Jones wrote: > > > OK ... glad to hear that it is not just on my > > system. > > Just noticed, there is a quick and easy way to > test: Use ''create HDR'', which certainly will > be a file created after the source images, but > the DNG is ordered just before them. > > > 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] Question regarding SVG files and why they work differently
One can also embed the font into the SVG. This makes the SVG larger, but it also ensures that the font goes with it, wherever it goes. One can choose to embed only the glyphs used, or the entire font, (or even an entire subset of the font, such as, Latin characters only. Another issue may be kerning, where each SVG has precisely the same font, but the spacing is different. I have been having some issues with my font spacing, but I only have the one Linux machine. I have not found my problem yet, but I think I may have inadvertently removed a font from my system; error between keyboard and chair, in my case. That is when I thought, “I ought to have embeded the stupid font!” Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 13 Oct 2020 at 09:34, Willy Williams wrote: > > On 10/12/2020 at 19:53, Guillermo Rozas wrote: > > > The logo looks identical on all three >> machines when viewed in Inkscape, yet when it is exported into the >> appropriate location for user-generated watermarks in darktable on each >> of the three machines, the two lines of text below the script logo shift >> slightly in size and position when the watermark is applied to an >> identical test photo on each machine. > > > Are you exporting the logo on each separate machine? Have you tried using > the same exported SVG file (from any machine) in all? > > The original .AI image was opened on only one (Win 10) machine and the > resulting .SVG image was copied to the remaining two machines (Win 10 and > Linux). That .SVG file was opened in Inkscape on all three machines and > appeared identical in font and in type location relative to the logo > graphic, just as it was created on the first machine. > > > The script logo does not shift at >> all; it's just the three lines below the logo that shift. Am I not >> holding my mouth right? Did I forget to perform some weird incantation >> on the full moon? >> > > First thing that crosses my mind is that the three machines are not using > the same version of the text font. Are you sure Inkscape and/or darktable > are not doing some font substitution? > > The Win 10 machines appear to be using the same (sans serif) font. I'm > not sure which font that Linux machine is using. Today I'm going to switch > to a different font that I know is the same on all three machines and try > again. I know this font (Della Robbia BT) is the same because I personally > loaded it onto all three machines. > > > One thing to test: convert the text to curves on Inkscape before > exporting. > > Thanks for this suggestion. I'll give it a try today and see what > results. > > > Best regards, > Guillermo > > Thanks for your insights, Guillermo. > > Willy > > > > 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] Re: Question regarding watermark location in Ubuntu Linux
> > Well, on my system (and most, if not all, other linux/unix systems I've > seen), > $USER1 is indeed your login name, but $USER2 (group) is *not* the same, > commonly I'd expect a normal user to be a member of group "users". OP did say that he was running Ubuntu Linux 20.04.1, and under Ubuntu, it is the norm that users are in a group by the same name, consisting of a single member, themselves. For that reason, $USER1 ought to be the same as $USER2, for a normal Ubuntu install. Because it may not be a “normal Ubuntu” install, but follow the norm for most other distros, the possibility of $USER1!=$USER2 was real, unusual for Ubuntu, but not necessarily a problem. The only important part here is the first group of "rw-", the others won't change anything (in this respect), as darktable is running with the login name as user. IF Dt is running as such, which ought to be so, but, depending on how it was invoked, it may not necessarily be so. for OP: > Something else that *may* play a role (based on some other questions about > access I've seen): are you by any chance using a snap package for version > 3.2.1, and a different install method for 3.0.2? One particular reason why it may be dependent on the invocation. Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Re: Question regarding watermark location in Ubuntu Linux
One thing which occurred to me, and I cannot see why this will be so, but I thought of permissions on your files. Do this…. > ls -l ~/.config/darktable/watermarks/*.svg and you should see something to the effect of > -rw-rw-??- 1 $USER1 $USER2 ??? MM DD > /home/$USER1/.config/darktable/watermarks/MyWatermark.svg First off, $USER1 and $USER2 would normally be the same thing. (If it is not, that does not mean that something is wrong; just that something is unusual, and that might be a problem). Second, $USER1 ought to be your Linux login username. (If it is not, then something is probably wrong). Finally, depending on what $USER1 and $USER2 are, the lines ought to start with one of, -rw-r- … -rw-rw … -rw-r--r-- … -rw-rw-rw- … If it does not, then we may have an idea of where to start. So tell us what you see when you type the command, and we can possibly go from there. (If what you see is one of the four above listed patterns, and $USER1==$USER2, then I am still stumped, but it may still help to know). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sat, 3 Oct 2020 at 11:22, Willy Williams wrote: > Thanks for the input, jys. An interesting thing - being somewhat > arbitrary, I chose to revert from darktable 3.2.1 to 3.0.2 on my Linux > machine this morning. Interestingly, I can now see the three new .svg > files in darktable (in the $HOME/.config/darktable directory) and use > them to create watermarks. Thanks for your help and guidance. > > Willy Williams > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Re: Question regarding watermark location in Ubuntu Linux
Either one can make your system unstable. The difference is that
> sudo cp myLogo.svg /usr/local/share/darktable/watermarks
does one thing then exits the SU privileged command, (sorta), whereas,
> {RMB-Click} → {Open as Administrator} → {DnD}
leaves a client window open with SU privileges, (if not closed when one is
done)
Even at the CLI, unless one does [ $exit {ENTER} ] after, someone can come
along within 15 minutes and do any sudo command in the terminal without
having to enter a password. (Even the Nautilus window will request a
password again after 15 minutes of inactivity).
What one ought not do, is
sudo My-GUI-Application
at the CLI, but perhaps,
gksudo My-GUI-Application
a safer alternative, which has been removed from the most recent Ubuntu
flavours, anyway.
What I suggested is no more dangerous than the CLI method. Any use of
elevated privileges is a security risk, to some extent, and can hose a
system by a simple mistyped path/command.
Sincerely,
Karim Hosein
Top Rock Photography
754.999.1652
On Sat, 3 Oct 2020 at 12:24, Jean-Luc CECCOLI
wrote:
>
> Patrick and jys gave you the path, however I think useful to warn you
> against the temptation of sudo nautilus (or whatever filemanager you use).
> This is the thing not to do if you do not want your system to become
> unstable.
> If you really need to copy files to a system area, then sudo cp them from
> cli.
>
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Question regarding watermark location in Ubuntu Linux
To clear up a few things…. “$HOME” is a variable which refers to the current user's home directory, which for Ubuntu 20.04., is at /home/$USER where $USER is the unix username, of whoever is currently logged into that session, e.g., /home/karim So that, for $USER=‘greycard’, the directory, $HOME/.config/darktable/watermarks will be at /home/greycard/.config/darktable/watermarks Any watermarks placed there will only be available to that particular user, in this case, ‘karim’. To create a watermark which is available to all users, it would need to be placed in the directory you mentioned, /usr/local/share/darktable/watermarks but only a user with superuser privileges can write to that directory, using sudo, or with administrator privileges in the GUI. This may be the way to go, if one is in an environment where more than one user will be using the same watermarks, say for a studio. To sum up, /home/$USER/.config/darktable/watermarks is for one particular user, “$USER”, and /usr/local/share/darktable/watermarks is for all users on the system. To make a systemwide watermark from, /$HOME/Pictures/SVG/MyWatermark.svg available to all users, do > cd ~/Pictures/SVG > sudo cp MyWatermark.svg /usr/local/share/darktable/watermarks >From “Files”, a.k.a., Nautilus, —the actual name of the application is, “Nautilus”, but Ubuntu makes it appear to end users as, “Files”— an navigate to "Computer/usr/local/share/darktable/watermarks". (One ought to now see four SVG files). Right-click, (or press the [ Application ] | [ Menu ] key on the keyboard), and select, “Open as Administrator” with the mouse, (or press, [ d ] on the keyboard). You will be asked to enter your password, (assuming you have SuperUser privileges). A new “Files” window will open, (with the same four files visible). Drag whatever SVG files you want available to all users into this window. When done, CLOSE THE WINDOW! (It is a security risk to walk away from your computer with any SuperUser privileged task running). All SVG files in that window will now be available to all system users. …so I created one and populated it with the .svg files, but darktable > doesn't find them. You may have to restart Dt for it to see the files, or try to click the “Refresh” symbol —circular arrow— beside the Watermark dropdown menu, to refresh the list. (If that does not work, try restarting your computer. Such drastic action ought not be necessary, but it means that, somewhere along the way, when the configuration was supposed to read the presence of those files, it did not. Restarting simply means that all configurations will be re-read in the order in which they are to be done, for the entire system). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 1 Oct 2020 at 18:53, Willy Williams wrote: > Where are watermarks stored in darktable 3.2.1 under Ubuntu Linux > 20.04.1? > > 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] Re: Change aspect ratio? (non uniform scale)
I have only used the “perspective correction” module two or three times, (and for architectural shots). Most perspective corrections which I have to do are more for aesthetics than accurate depiction, and I tend to use the keystone correction tool in the crop module. I am not certain as to what algorithm is used in the perspective correction module. Perhaps someone close to the developers can answer that. If it did, then one would end up with the correct size ratio of the paper. (Remember to also do lens-correction, as that can also skew your size ratios). Also, when I said, “phone,” I actually meant camera. My MIL has a home aide who uses her camera phone to “scan” her paperwork every Friday, so while thinking, ‘camera,’ I said, ‘phone.’ One can keep the camera parallel to the paper and still avoid reflections, by not centering the camera to the paper. Still keep it parallel, just not centered. Also, have light-sources off-centered also, (but not opposite to the camera, as angle of incidence equals angle of reflection). are we better doing perspective correction in GIMP or DT? Both programs > have intuitive options for this. Not certain. Never actually tried perspective correction in The Gimp. Again, probably a developer question also. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 16 Sep 2020 at 22:43, Felix E. Klee wrote: > > How about the “perspective correction” module? This should do it > correctly, right? For the given purpose, however, “keystone” in the > “crop and rotate” is way easier to use. So far I have not noticed any > distortion, but my photographs of documents were not angled too crazy. > Normally, I just need a little correction. > > I “scan” with my compact camera, and only if I need to. Sometimes, for > example when taking a photo of a postcard in non perfect lighting > conditions, it’s necessary to shoot at an angle to avoid reflections. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Change aspect ratio? (non uniform scale)
Sorry, did a reply, but I do not think it went to the list. This was a reply to Graham Byrnes, who wrote,… I think you'll find that this is what it does: if you correct for keystone > on one axis, then you apply a constant rescale on the other, you return to > the trigonometric approach you suggest. It would be possible to combine > them, but the 2nd axis effect is just a constant factor. > Then you could also add the loss of focus due to shifting the focal > plane... which is less likely to be popular. Thank you. I was just going through my head as to what you said, and, at first it made no sense. But looking at it from a geometric perspective, it is logical that any “pixel” expanded on the y-axis, ought to be expanded on the x-axis to the same degree, and any reduced on the y-axis, likewise on the x-axis. Simple arithmetics; no trigonometry needed. The thing is that the re-size is non-linear, during the perspective correction, whereas correcting in The GIMP later would be linear. (…And, ideally, the square pixel becomes a trapezoid pixel 😁 ). As for the focus issue, that was the problem in the darkroom. When we did that, we had to stop down the aperture to achieve a deeper DoF, to keep the image focused on the paper. Of course, film did not have “pixels”, but grain, and grain is random, not in a neat little matrix. (That neat little matrix is the one thing which still bothers me about digital photography). I suppose that if the resolution was large enough, (and the final print small enough), it would be less obvious, (which is one reason we tended to shoot architecture at the lowest possible sensitivity, and the largest possible film stock). 😉😊😀😁 Sincerely, Karim Hosein Top Rock Photography 754.999.1652 I think you'll find that this is what it does: if you correct for keystone >> on one axis, then you apply a constant rescale on the other, you return to >> the trigonometric approach you suggest. It would be possible to combine >> them, but the 2nd axis effect is just a constant factor. >> Then you could also add the loss of focus due to shifting the focal >> plane... which is less likely to be popular. >> >> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Change aspect ratio? (non uniform scale)
The problem here is that most software algorithms do not do keystone correction the same way that enlargers did. When an enlarger was tilted to correct keystone, aside from expanding/contracting along the x-axis, it also elongated/shrunk along the y-axis. Modern software does not seem to do that. They treat the two axes independently. Although stretching an axis in The GIMP will fix the size ratio of the entire image, it may still leave height variabilities in the fonts on the top of the page, versus the bottom of the page. (That will also happen with adjusting the pixel size ratio). What really needs to happen is that a separate keystone correction module —i.e., separate from crop/rotate, or, at least, separate from crop,— needs to be re-written from scratch, which corrects keystone by a mathematical formula, based on projecting the 2-D image onto a plane being manipulated in 3-D space, using trigonometric equations. Yes, this can solve for rotation, as well. Come to think of it, it can also solve problems for crop, as well. Hmm. Necessity may very well be a mother, as such a re-write will be a slightly more convoluted solution than most current keystone algorithms, based on single axis variable scaling. The best solution for “scanning” with a phone, is to make every effort to hold the phone parallel to the paper during capture, if maintaining aspect ratio is vital. This way, keystone correction will not be necessary. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sat, 29 Aug 2020 at 04:49, Felix E. Klee wrote: > Sometimes, if no scanner is around, I take photos of documents or > postcards. These can be corrected fairly quickly using keystone and > crop in the “crop and rotate” module, plus some color correction. After > correction, however, the aspect ratio will never be perfect. An A4 > page, for example, will be slightly off the √2 aspect ratio. Is there a > way to correct aspect ratio from within Darktable? > > The only > thing that would be even better is to fix the aspect ratio when > converting the exported images to PDF using some PDF command. > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] cmake errors: variables not set in master/debian buster
You may want to delete the build directory, and install,…
libcolord-dev
libcolord-gtk-dev
libsoup2.4-dev
libosmgpsmap-1.0-dev
..then do the build again.
Keep in mind that the version numbers hee are what is on my Ubuntu 20.04.1
distro. Your system may have some other versions. Search in your package
manager for,…
colord
soup2
osmgps
…for the packages specific to your distribution.
If you are using Windows, (or Mac), you may have to download, build, and
install those also.
Also note that, aside from errors, the build/compile process may throw up
warnings, which allows the system to build, compile, install, and run, but
without certain features enabled. As such, look for these warnings as well
as errors. Delete the build directory, install the dev files needed, and
re-build/compile.
Some of these warnings may be innocuous. They may look similar to…
Looking for such-and-such
Looking for such-and-such SUCCESS
Looking fo so-and-so
Looking fo so-and-so FAIL
Looking for this-and-that
Looking for this-and-that SUCCESS
…but everything continues as normal. The program will build, compile,
install, and run, but whatever module or feature which relies on
“so-and-so”, will not be available.
Also, suggested that you install the, “whatever-dev” package. That is often
what the system is looking for, but occasionally, it is looking for some
executable. In addition to the, “whatever-dev” package, you may want to try
to install the, “whatever } package with it. In other words, for the top
list, using Ubuntu/Debian, do,…
sudo apt-get update && sudo apt-get
install colord libcolord-dev libcolord-gtk1 libcolord-gtk-dev
libsoup2.4-1 libsoup2.4-dev libosmgpsmap-1.0-1 libosmgpsmap-1.0-dev
…and it ought to work. (Try just the dev files first if you want to avoid
installing things you may not need).
Sincerely,
Karim Hosein
Top Rock Photography
754.999.1652
On Mon, 14 Sep 2020 at 03:39, Bernhard
wrote:
> Hi,
>
> I just wanted to build the current master and get this:
>
> > CMake Error: The following variables are used in this project, but they
> are set to NOTFOUND.
> > Please set them or make sure they are set and tested correctly in the
> CMake files:
> > _colord_LIBRARY
> > linked by target "lib_darktable" in directory
> /home/{username}/github/darktable-org/darktable/src…
> > _colordgtk_LIBRARY
> > linked by target "lib_darktable" in directory
> /home/{username}/github/darktable-org/darktable/src⎄.
> > _libsoup2_LIBRARY
> > linked by target "lib_darktable" in directory
> /home/{username}/github/darktable-org/darktable/src…
> > _osmgpsmap_LIBRARY
> > linked by target "lib_darktable" in directory
> /home/{username}/github/darktable-org/darktable/src…
> >
> > -- Configuring incomplete, errors occurred!
>
> when running the command
> > $ cmake -DCMAKE_INSTALL_PREFIX=/opt/darktable/ ..
> …
> Any suggestions?
>
>
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] could someone direct me....
Of course it is. It always is. I am in the middle of a one-minute, thirty-second exposure right now. Even then, one can always squeeze in time to help other photographers. Oh, I have to go. I need to adjust my aperture and take the next frame. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sun, 13 Sep 2020 at 16:25, Patrick Shanahan wrote: > * Top Rock Photography [09-13-20 15:05]: > > This is not logical, and somewhat incorrect. The [ lensfun-data-v1 ] > > package needs no mention of the file, as the programme makes mention of > it. > > In the worst-case scenario, the new version of lensfun already has the > new > > camera/lens in its database, and any references to the same camera/lens > in > > any extraneous files are ignored. > > > > What system-wide updates do is that only one user has to run the update, > > (and we assume that that one user is a sysadmin who knows what they are > > doing). With local updates, all users have to run the update, creating > > multiple copies of the same file. Turning Debian into Windows is not a > good > > idea. 😄😉 > > > > The only time a local update is advised, is when creating a custom entry > > for some non-standard camera/lens combination, such as a howe-made, > > Frankenstein, macro-lens. That is NOT something which one would > necessarily > > want other users to have in their database. > > > > Sincerely, > > > > Karim Hosein > > Top Rock Photography > > 754.999.1652 > > > > > > > > On Sat, 5 Sep 2020 at 10:42, Timur Irikovich Davletshin < > > timur.davlets...@gmail.com> wrote: > > > > > Let's imagine new camera or lens family appears, this creates new file > > > in lensfun data structure. This file is orphaned since it is not > > > mentioned in lensfun-data-v1 package. During regular apt update this > > > will create mess. Turning Debian into Slackware is not a good idea 😄 > > > > > > Timur. > > > > > > > > > > We really have much too much time on our hands. Perhaps time to go > capture some images? > > -- > (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 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Overexposure icon and others invisible
Try clicking on the little triangle on the bottom of the screen. The area with those tools, and the filmstrip, can be hidden/shown by clicking the triangle. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sun, 13 Sep 2020 at 15:45, Matthias Albert wrote: > After the last update, the overexposure icon ant aother icons at the > bottom right corner of the > darkroom view are not visible anymore. > > I am using Darktable 3.2.1 on Manjaro Linux /XFCE. > > Any idea, what can be done? > > mATTHIAS > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] could someone direct me....
This is not logical, and somewhat incorrect. The [ lensfun-data-v1 ] package needs no mention of the file, as the programme makes mention of it. In the worst-case scenario, the new version of lensfun already has the new camera/lens in its database, and any references to the same camera/lens in any extraneous files are ignored. What system-wide updates do is that only one user has to run the update, (and we assume that that one user is a sysadmin who knows what they are doing). With local updates, all users have to run the update, creating multiple copies of the same file. Turning Debian into Windows is not a good idea. 😄😉 The only time a local update is advised, is when creating a custom entry for some non-standard camera/lens combination, such as a howe-made, Frankenstein, macro-lens. That is NOT something which one would necessarily want other users to have in their database. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sat, 5 Sep 2020 at 10:42, Timur Irikovich Davletshin < timur.davlets...@gmail.com> wrote: > Let's imagine new camera or lens family appears, this creates new file > in lensfun data structure. This file is orphaned since it is not > mentioned in lensfun-data-v1 package. During regular apt update this > will create mess. Turning Debian into Slackware is not a good idea 😄 > > Timur. > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] I think I found a bug:
This article may be helpful. https://discuss.pixls.us/t/darktables-filmic-faq/20138 Sincerely, Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] I think I found a bug:
Whenever further editing needs to be applied in another application, an output colour profile is only necessary IF the second application can only read image formats with a colour profile attached, or you have already done some necessary colour adjustments. If one takes one's most heavily edited image in Dt, and look at the [ show only active modules ] tab, one will see that the [ input colour profile ] occurs immediately before the first colour correction module, and the [ output colour profile ] module is one of the last modules, occurring after the last colour correction module. Most of the actual development takes place BEFORE colour profiles are even considered. Raw black/white point, white balance, (which has to do with the relative level of RGB response, and not the actual values of R, G, and/or B), highlight reconstruction, (again, relative response), demosaic, (again, relative), orientation, crop and rotate, retouch, and exposure, all come before input colour profile, (and is NOT an exhaustive list). If no colour work is being done before the next application, then a linear colour workflow format such as OpenEXR is more than adequate, and highly recommended, (by me, and industry creatives). If one has done some colour work, and there is more colour work to be done, (or if the next application cannot read OpenEXR, or other linear colour model formats) then I highly recommend a high colour gamut profile such as ProPhotoRGB. If any other processing does not involve colour work, (such as, you are the final colour grader), then use an appropriate output colour profile such as sRGB, unless that is someone else's job to decide, based on expected usage. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 4 Sep 2020 at 21:13, Terry Pinfold wrote: > Thanks Karim for this great explanation. I will share this with my > students in future because it is one of the best explained answers on this > topic. Are you a fan of ProPhoto RGB instead of sRGB or Adobe RGB when > further editing will be applied? > > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] I think I found a bug:
16,384 protons generate a value of 16,384. This is a linear correlation. Is 16,384 White? No; it is merely ‘saturation’. For a 14-bit sensor, that is the maximum value which it can store. It may have been a very dark scene, shot at *f*/1.4 and an exposure time of 30 seconds, just to saturate that one pixel. Nothing was really ‘white.’ Almost everything was black. The photographer chooses what they want the viewer to see as black, white, or middle grey. On the other hand, it may have been a rocket launch on a very bright day on the beaches of the Space Coast of Florida. The image may have been taken at *f*/45, and at ¹/8000 seconds, and nothing was black, nor even middle grey. It was just one, big, blob of whiteness. Again, the photographer chooses what the viewer sees as black, middle grey, and white, and now we see a greyrocket against a dark sky, with white rocket blast. We basically have a mere 14-stops of linear data on this 14-bit sensor. On a 10-bit sensor, the values only go from 0 to 1,024, representing a mere 10-stops of linear data, but on a 16-bit sensor, from 0 to 65,536, representing 16-stops. Why do many 14-bit DSCs claim a mere 12.5 stops of dynamic range? Because no sensor has a 100% efficiency, and a lot of the low values are indistinguishable from noise. I.e., no pixel can be given, with any degree of certainty, a value of zero, or one, or two, etc. A pixel which registers zero, may have been hit by a photon or two, (or more), which simply did not register a reading, while a pixel which was not hit at all may show a reading of one or more, simply due to noise from heat, or electronic interference. The more efficient the sensor can be made, (where one photon always generates one electron), and the less susceptible the sensor can be made to heat, and electronic interference, the better one is able to get a 14-stop dynamic range from a 14-bit sensor. Of course, one can “cheat” the system using a logarithmic interpretation, or some other “curve.” Yes, that is what “curve” tools do, bending the interpretation of the linear graph, (usually at the extremes, near black, and near saturation), to “create more dynamic range,” or to “ceate more shadow/highlight detail.” (In reality, one cannot create what was never there in the first place. It is just an illusion). Hope I was not too technical. (I also hope that I got nothing wrong. 😉 ) Sincerely, Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] I think I found a bug:
Not really a bug, per se, (and not in Dt) The application which is being used to do tho merge is using integer arithmetic. (Dt uses floating point). When an int goes beyond its range, it gets clipped to the maximum. Any correction then gets evenly reduced. So for an integer between 0 and 255, a value of 255 gets increased by 30%, it remains at 255. If reduced by nineteen percent, it becomes 206. The clipped areas in your “bright” image got reduced to an even grey. With fp values, nothing is really “out of range” (technically possible, but nevermind that), meaning that if the value is to fall somewhere between 0 and 1, but it gets computed to 1.3 (or even 17.9), the variable can still hold the number. If these numbers are then later reduced accordingly, and, if reduced by nineteen percent, is still 1.053, or still at saturation (>=1). So, with the two images, the application does some maths on a certain value near zero, and a certain value at 255, and it results in another value, (somewhere in the vicinity of > 127). But with the tree images, at some point, the high value got clipped, and then reduced, resulting in the even grey circles. One can say, “but I used a 16-bit format.” Sure, but if it was a 16-bit integer format, one still has the same problem, except now, the values are 0-65535, and 65535 times 30% is still 65535, reduced by 19 % is still 53083. With a 16-bit fp, or a 32-bit fp, the answer is still 1.053; the only difference is to what decimal place accuracy. Perhaps, if the images were sent to the algorithm in a different order, it would not have resulted in the clipping. Pipeline order is important, especially with integer mathematics. Talk to the developers of the program doing the merge, to consider using a fp pixel pipeline in their next major upgrade. (That is no easy feat. It may involve a total rewrite, and a few years. Just ask the developers of The GIMP). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 1 Sep 2020 at 15:49, Michael wrote: > I merged three files of a room and got a round discoloration. I then > merged The lighter and darkest image and the pic was normal. If it is > a bug please fix it. If it isn't a bug nevermind:) > -- > :-)~MIKE~(-: > images > https://drive.google.com/drive/u/2/folders/0B2xvsVTZy4y1ODR6dTk5UldpR3c darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Darktable 3.2, a short review
Do not get caught up on the Sharpen module. I remember reading an article which claimed that ALL digital images NEED sharpening, and justified it by claiming that ALL digital cameras do unsharpening with the OLPF, a.k.a., AA filter. This is not true. My Pentax, (and every Pentax since the K-5 IIs, and several other manufacturers since the K-5 IIs), no longer put an OLPF on sensors with more than 16 Mpx. The truth which Pentax realised is that there is no point to make something unsharp, just to try and sharpen it again with an unsharp mask. One gets more detail by simply never unsharpening it in the first place; no OLPF. Then why was it put there in the first place??? To combat moiré. Then why did Pentax get rid of it? Because on high Mpx sensors, moiré is less of a problem, and there are other ways to combat moiré than blurring an image, (and if one needed to, they have a simulated AA filter with two strengths options). Fact is, that unless one has an OLPF in their camera, one probably does not need an unsharp mask, except for what it was invented. Back in the emulsion days, an unsharp mask was not a normal part of the workflow; it was a creative tool for a creative effect. (It also took advantage of “depletion zones” in emulsions, to bring about the effect. CMOS/CCD sensors do not have these depletion zones). But, if one insists on using the Sharpen module, whenever I used it, (on the pre-3.2.1 releases), was to not use the default method, but the other method, and got better results. (I just opened up Dt to look at what the two methods were called, and realised that Dt ver 3.2.1 has only one method to do sharpening, or at least my build only has one method. Did not realise that until now, as I rarely use it). Furthermore, if one will be scaling down the image to lower resolution, then sharpening is not only unnecessary, but whatever sharpening is done on the high Mpx original, will probably get lost, anyway, (depends on how much one re-sizes down). Regarding highlight/shadow recovery, no real image processor can recover what was never there. If the sensor had hit saturation, the highlight detail is forever lost. If the light level was very low, then shot noise overwhelms the details, which can never be truly brought back. Some image processors use computer learning/AI to create what was never there in the first place, and sometimes, just sometimes, the results look acceptable. Usually, not natural. In a video where Aurelein was demonstrating how to do professional edits with time constraints, someone submitted an awful image with a grossly under-exposed subject, with a heavily clipped sky, (sun behind clouds). One person had asked, when Aurelein was done, why the sun was not yellow. Well, the sun is NOT yellow, so it ought not be. However, some other programs, when they reconstruct such images, make the bright area quite yellow. This is because, if one had a bright sun in a blue sky, as one approaches the sky, the blue is the first to clip, the red is the last. As the AI is trying to figure out what was supposed to be there, it concludes that what was there was obviously mostly blue, and least red, reproducing a mostly blue+green area, —the sensor is mostly green,— making the sun yellow. This fading into yellow may possibly look better than fading to a big white blob, but nevertheless is unnatural. This is what some are used to seeing when they “reconstruct/recover” the highlights. Similarly for shadows, in that, what the AI thinks is there, may look better than what was actually there, but is nevertheless, unnatural. What one may think is a “better job,” may just be what one is used to getting from badly coded AI algorithms. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 1 Sep 2020 at 04:39, Kneops wrote: > DT is great :), the only two things that currently hold me back is that > I still think LR overall does a better job in highlight / shadow > recovery and detail/sharpness. I just played with an image of wooden > beach poles and LR gives me more detail and edge sharpness, even when > adding sharpness + local contrast + the highpass filter in DT. > > I'm a linux user and have 2 pc's, and there is no doubt in my head that > I would turn my newest and really fast pc back into an Linux machine too > if I can get those two things right, because I currently consider that > investment a waste of money if I only use it for LR. DT in Linux on that > new pc is so fast I could not even see the thumbnails being created > during import, they were just there in a blink of an eye :). > > > > Op 31-08-2020 om 21:28 schreef Matt Maguire: > > Darktable is great, it has taught me some much about image processing, > > and I haven't looked back at leaving Lightroom since. > > > darktable user mailing l
Re: [darktable-user] Darktable 3.2, a short review
Dt uses multi-threading, multi-core, & GPU acceleration. Adobe Lr (and Ps) does not. If you watch YouTube tutorials on buying a computer for image editing, they will almost all tell you to get the most powerful CPU, regardless of how few cores it has, (e.g., a two-core i9 vs an eight-core i3, or a 12-core Ryzen5), ignore GPU, and get at least 8GB of RAM, no more than 16GB, (because then you have diminishing returns, with negligible gains), and spend the rest of the money on fast storage. That advice is based entirely on using Lr/Ps. With such a setup, it may actually be possible that Lr outperforms Dt. I am not certain of that. But get a less powerful CPU with 8 to 12 cores, (16 to 24 threads), & a powerful GPU, and Dt will run circles around Lr. As for fast storage, that has to do with the dismal performance of Lr on importing images. I have heard pros talk about waiting overnight for Lr to import 1,000+ images from one shoot, on spinning rust. (Who shoots 1,000 images in one day)? Using SATA SSD or even NvMe m.2 SSD speeds up Lr imports to some extent. (really, only the writing to the drive and to the database). In any case, on my ten year old system, (AMD Phenom II X6, with six cores & six threads), with a four-HDD, RAID5 storage, (a GTX 760 GPU & 32 GB of 1600MHz DDR3 RAM), I recently uninstalled DT 3.0, and in doing so, accidentally deleted my database. I re-installed Dt 3.2.1 (I had compiled from source), and had to re-import my images, (tens of thousands). It took about an hour. (Granted, my side-car files were already there, so they did not have to be written, but they all had to be read in, again, to sync with the database). Typically, after a shoot, (maybe 300-500 images, at worst-case), my import takes less than five minutes, if that long. So, yes, the sports- car metaphor goes all the way. If one wants the best performance on the track from one's sports car, install a great engine, use high-octane fuel, and get an excellent driver. Use a multi-core processor, use a quality GPU, run it on Linux, etc. (Yes, there is anecdotal evidence, done using the same HW, which suggests that Dt runs faster on Linux, over Windows. Not sure if anyone tried Linux vs Mac OS, or Mac OS vs Windows, but Mac OS users seem happy). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 25 Aug 2020 at 04:10, wrote: > Terry & all readers, > > > > as a beginner this thread is very good to keep me motivated. I’ll continue > to enthusiastically use darktable to gradually acquire the skills of a > ‘sports car driver’. > > > > Is the comparison with the sports car also correct when it comes to the > engine, ie the computer? I think so, but I only have experience with an > aged version of Lightroom (5.7) on Windows. LR gave acceptable response > with my 16 MP raw files on a 6 years old Intel dual core laptop with 8 GB > of memory (no discrete GPU) under Windows. Use of darktable was a pain on > that laptop. Now on my recent laptop LR (5.7) response is flashy while dt > response is acceptable. > > > > Would anyone who uses both programs, in up-to-date versions, on the same > computer under Windows or MacOS, comment on that? > > > > The question is somewhat important as I often interact with fellow photo > art students at the evening school. (I hate to say this here, but they are > mainly Mac, some on Windows, but never on Linux.) > > > > Marc. > > > > *Van:* Terry Pinfold > *Verzonden:* dinsdag 25 augustus 2020 0:24 > *Aan:* Kneops > *CC:* darktable forum > *Onderwerp:* Re: [darktable-user] Darktable 3.2, a short review > > > > It is really worth investing the time in learning DT. As an editing > program it leaves LR for dead. Yes Adobe has made a very easy to use > product. Rather than complicated modules just a few sliders and you have a > good image. LR is like an automatic car. DT is a high performance sports > car. Depends what you are happy to settle for. I have LR so my preference > is not based on what I am willing to pay for, but which program is more > capable. For me, Darktables drawn paths to localise adjustments leaves the > adjustment brush in LR looking a little sad. > > > > On Mon, 24 Aug 2020 at 17:08, Kneops wrote: > > Hi Michael. I agree ofcourse with what you say, but 'After a month'... > is exactly what I mean. If it takes a month, something is not right. I > never used LR, but opening it and - like I said - I could edit 99% of my > images the way I want within 5 minutes. I even don't use Gimp anymore, > unless my sensor had become too dirty ;). > > > > Op 22-08-2020 om 22:04 schreef Mikael Ståldal: > > The filmic module can be a bit intimidating and unfamiliar if you are > > used to Lightroom. But if you just spend a few hours watching v
Re: [darktable-user] Darktable 3.2, a short review
Regarding the Adobe subscription, whereas one can pay for the annual subscription in a single payment, or monthly, Adobe does NOT offer a month-by-month subscription; they only offer annual subscriptions. There is a pro-rated penalty for early termination, which is 50% of the outstanding balance of the full annual cost. If you have it for a month, you may as well keep it for the year. Read the terms of service. Now the terms of service do mention cancellation of the “monthly” plan, however, Adobe does not offer a monthly subscription plan for sale. Then why mention it? Because, if one keeps their annual plan for the full year, one is THEN converted to a monthly subscription. So do not think that you can just get it for a single month. That will cost you about ¤65 on the 1TB Lr subscription, or the 20GB Ps/Lr subscription, or about¤130 on the 1TB Ps/LR subscription. However, one might possibly be able to get it for less than14 days for free, IF one is a first-time user, and cancel within the first 14 days! Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Fri, 21 Aug 2020 at 07:45, Kneops wrote: > …I don't > think I will ever need Prophoto though, but in case I do I can always… *subcribe to LR for one month ;).* > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] to compile darktable or not....
I compile for two reasons: 1. It is often a n unbearable wait for the latest version to come to ubuntu [evenYear].04 LTS, and 2. Some features are NOT in the official ubuntu build. For example, WebP support, and AVIF support. (WebP, I use, AVIF, I just want to play around with). Indeed, one build I got from official ubuntu repos did have WebP support, but NOT with EXIF/metadata. That build used an old version of Exiftool. I had to dwnld & compile the latest Exiftool, then compile the latest Dt. If the build for your platform is current, and it has all the features which you want, then there is no need to compile. If you are missing a feature which you deem is important, then go ahead and compile…. …BUT NOT from dailies/beta. Use the stable branch. (Well, you can use the dailies, just do not bet on it working flawlessly). I have compiled several stable versions of Dt now, without any apparent bugs, (beyond what is mentioned in the release notes/bug reports). Good luck. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Wed, 19 Aug 2020 at 14:11, Michael wrote: > that is the question! > Is there any benefit to compiling the program on my own? > > -- > :-)~MIKE~(-: > > > 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] Darktable 3.2.1
CORRECTION: I DID NOT download a G'MIC tarball and compile; I downloaded a G'MIC *.deb file and installed. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 11 Aug 2020 at 14:04, Top Rock Photography < ka...@toprockphotography.com> wrote: > For LLVM, I installed, > llvm-10-dev > Your system may have it listed as a dependency package, > llvm-dev > depending on the latest version. That being said, my system, (Ubuntu > 20.04), has llvm-7-dev, llvm-8-dev, & llvm-9-dev, also installed, (I > suppose they were dependencies of some other development tool I installed). > I also do NOT have llvm-dev installed, but it is available. > > For G'MIC, I tried using, > libgmic-2.4.5-1.1 > but that did not work. I downloaded the latest (stable) tarball, 2.9.1, > and compiled. That worked. > > For libavif, I tried, > libaom-dev (1.0.0) > but that did not work. I downloaded the latest (stabe) version of > libaom/aom-tools, (2.0.0), using git, ( > https://aomedia.googlesource.com/aom/), and compiled. Still did not work, > BUT, was still necessary. > > I then downloaded the latest libavif (0.8.1) using git, ( > https://github.com/AOMediaCodec/libavif), and tried to compile. Had > trouble, so this is what I had to do…. > > >1. Re-compile libaom using these parameters… >cmake -fPIC -DBUILD_SHARED_LIBS=1 -DENABLE_EXAMPLES=1 -DENABLE_TOOLS=1 >-DCONFIG_AV1_DECODER=1 -DCONFIG_AV1_ENCODER=1 -DCONFIG_LIBYUV=1 >-DCONFIG_WEBM_IO=1 -DCONFIG_MULTITHREAD=1 -DENABLE_DOCS=1 .. >make [-j6] >sudo make install >2. Re-compile libavif using these parameters… >cmake -fPIC -DBUILD_SHARED_LIBS=1 -DAVIF_CODEC_AOM=1 -D >-DAVIF_BUILD_EXAMPLES=1 -DAVIF_BUILD_APPS=1 .. >make [-j6] >sudo make install >3. Recompile Darktable according to their recommendations. > > No errors on compile, everything now, “works.” > > Okay, so saving as an AVIF image takes forever on my old hardware, and I > have no idea how to tell if the resulting files are any good. (I do not > have a viewer with AVIF capabilities, yet). The AVIF libraries are still in > beta. That being said, the encoder apparently does use all my cores when > encoding, and, according to the specs, the decoding ought to be much, much, > much faster. (It takes the time to encode effectively once, so that it can > decode efficiently thousands of times). > > That all being said, the lack of these libraries will not stop darktable > from working. LLVM makes the code/execution more efficient. G'MIC adds some > functionality, (cannot recall precisely what at this time), and libavif > allows one to save the final image in the AV1 image file format. > > Most people save the final image in JPEG JFIF, (regular ‘JPEG’), or WebP, > and save intermediaries in OpenEXR, (16-bit/32-bit float, industry > standard), TIFF, (16-bit float, 16-bit integer, seems to be universally > readable, but do not bet on it), PNG (16-bit integer, and universally > readable), or XCF (8/16-bit integer, or 32-bit float, GIMP/Krita compatible > image) format for further processing by others, or with other software. > > So it can be ‘fixed,’ but does not need to be. > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > > > On Mon, 10 Aug 2020 at 05:50, Dieter Faulbaum > wrote: > >> >> I want to compile darktable "as complete as possible" on a Debian >> testing system. >> >> But I get hints (from build.sh): >> >> -- The following OPTIONAL packages have not been found: >> >> * LLVM (required version >= 3.9) >> * libavif (required version >= 0.7.2) >> * GMIC >> >> I have llvm (version 9) installed and >> libavifile-0.7-dev (version 0.7.48~20090503.ds-20.1+b1) and >> libgmic-dev (version 2.4.5-1.1) too >> >> Can anyone tell me, what is needed to get rid of these hints? >> Is it possible on Debian testing? >> >> >> Cheers >> >> >> 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] Darktable 3.2.1
For LLVM, I installed, llvm-10-dev Your system may have it listed as a dependency package, llvm-dev depending on the latest version. That being said, my system, (Ubuntu 20.04), has llvm-7-dev, llvm-8-dev, & llvm-9-dev, also installed, (I suppose they were dependencies of some other development tool I installed). I also do NOT have llvm-dev installed, but it is available. For G'MIC, I tried using, libgmic-2.4.5-1.1 but that did not work. I downloaded the latest (stable) tarball, 2.9.1, and compiled. That worked. For libavif, I tried, libaom-dev (1.0.0) but that did not work. I downloaded the latest (stabe) version of libaom/aom-tools, (2.0.0), using git, (https://aomedia.googlesource.com/aom/), and compiled. Still did not work, BUT, was still necessary. I then downloaded the latest libavif (0.8.1) using git, ( https://github.com/AOMediaCodec/libavif), and tried to compile. Had trouble, so this is what I had to do…. 1. Re-compile libaom using these parameters… cmake -fPIC -DBUILD_SHARED_LIBS=1 -DENABLE_EXAMPLES=1 -DENABLE_TOOLS=1 -DCONFIG_AV1_DECODER=1 -DCONFIG_AV1_ENCODER=1 -DCONFIG_LIBYUV=1 -DCONFIG_WEBM_IO=1 -DCONFIG_MULTITHREAD=1 -DENABLE_DOCS=1 .. make [-j6] sudo make install 2. Re-compile libavif using these parameters… cmake -fPIC -DBUILD_SHARED_LIBS=1 -DAVIF_CODEC_AOM=1 -D -DAVIF_BUILD_EXAMPLES=1 -DAVIF_BUILD_APPS=1 .. make [-j6] sudo make install 3. Recompile Darktable according to their recommendations. No errors on compile, everything now, “works.” Okay, so saving as an AVIF image takes forever on my old hardware, and I have no idea how to tell if the resulting files are any good. (I do not have a viewer with AVIF capabilities, yet). The AVIF libraries are still in beta. That being said, the encoder apparently does use all my cores when encoding, and, according to the specs, the decoding ought to be much, much, much faster. (It takes the time to encode effectively once, so that it can decode efficiently thousands of times). That all being said, the lack of these libraries will not stop darktable from working. LLVM makes the code/execution more efficient. G'MIC adds some functionality, (cannot recall precisely what at this time), and libavif allows one to save the final image in the AV1 image file format. Most people save the final image in JPEG JFIF, (regular ‘JPEG’), or WebP, and save intermediaries in OpenEXR, (16-bit/32-bit float, industry standard), TIFF, (16-bit float, 16-bit integer, seems to be universally readable, but do not bet on it), PNG (16-bit integer, and universally readable), or XCF (8/16-bit integer, or 32-bit float, GIMP/Krita compatible image) format for further processing by others, or with other software. So it can be ‘fixed,’ but does not need to be. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Mon, 10 Aug 2020 at 05:50, Dieter Faulbaum wrote: > > I want to compile darktable "as complete as possible" on a Debian > testing system. > > But I get hints (from build.sh): > > -- The following OPTIONAL packages have not been found: > > * LLVM (required version >= 3.9) > * libavif (required version >= 0.7.2) > * GMIC > > I have llvm (version 9) installed and > libavifile-0.7-dev (version 0.7.48~20090503.ds-20.1+b1) and > libgmic-dev (version 2.4.5-1.1) too > > Can anyone tell me, what is needed to get rid of these hints? > Is it possible on Debian testing? > > > Cheers > > > 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] Windows or Linux?
I also run Dt on a ten years old system, (AMD Phenom II X6), but with a few upgrades, (4GB nVidia GTX 760, and a 4×2TB HDD RAID5 SATA III storage, 1TB SSD SATA III system drive, 32 GB 1,333MHz DDR3 RAM), and it runs fairly fast under Ubuntu 20.04. Also, 66MHz PCI 2.1 bus. The GPU is PCIe 3.0 capable, but the MB is only PCIe 2.0 capable. I recently did a clean Dt ver 3.0.2 install, and imported 68,000+ raw images, and it took about an hour. I hear horror stories of Lr users taking several hours to import about 1,000 images. Northrup would say that he would come home from a shoot, set his Lr to import the files, and they may be done by the morning, (having run for 7-8 hours). Now that is a Lr CC on Windows comparison. I have no idea how Dt on Windows will do. I do know that ten years ago, my Linux system would run circles around any similarly spec'ed windows machine, but Windows has come a long way since then. The fact that Dt uses HW acceleration, including GPU, and that it does multithreading, (things that Lr does not do), puts it ahead. [ASIDE] I hope to upgrade my computer soon, to a PCIe 4.0 MB, a 12 to 24 core Ryzen, (24 to 48 threads), and 32GB ECC 2,666MHz DDR4 RAM, but I will probably keep the same video card for now, (as well as SSD and HDD RAID). Maybe, possibly, but not likely anytime soon, get an M.2 system drive, and a 6 to 8 GB PCIe 4.0 video card. [/ASIDE] Sincerely, Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Watermark file
That is the part which I had previously explained. After setting up the watermark module the way you want it, click on the hamburger menu and save as a new preset, but, while doing so, check the box which says, «auto-apply this preset to matching images.» When you do that, whatever image you chose as your watermark, at whatever position you had set it, at whatever scale, rotation, and opacity you had set, will become the default thereafter. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 26 Mar 2020 at 11:02, Jesus Arocho wrote: > I do understand the issues below; I guess my issue is that if I click on > the watermark, the default is the darktable file, not any of my files. I > still have to select my file. Also, if I then click on a preset, the > watermark disappears and I have to reselect. > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Watermark file
«… but the matching images part was the catch. I do have presets for portrait and landscape set up.» When you scale the watermark to a certain percentage, you have the option to either always scale according to the long edge, according to the short edge, or to consider the image dimensions, first. With the scaling set to «image», a ‘Portrait’ image will be scaled to the long edge, and a ‘Landscape’ image will be scaled to the short edge of the image. I typically —whenever I use it— have it set to «short edge», as I find that, when set to «image», the watermark appears disproportionately large in ‘portrait’ images. Try those settings and see if they can achieve what you want. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Watermark file
Just get the Watermark module set up the way you want it, then select "Store new preset..." from the module's drop-down menu (the little "burger" icon in the upper left). Give it a name, Any name at all, such as, “My corner logo,” and check the box for "auto apply this preset to matching images". The default criteria will match everything; you can refine the selection if you want. Save the preset, and if you don't actually want it to be *activated* by default, you can de-activate the module, then select "update preset " from the same menu as before. Now the settings will be applied to the module every time an image is loaded, but the module won't be activated. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 24 Mar 2020 at 14:56, Dr. A. Krebs wrote: > > > I want to make a particular file the default watermark. Looked in the > > manual and in the global settings and cannot find the setting. Is it > > possible? > > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] EXIF on Export
Also, Google Photos sees the metadata. You can also use that in a pinch, (assuming that you do not have Google Photo setup to automatically strip the metadata on import). Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sun, 22 Mar 2020 at 20:09, Top Rock Photography < ka...@toprockphotography.com> wrote: > I had a similar problem, (but it was only with WebP files). My problem was > that my version of DT was compiled against an older version of libexiv2. I > had to get the latest EXIV2 source and compile, then get the latest DT code > and compile. Then everything worked. > > …Almost. > > The other problem I had was that my file viewer did not read the EXIF > data, because it, too, was compiled against an older EXIV2 library. So I > had to get the latest source code for that and compile. Then everything > worked. > > To see if the metadata is actually in the file or not, try opening the > file with different editors/viewers, and see if one of them sees the > metadata. (For me, The GIMP did see the metadata). > > Also, there is an option in the latest DT to specify what is exported as > metadata. That ought to be the FIRST thing you do. (Simplest fix). > > Hope this solves your problem. > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > > > On Sat, 21 Mar 2020 at 13:16, David Vincent-Jones > wrote: > >> When I export an image the EXIF data is not included. I think that was at >> some point .. maybe? Is there an option to export EXIF to email or file? >> >> David >> > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] EXIF on Export
I had a similar problem, (but it was only with WebP files). My problem was that my version of DT was compiled against an older version of libexiv2. I had to get the latest EXIV2 source and compile, then get the latest DT code and compile. Then everything worked. …Almost. The other problem I had was that my file viewer did not read the EXIF data, because it, too, was compiled against an older EXIV2 library. So I had to get the latest source code for that and compile. Then everything worked. To see if the metadata is actually in the file or not, try opening the file with different editors/viewers, and see if one of them sees the metadata. (For me, The GIMP did see the metadata). Also, there is an option in the latest DT to specify what is exported as metadata. That ought to be the FIRST thing you do. (Simplest fix). Hope this solves your problem. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Sat, 21 Mar 2020 at 13:16, David Vincent-Jones wrote: > When I export an image the EXIF data is not included. I think that was at > some point .. maybe? Is there an option to export EXIF to email or file? > > David > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] cryptic icons
There is an option in the settings, «GUI Options» «Security» «ask before removing empty folders» The default is ‘un-checked.’ Check that box, and DT will not automatically remove any empty folder. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 > There are two levels to optimize: > > 1. Move all images from a folder to a new folder in the archive from > WITHIN darktable. DT will remove the empty folder. > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] cryptic icons
Replied earlier, but I do not see it in the thread. Maybe I did something
wrong. Here I go again. Sorry if it appears to others twice.
TO: Dr Krebs,
RE: Archiving
The third part of your workflow is the problem. Use Dt to move the files to
the NAS. No need to re-import, sync side-cars, etc.
① In { Lighttable } mode, use the «Select» module to select all images, (or
select the ones you want to archive).
② Use the «Selected image[s]» module to «move…» the selected images to the
NAS.
Done. No sculls, no re-importation.
Also, read the manual on the «Selected Image[s]» module, specifically on
the «move…», «copy…», «duplicate», «copy locally», and, «resync local copy»
options, so you may consider other ways to adjust your workflow.
Sincerely,
Karim Hosein
Top Rock Photography
754.999.1652
> > 1.) From different DSLRs, I empty media (SD, XQD, CS) with OS- this is
> > the most basics, fast and reliable way to bring pics to my hardware.
> >
> > 2.) Actively, I am working on my PC on local directories /home and
> > /data. Here I select, optimize and elaborate pictures.
> >
> > 3.) From there, I regularly move the oldest folders to NAS which
> > serves a archive. So, my procedure is systematic against the
> > capabilities, darktable provides.
> >
> > Of course, I could "import" directories at the _end_ of my workflow,
> > meaning on the NAS location. And neglect the location I'm actively
> > working on pictures.
> >
>
>
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] Re: No metadata in WebP
Problem solved by very helpful people in another forum. First, I had to get the latest EXIV2 source code and compile, then the latest DT source code, and compile against EXIV2 0.27.x. Additionally, even when I got the metadata into WebP files, my viewer, (gThumbs), did not show it. I had to get the latest source code of that, and re-compile against EXIV2 0.27.x. In the time following the fix, —the problem being that Ubuntu 18.04 had an older library of EXIV2, as did the OBS version of Dt,— I have downloaded the source code for DT 3.0.1, and compiled. Everything still looks good. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Tue, 4 Feb 2020 at 12:47, Top Rock Photography < ka...@toprockphotography.com> wrote: > I know that WebP is capable of metadata. I also did a really roundabout > thing to get some metadata into a WebP file once, (but can't remember the > sequence of things I did). > > Nevertheless, I cannot be manually re-adding metadata to each WebP file I > create. If the Metadata is in the RAW, plus whatever I may add with > Darktable, then it ought to be in the exported files which support > metadata, including JPEG, PNG and WebP. > > Not really concerned that much with PNG, but that is also an issue. I only > get metadata in JPEG files. (Then again, I rarely use it, but I never did > check my OpenEXR files if they had the metadata). > > …And on another note, I would expect them to be in my AVIF files once you > start supporting those, but one day at a time. This is really about the > WebP metadata issue right now. Thanks. > > Ubuntu 18.04.4 (until April 2020) > Darktable 3.0.0-1.1 [ download.opensuse.org ] > WebP libraries 0.6.1-2 > EXIF libraries 0.6.21-4 > EXIV2 libraries 0.25-3.1 > > Sincerely, > > Karim Hosein > Top Rock Photography > 754.999.1652 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] Importing, How do you do it?
Funny, but to make sure that I was not speaking of things of which I know nothing, I actually did it before I posted. I “Imported” 179 files from my SD card to my RAID, and added them to the DT database, by using the «Import» module of DT. So, yes, DT DOES move files from one's SD card, renames them, and adds them to your library, with «import». Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 12 Mar 2020 at 16:35, Patrick Shanahan wrote: > * Top Rock Photography [03-12-20 15:52]: > > Patrick, > > > > In Darktable, «Import» means one of THREE things; > > ① to add a file which is located in DAS/NAS, to the DT database, > > ② to add a folder of files (and subfolders of files) which is located in > > DAS/NAS, to the DT database, and > > ③ to move files from a “camera”† to a preset DAS/NAS location, via a > preset > > naming convention, then adding them to the DT database. > > > > All three are considered «Import»ing, all three are available through the > > «Import» module,and all three ought to work. > > > > As others have said, most of us use some other application to move files > > from SD cards or our cameras to our DAS/NAS devices, then use one of the > > first two import methods. (Not that anyone asked, but I use Rapid Photo > > Downloader). That aside, the third import method is legitimately a > > Darktable import method, offered by DT. > > > > To say that that is not using DT, but gPhoto, is akin to saying that one > > does not use DT for raw processing, but Libraw, or does not use DT for > lens > > correction, but Lensfun, et al. DT, like most F/LOSS titles, does not > > re-invent the wheel, but uses third-party wheels, just as Ford, Crystler, > > and GM do. > > > > † I have “camera” in quotes, because it can be any device recognised as a > > “camera device” including an SD Card. > > > > Sincerely, > > > > Karim Hosein > > Top Rock Photography > > 754.999.1652 > > > > > > > > On Thu, 12 Mar 2020 at 11:14, Patrick Shanahan > wrote: > > > > > * Willy Williams [03-12-20 11:02]: > > > > Not entirely true, according to "The Fine Manual". Look on p. 11. > > > > > > > >1.3.1. Importing images > > > >To begin with darktable, you first need to import images. The > import > > > >module is in the > > > >left panel of the lighttable view (Section 2.3.1, “Import”). *You > > > >can either import from the** > > > >**filesystem or, if darktable supports your camera model, directly > > > >from camera. * > > > > > > > > > > > > > > > > On 3/12/2020 at 10:48, Patrick Shanahan wrote: > > > > > * Subhash Fotografie [03-12-20 10:41]: > > > > > > No, on Apple until DT 3.0.0 it was not possible to import from > > > cameras or SD card. Version 3.0.1 I have not tried yet. > > > > > > > > > > > > > > > > > > [August Schwerdfeger schrieb am 11.3.2020 um 19:48 Uhr:] > > > > > > > > > > > > > Darktable does support imports directly from cameras and SD > cards > > > > > > > (through the 'gphoto2' library). The Darktable preferences > under > > > the > > > > > > > "Session Options" tab let you set the patterns controlling > where > > > > > > > imported images are copied to. Section 2.3.1 of the manual [1] > > > goes into > > > > > > > detail about this. > > > > > > > -- > > > > > > > August Schwerdfeger > > > > > > > > > > > > > On Wed, Mar 11, 2020 at 7:38 PM Rod Cerkoney wrote: > > > > > > > Newbie alert, just started using this program. > > > > > > > So I finally figured out that dt does not copy files from an > SD > > > Card > > > > > > > (or camera) into a disk location. (I find this odd coming from > a > > > > > > > Lightroom environment). I must use a file manager to copy > files to > > > a > > > > > > > permanent disk location, then "import" into dt. I find that > > > awkward and > > > > > > > I'm looking for a better solution, one that is more elegant. > > > > > > >
Re: [darktable-user] Importing, How do you do it?
Patrick, In Darktable, «Import» means one of THREE things; ① to add a file which is located in DAS/NAS, to the DT database, ② to add a folder of files (and subfolders of files) which is located in DAS/NAS, to the DT database, and ③ to move files from a “camera”† to a preset DAS/NAS location, via a preset naming convention, then adding them to the DT database. All three are considered «Import»ing, all three are available through the «Import» module,and all three ought to work. As others have said, most of us use some other application to move files from SD cards or our cameras to our DAS/NAS devices, then use one of the first two import methods. (Not that anyone asked, but I use Rapid Photo Downloader). That aside, the third import method is legitimately a Darktable import method, offered by DT. To say that that is not using DT, but gPhoto, is akin to saying that one does not use DT for raw processing, but Libraw, or does not use DT for lens correction, but Lensfun, et al. DT, like most F/LOSS titles, does not re-invent the wheel, but uses third-party wheels, just as Ford, Crystler, and GM do. † I have “camera” in quotes, because it can be any device recognised as a “camera device” including an SD Card. Sincerely, Karim Hosein Top Rock Photography 754.999.1652 On Thu, 12 Mar 2020 at 11:14, Patrick Shanahan wrote: > * Willy Williams [03-12-20 11:02]: > > Not entirely true, according to "The Fine Manual". Look on p. 11. > > > >1.3.1. Importing images > >To begin with darktable, you first need to import images. The import > >module is in the > >left panel of the lighttable view (Section 2.3.1, “Import”). *You > >can either import from the** > >**filesystem or, if darktable supports your camera model, directly > >from camera. * > > > > > > > > On 3/12/2020 at 10:48, Patrick Shanahan wrote: > > > * Subhash Fotografie [03-12-20 10:41]: > > > > No, on Apple until DT 3.0.0 it was not possible to import from > cameras or SD card. Version 3.0.1 I have not tried yet. > > > > > > > > > > > > [August Schwerdfeger schrieb am 11.3.2020 um 19:48 Uhr:] > > > > > > > > > Darktable does support imports directly from cameras and SD cards > > > > > (through the 'gphoto2' library). The Darktable preferences under > the > > > > > "Session Options" tab let you set the patterns controlling where > > > > > imported images are copied to. Section 2.3.1 of the manual [1] > goes into > > > > > detail about this. > > > > > -- > > > > > August Schwerdfeger > > > > > > > > > On Wed, Mar 11, 2020 at 7:38 PM Rod Cerkoney wrote: > > > > > Newbie alert, just started using this program. > > > > > So I finally figured out that dt does not copy files from an SD > Card > > > > > (or camera) into a disk location. (I find this odd coming from a > > > > > Lightroom environment). I must use a file manager to copy files to > a > > > > > permanent disk location, then "import" into dt. I find that > awkward and > > > > > I'm looking for a better solution, one that is more elegant. > > > > > -- > > > > > Rod > > > misconception present. "importing" in dt only involves adding an > existing > > > file to the database, library.db. It does not involve moving a file > from > > > its present location to another location, ie: sd card to local disk. > > > > > > copy or move your images from camers/sd card/... to a physical drive > and > > > then import to dt. > > and that is true, BUT, "import" refers to adding to the library.db, not > moving the file from one location to another. > > "import" in dt is making dt recognize the image and nothing to do with the > filesystem except recording the physical location of the image. > > -- > (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 > > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[darktable-user] No metadata in WebP
I know that WebP is capable of metadata. I also did a really roundabout thing to get some metadata into a WebP file once, (but can't remember the sequence of things I did). Nevertheless, I cannot be manually re-adding metadata to each WebP file I create. If the Metadata is in the RAW, plus whatever I may add with Darktable, then it ought to be in the exported files which support metadata, including JPEG, PNG and WebP. Not really concerned that much with PNG, but that is also an issue. I only get metadata in JPEG files. (Then again, I rarely use it, but I never did check my OpenEXR files if they had the metadata). …And on another note, I would expect them to be in my AVIF files once you start supporting those, but one day at a time. This is really about the WebP metadata issue right now. Thanks. Ubuntu 18.04.4 (until April 2020) Darktable 3.0.0-1.1 [ download.opensuse.org ] WebP libraries 0.6.1-2 EXIF libraries 0.6.21-4 EXIV2 libraries 0.25-3.1 Sincerely, Karim Hosein Top Rock Photography 754.999.1652 darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
