Don't get hung up on the example file names I used in the email. The issue that I'm having is with the database "disabled" darktable does not recognize additional versions of images that are created (via clicking duplicate in darktable, which creates a second xmp file for the image). What's worse is when you open the folder in darktable after closing it, not only is the version you've created gone, but if you create the second version again DT immediately overwrites the second xmp file. Hopefully that makes more sense. On Sun, 2019-04-07 at 11:50 -0400, Patrick Shanahan wrote: > * Benjamin Daines <ben@digitalsand.photography> [04-07-19 11:04]: > > Importing the folder doesn't recognize versions either > > unfortunately. On Sat, 2019-04-06 at 13:54 -0400, Patrick Shanahan > > wrote: > > > * Benjamin Daines <ben@digitalsand.photography> [04-06-19 12:51]: > > > > The issue I'm running into now, with database=:memory: is that > > > > ifI'veduplicated an image so that I've got two xmp files for > > > > the sameimage(say IMG1.xmp and IMG1_01.xmp), when I close the > > > > folder andopen itagain, DT only reads the initial image, not > > > > the secondversion. If Ithen create a new version, DT > > > > immediately overwritesIMG1_01.xmp, sounless I've copied all my > > > > xmp files to asubdirectory, that work islost. It would be best > > > > to have darktableautomatically create these versionswhen seeing > > > > IMG_01.xmp.Hopefully that makes sense. On Tue, 2019-04-02 at > > > > 07:20 +0300, JuhaLintula wrote: > > > > > Hi!I also use darktable only for image processing and have > > > > > thesamesetting as Robert; database=:memory: This setting > > > > > willalwaysautomatically read the .xmp files as you are > > > > > alwaysstarting with afresh database.-JuhaOn Tue, 2 Apr 2019 > > > > > at 05:20, Patrick Shanahan <p...@opensuse.org>wrote: > > > > > > * I. Ivanov <iv3...@gmail.com> [04-01-19 20:03]: > > > > > > > On 2019-04-01 16:34, Patrick Shanahan wrote: > > > > > > > > * Benjamin Daines <ben@digitalsand.photography> [04-01- > > > > > > > > 19 > > > > > > 18:46]: > > > > > > > > > In my workflow I find myself using multiple machines > > > > > > > > > towork > > > > > > on the > > > > > > > > > same images. My configuration right now on both > > > > > > > > > machinesis > > > > > > to have DT > > > > > > > > > look for updated xmp files on start up and that seems > > > > > > > > > towork > > > > > > pretty > > > > > > > > > well. I usually just ignore the window that pops up > > > > > > > > > totell > > > > > > me about > > > > > > > > > newer xmp files, unless the ones that I'm about to > > > > > > > > > workon > > > > > > are listed, > > > > > > > > > then I select those and let it update the > > > > > > > > > database.However, there have been some situations > > > > > > > > > where myprevious > > > > > > work has > > > > > > > > > been wiped out when opening a folder on another > > > > > > > > > machine. > > > > > > Because of > > > > > > > > > this, I now habitually copy all my xmp files to > > > > > > > > > asubfolder > > > > > > after > > > > > > > > > working on them in order to keep a back up, just > > > > > > > > > incase. > > > > > > Occasionally > > > > > > > > > I need to manually load these sidecar files.Would an > > > > > > > > > option to disable darktable's database and usejust > > > > > > the xmp > > > > > > > > > files be a feasible option? How about using > > > > > > > > > somethinglike > > > > > > syncthing > > > > > > > > > (Linux platform here) to keep the database synced > > > > > > > > > between > > > > > > multiple > > > > > > > > > machines? Would doing that cause any foreseeable > > > > > > > > > issues?How are other people dealing with using > > > > > > > > > multiple machinesto > > > > > > work onprojects, any tips? > > > > > > > > when I use any machine beside my main workstation to > > > > > > > > edit > > > > > > photos, I issue > > > > > > > > darktable as: darktable --library :memory: import > > > > > > > > the photos to be edited finish the edits close > > > > > > > > dtand back at my workstation, re-import the edited > > > > > > > > photoswith > > > > > > their > > > > > > > > accompanying xmp files.have not encountered any > > > > > > > > problems with this work plan. > > > > > > > In theory... if you have 2 identical machines (for > > > > > > > examplelinux)shared network location for DT filesshared > > > > > > > network location for the DB, configuration files > > > > > > > andcachesame mounting point for the 2 machinesyou could > > > > > > > use DT on one or the other (one at a time) and the > > > > > > changes should > > > > > > > be on the 2 machines.BUT... I haven't tested the scenario > > > > > > > please back up if youwant > > > > > > to try it. > > > > > > > On the other hand - what Patrick is pointing to is based > > > > > > > on > > > > > > experience. > > > > > > > > > > > > IF, IF, IF you NEVER run dt at the same time on > > > > > > differentmachines,onecould share the db placing it on > > > > > > networked storage. BUT NEVERRUNDT ONTWO MACHINES AT THE > > > > > > SAME TIME. > > > > > > > > > > > > > > Thanks. > > > > > > try instead, to import the image instead of just reading the > > > xmpfile. Ihave not seen that happen to me and I do have > > > duplicateimages withdifferent crops. it appears your dup images > > > are not beingcreated withthe same filenames reflected by your > > > oddly number xmpfiles. but ... > > versions of what? > importing an image not in dt's db will utilize the acompanying xmp. > you have something irregular wrt your filename and accompanying xmp > files. if the filenames to the xmp files do not match, iiuc, the xmp > is notrelevant, ie: not utilized. you appear to be defeating the > very actionyou wish to utilize.
signature.asc
Description: This is a digitally signed message part
