as expected, when images are scanned from negs or from slides -- or from prints -- the EXIF data doesn't include the date taken

you can go back with the program jhead -- and set the date/time -- to whatever you think is a good guess -- BUT: Shotwell doesn't always accept the file date and insists on going by some other date

you would think you could just define a new event and merge the badly filed images into whatever event they belong in, -- but NO. Shotwell puts them under some sort of date it comes up with from someplace.

the JHEAD program offers various tools for correcting dates

the scanner creates only minimal exif data: just the sRGB setting. Perhaps if I delete all the existing exif entries and the re-create them I can get them setup right.

any notes from experience with this will be appreciated !!

I suspect this issue has to do with their database

if i remove the entire set -- 75 images from the /Pictures library -- then their "Event" -- disappears -- as it should.

However: even if I completely clean up all 75 images in this set: setting the file date using touch and the metadata using jhead -- and even verifying that the images are all dated properly -- and contain proper metadata -- which can be verified using gThumb --

Still: when I reload the set in question: 12 of the images -- always the same 12 -- are posted to the WRONG DATE (today ) rather than the Aug. 2003 date this is correct for these.

And: Shotwell will not allow this to be corrected.

I think the issue is in their database: when I remove the images from the /pictures directory -- Shotwell should delete all of the related entries from their database. it appears they do not; instead they use the old DB entries to address the 12 images in question on report them under the wrong date.

there should be an option to DELETE DB REFERENCES

has anyone -- perhaps -- discovered a circumvention or a work-around for this ??

work around

after scanning images for an event:

1. using touch with the -t switch set the date time on all the images in the scanner working set

2. using jhead with the -mkexif switch add exif data to all the images in the scanner working set

3. move the scanner working set into Shotwell's pickup area

this works for new material but will not correct erroroneous entries in the shotwell db.

1 members found this post helpful.

That's pretty ugly. I'm in a similar situation, finally digitizing (some of) my old photos/negs/slides. As it happens I have merely scanned them up and haven't bothered with a management tool yet as I still have heaps to do. I was planning on fixing the date in the EXIF and probably the file date as well, but might have stumbled on that as you did.
Thanks for the heads-up.

the thing that is UGLY is that Shotwell will not allow me to make the corrections I want to make. My guess is that even though I remove a set of images from the /Pictures directory -- Shotwell does not drop the ID data from its database. as a result: when I reload the corrected set -- Shotwell ignores the correction and put the set back where it had it -- which is the wrong location.

I don't know what Shotwell generates for an image identifier. But, whatever it is -- they invariably put the corrected images back into the wrong event when i reload them

interestingly the SCANNER (Epson V500) assigns a 6-character name to each scanned image, format IMG000.jpg to IMG999.jpg
it would be easy enough to rename them en mass and maybe I should. what I've been doing is just keeping them in sets with each set in its own sub-directory

the program I'd like to use is ACDSEE; sadly that's for Windows or Mac. the ACDSEE does run in Virtualbox.

That's what I meant.

cool

I just kinda made a mental fix out of this problem: I use Shotwell for managing uploads to Flickr ;gThumb for managing my photo library

it's an interesting topic, and one which really comes in several pieces: library management, photo editing, and publishing. It's not at all clear that there is one tool that "does it all" -- we may be at the old "do one thing and do it well" point on this.