Re: [darktable-dev] Problems trying to install build of release-3.7.0-1493-g4a7774f95
Hello Patrick, On Sun, 2021-11-14 at 23:43 -0500, Patrick Shanahan wrote: > * Terry Duell [11-14-21 23:35]: > > Hello All, > > I have just completed a Fedora 34 rpm build of darktable release-3.7.0-1493- > > g4a7774f95, which completed without any errors, but when I attempted to > > install > > I got the message 'nothing provides libraw.so.22', which followed on from a > > check of all the normal Fedora repos. > > So the indications are that this version of darktable depends on > > libraw.so.22, > > but that version doesn't seem to be available. > > Can anyone provide advice on what might be needed to build and/or install? > > build the executables when you compile rather than making an rpm to > install. The rpm fails for me on openSUSE Tumbleweed also missing > libraw22, but the executables from the compile/build are functional. > > libraw22 will appear but apparently not yet > OK, thanks for your advice. I only build and install rpms, so I'll have to wait. Cheers, -- Terry Duell ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Problems trying to install build of release-3.7.0-1493-g4a7774f95
* Terry Duell [11-14-21 23:35]: > Hello All, > I have just completed a Fedora 34 rpm build of darktable release-3.7.0-1493- > g4a7774f95, which completed without any errors, but when I attempted to > install > I got the message 'nothing provides libraw.so.22', which followed on from a > check of all the normal Fedora repos. > So the indications are that this version of darktable depends on libraw.so.22, > but that version doesn't seem to be available. > Can anyone provide advice on what might be needed to build and/or install? build the executables when you compile rather than making an rpm to install. The rpm fails for me on openSUSE Tumbleweed also missing libraw22, but the executables from the compile/build are functional. libraw22 will appear but apparently not yet -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode What sort of day was it? A day like all days, filled with those events that alter and illuminate our times... all things are as they were then, but were you there? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] Problems trying to install build of release-3.7.0-1493-g4a7774f95
Hello All, I have just completed a Fedora 34 rpm build of darktable release-3.7.0-1493- g4a7774f95, which completed without any errors, but when I attempted to install I got the message 'nothing provides libraw.so.22', which followed on from a check of all the normal Fedora repos. So the indications are that this version of darktable depends on libraw.so.22, but that version doesn't seem to be available. Can anyone provide advice on what might be needed to build and/or install? Cheers, -- Terry Duell ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Geotagging module not working with dates < 1970-01-01
* Mark Feit [11-14-21 15:44]: > On 11/14/21 8:22 AM, Patrick Shanahan wrote: > > but *you* are doing what you believe darktable should never do, altering > > the original raw file. exiftool changing the DateTimeOriginal *is* > > altering the original raw file and may cause you lose of data by altering > > the original. > > > That's the user's doing, and if they're doing it, they know they're doing > it. Lettubg darktable do it violates the principle of least astonishment. > > The user has the option of taking steps to preserve the "original original" > if they want to. I have absolutely no argument with him altering his raw files, only that he believes he is doing no harm. He is free to delete them. but he surely cannot believe that he is not altering the raw file. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode What sort of day was it? A day like all days, filled with those events that alter and illuminate our times... all things are as they were then, but were you there? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
[darktable-dev] CR3 support integrated
Just a quick note about the recent integration of the CR3 support in darktable. Be sure to update the submodules after next git pull to ensure the LibRaw sub-module is properly populated. $ git submodule init $ git submodule update Best, -- 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 developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Geotagging module not working with dates < 1970-01-01
Actually I think this is a matter of belief and to have a consistent argument. I would like to have a way to correct the exif information but sure thing this modified the original data. Since writing exif is writing to the file it's a violation of the rules to never write to the raw file. If you wrote the exif then you could also write something else because you already write, so where is the difference - might be an upcoming argument for a new feature request and so step by step room would emerge for features that alter the original file. I mean yeah, changing the file might break the format of the file as specified by the manufacturer. It might lead to data loss. It might just work. It might look like it just works but something is broken that you cannot easily detect and find out painfully eventually. Because afaik the raw formats are more implemented by reverse engineering than implementing a full standard I agree that following the religious 'never write to the raw file' is the correct way to deal with it but in my heart I am wishing for a feature that modifies the exif information permanently (and so writes to the raw). Peter Harde schrieb am So., 14. Nov. 2021, 14:42: > exiftool changing the DateTimeOriginal *is* > altering the original raw file and may cause you lose of data by altering > the original. > > Changing a parameter which is definitely wrong is not a loss of data but a > correction. exiftool preserves the original file by adding "_original" to > the file name. No danger of loss of data until the new file, created by > exiftool, has been validated. > > ___ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Geotagging module not working with dates < 1970-01-01
* Peter Harde [11-14-21 08:44]: > > exiftool changing the DateTimeOriginal *is* > > altering the original raw file and may cause you lose of data by altering > > the original. > Changing a parameter which is definitely wrong is not a loss of data but a > correction. exiftool preserves the original file by adding "|_original|" to > the file name. No danger of loss of data until the new file, created by > exiftool, has been validated. validated ??? only the camera vendor can do that as no one else has access to their proprietary software. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode What sort of day was it? A day like all days, filled with those events that alter and illuminate our times... all things are as they were then, but were you there? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Geotagging module not working with dates < 1970-01-01
exiftool changing the DateTimeOriginal *is* altering the original raw file and may cause you lose of data by altering the original. Changing a parameter which is definitely wrong is not a loss of data but a correction. exiftool preserves the original file by adding "|_original|" to the file name. No danger of loss of data until the new file, created by exiftool, has been validated. ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] Geotagging module not working with dates < 1970-01-01
* Peter Harde [11-14-21 02:00]: > Am 13.11.21 um 21:34 schrieb Coding Dave: > > darktable will never change the raw file but you might want to change > > the date taken exif information. > I absolutely agree, darktable should never change the raw file. That's the > reason why I use exiftool to rough adjust "DateTimeOriginal" of the raw > files to the day the original (analog) image was taken *before* importing > into darktable. > > So you might spend huge amount of work with darktable to correct the > > exif data and expect this to have a permanent effect. Now imagine you > > open the raw data with another program, then your tuning of date taken > > exif information does not show up. So it looks like you've lost the > > work. > I'm aware of this situation. > > You will realize that you might have intended to change the exif in the > > image, not the sidecar information. > That's exactly what I'm doing (see above). Where it is reasonable darktable > is used only to fine tune the *time* information of "DateTimeOriginal". but *you* are doing what you believe darktable should never do, altering the original raw file. exiftool changing the DateTimeOriginal *is* altering the original raw file and may cause you lose of data by altering the original. I adjust the filename to reflect DateTimeOriginal. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode What sort of day was it? A day like all days, filled with those events that alter and illuminate our times... all things are as they were then, but were you there? ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org