I have posted this on pixls.us now it is back up.
Dusenberg
On 26/07/2023 20:39, Dusenberg wrote:
Guillermo
Since my last post, I have extracted data from the dt db image table
for the image and versions concerned from three backup instances of
the dt database going back 3 years:
a) 2020-12-14 - pre-dt3.4.0, closest I can get to the original
shot date
b) 2023-07-22 - dt4.2.1, before new duplicate created
c) 2023-07-24 - dt4.2.1, after new duplicate created showing
duplicate version '****'
Hope this sheds more light on the issue.
pre-dt3.4.0-library.db from backup archive 2020-12-14
------------------------------------------------------
select key, value from db_info;
key value
version 30
select id, group_id, film_id,filename,version,max_version from images
where filename = "20200325_BonallyWoods_NIK_1413.NEF" order by id;
id group_id film_id filename version max_version
3574 3574 135 20200325_BonallyWoods_NIK_1413.NEF 0 7
3578 3574 135 20200325_BonallyWoods_NIK_1413.NEF 1 7
3582 3574 135 20200325_BonallyWoods_NIK_1413.NEF 2 7
3583 3574 135 20200325_BonallyWoods_NIK_1413.NEF 3 7
3789 3574 135 20200325_BonallyWoods_NIK_1413.NEF 4 7
3790 3574 135 20200325_BonallyWoods_NIK_1413.NEF 5 7
3791 3574 135 20200325_BonallyWoods_NIK_1413.NEF 6 7
3792 3574 135 20200325_BonallyWoods_NIK_1413.NEF 7 7
library.db-snp-20230722155434 from backup archive BEFORE new duplicate
created
------------------------------------------------------------------------------
select key, value from db_info;
key value
version 37
select id, group_id, film_id,filename,version,max_version from images
where filename = "20200325_BonallyWoods_NIK_1413.NEF" order by id;
id group_id film_id filename version max_version
3574 3574 135 20200325_BonallyWoods_NIK_1413.NEF 0 7
3578 3574 135 20200325_BonallyWoods_NIK_1413.NEF 1 7
3582 3574 135 20200325_BonallyWoods_NIK_1413.NEF 2 7
3583 3574 135 20200325_BonallyWoods_NIK_1413.NEF 3 7
3789 3574 135 20200325_BonallyWoods_NIK_1413.NEF 4 7
3790 3574 135 20200325_BonallyWoods_NIK_1413.NEF 5 7
3791 3574 135 20200325_BonallyWoods_NIK_1413.NEF 6 7
3792 3574 135 20200325_BonallyWoods_NIK_1413.NEF 7 7
library.db-snp-20230724163328 from current backup AFTER new duplicate
created
-------------------------------------------------------------------------------
select key, value from db_info;
key value
version 37
select id, group_id, film_id,filename,version,max_version from images
where filename = "20200325_BonallyWoods_NIK_1413.NEF" order by id;
id group_id film_id filename version max_version
3574 3574 135 20200325_BonallyWoods_NIK_1413.NEF 0 0
3578 3574 135 20200325_BonallyWoods_NIK_1413.NEF 1 3
3582 3574 135 20200325_BonallyWoods_NIK_1413.NEF 2 3
3583 3574 135 20200325_BonallyWoods_NIK_1413.NEF 3 3
****duplicate
3789 3574 135 20200325_BonallyWoods_NIK_1413.NEF 4 3
3790 3574 135 20200325_BonallyWoods_NIK_1413.NEF 5 3
3791 3574 135 20200325_BonallyWoods_NIK_1413.NEF 6 3
3792 3574 135 20200325_BonallyWoods_NIK_1413.NEF 7 3
9744 3574 135 20200325_BonallyWoods_NIK_1413.NEF 3 3
****duplicate
The dt database has an index, "images_filename_index" ON "images" (
"filename", "version" ); which means that a 'duplicate' is related to
a particular image filename. There are two implications from this
which may be relevant to the issue I raised:
a) The index is is not unique, it allows duplicates. Therefore the
database allows (and cannot trap) insertion of a new image table row
with a version number that already exists for the given filename
value. The fact I have a duplicate version for a filename suggests the
dt code also does not trap this.
b) This index assumes filenames are unique across the whole dt
database, which probably is not realistic given how cameras from the
same manufacturer can generate common filenames.
While a unique id is given to each imported image by the dt db to
ensure images with the same filename are permitted and can be handled,
it seems the 'duplicate image' functionality does not recognise this
potential.
Regards
Dusenberg
On 26/07/2023 09:59, Dusenberg wrote:
Guillermo,
Answers to your questions:
a) xmp's are named '<project
name>_<camerafilename>_<$VERSION>.RAWextension.xmp'
eg:
original raw: '20200325_BonallyWoods_NIK_1413.NEF'
version 3 xmp: '20200325_BonallyWoods_NIK_1413_03.NEF.xmp'
b) I've checked the files and the new duplicate '3' has overwritten
the existing xmp for the previous version 3. Also all xmp files in
that group new have new modified dates - 24 July 2023, when I
created the new duplicate
Also I didn't mention that the NIK_1413 RAW and duplicates are in a
single group.
Thanks for your time.
Dusenberg
On 26/07/2023 03:41, Guillermo Rozas wrote:
That sounds strange. How are the xmp files named? If the duplicate
uses a previously used version number, does it also overwrites the
corresponding xmp sidecar?
Regards,
Guillermo
On Tue, Jul 25, 2023 at 1:06 PM Dusenberg <dusenb...@gmx.co.uk> wrote:
Hi Guillermo
Yes the original and all duplicates were in the database before
making the new duplicate.
Regards
Dusenberg
On 25/07/2023 15:03, Guillermo Rozas wrote:
Hi,
were the original and all the duplicates present in the
database before making the duplicate?
Regards,
Guillermo
On Tue, Jul 25, 2023 at 5:57 AM Dusenberg <dusenb...@gmx.co.uk>
wrote:
Originally posted to darktable-dev list in error.
dt 4.2.1 (OBS), Linux Mint 21,Ubuntu 22.04 jammy
I have an image from March 2020 developed in darktable. I
went back to it today to try another edit on it (its a
monochrome rendition that I just can't get 'right').
However, today when I created a duplicate of this 2020
image in dt 4.2.1, it was given version number '3' - which
already exists for that image (there are seven pre-existing
duplicates). I see that dt has also given the new duplicate
a different 'image id' to the original RAW image. I've
never seen this before, although its not often I go back in
time like this.
My workflow is that I always create a new version
(duplicate) of the base RAW for a different edit so I can
trace back any final output that may result. My filenaming
system is '<filename>_<version number>_<colorspace>_<max
size>' where filename is composed of
'<YYYYMMDD_projectname_original camera filename>'.
Original camera images are renamed during download onto my
workstation via a bespoke script (ie outside dt). I use
variables in the dt export module to ensure any output
follows this format. This provides unique identification
of every image and its derivatives across my libraries,
even when intermediate tiffs are involved in say, focus
stacks.
This is critical for me - I can't have two different edits
of a RAW with the same filename! Why has it happened and
what can I do about it?
Thanks
____________________________________________________________________________
darktable user mailing list to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org
<mailto:darktable-user%2bunsubscr...@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
<mailto:darktable-user%2bunsubscr...@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
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
