Re: [darktable-dev] Problems trying to install build of release-3.7.0-1493-g4a7774f95

2021-11-14 Thread Terry Duell
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

2021-11-14 Thread Patrick Shanahan
* 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

2021-11-14 Thread Terry Duell
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

2021-11-14 Thread Patrick Shanahan
* 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

2021-11-14 Thread Pascal Obry


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

2021-11-14 Thread Coding Dave
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

2021-11-14 Thread Patrick Shanahan
* 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

2021-11-14 Thread Peter Harde

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

2021-11-14 Thread Patrick Shanahan
* 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