Date selection uses "a bad exif date" instead of "Date and Time (original)"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Select a photo which has been edited recently for example using jBrout's
thumbnail refresh ;-)
2. right-click "Select this period"

What is the expected output? What do you see instead?
I expected to have all the pictures which were taken at the same time.
Instead I have all the pictures which were modified at the same time.

Original issue reported on code.google.com by davito...@gmail.com on 8 Jan 2009 at 4:10

[GoogleCodeExporter]

Sorry, forgot again: WinXP Sp3, jBrout 0.3.145

Original comment by davito...@gmail.com on 8 Jan 2009 at 4:11

[GoogleCodeExporter]

?!?
It works well with the linux version ...
can't reproduce it under windows, til the package don't work on my box ...
It should work on windows too ... are you really sure ?!?

(I will remove you from admin site ...)

Original comment by manat...@gmail.com on 8 Jan 2009 at 4:34

[GoogleCodeExporter]

Sorry, wrong, it is not jBrout who changed the file date. The file date was
10/01/2008. We are in 2009, dummy!!!

I pick another picture: 0160_img.jpg. in the meta-data window, jBrout says: 
"Date and
Time"=2008-01-06 14:12:41, "Date and Time (original)"=2002-07-23 14:38:21, same 
for
Date and Time (digitized)".

I check in the file system (Window's file properties dialog): created on 
2008-07-04,
modified on 2002-07-23, last access 2009-01-08. Actually these dates make sense 
since
this is a new disk, so the creation date can be more recent than the 
modification date.

But I have absolutely no idea where jBrout found 2008-01-06... Ok found it: 
using
PhotoME, I discovered this date is stored somewhere in the jpeg file, in a place
PhotoME calls "File change date and time" and XnView calls "Date de 
modification" (I
suppose english-speaking readers will be able to guess the translation :-) ).

I bet jBrout uses the wrong date...

Original comment by davito...@gmail.com on 8 Jan 2009 at 4:58

[GoogleCodeExporter]

Easier with the picture :-)

Original comment by davito...@gmail.com on 8 Jan 2009 at 5:13

Attachments:

• 0160_IMG.JPG

[GoogleCodeExporter]

BTW, this means this should be reproducible under GNU/Linux

Original comment by davito...@gmail.com on 8 Jan 2009 at 5:28

[GoogleCodeExporter]

effectivly ...
On this picture "Date and Time" differs from "Date and Time (original)" ...
only you know, is a picture taken in 2002 or in 2006 ????

Original comment by manat...@gmail.com on 8 Jan 2009 at 6:04

[GoogleCodeExporter]

rename bug title

Original comment by manat...@gmail.com on 8 Jan 2009 at 6:05

• Changed title: Date selection uses "a bad exif date" instead of "Date and Time (original)"

[GoogleCodeExporter]

2002. The few times I checked, (original) and (digitized) were equal to each 
other
and both meant the time the picture was taken. Frankly, since this is the only 
date
which matters to me (except for the file date but I don't need EXIF for this!) I
never bothered to investigate other dates. You should be able to check that 
each time
you have a Date and Time (original) and a Date and Time and they are different, 
Date
and Time (original) is the earliest.

Of course, if Date and Time (original) is missing, you can fall back on Date 
and Time
(digitized) (but in that case it should be missing too) and if both are missing
jBrout has no other solution than to fall back to the Date and Time it 
currently uses.

Original comment by davito...@gmail.com on 8 Jan 2009 at 6:32

[GoogleCodeExporter]

Fixed in rev 147

In jbrout0.2 this trouble couldn't exists, because all this kind of jobs was 
done by
jhead ...
Since 0.3, all is done in python. I used "Exif.Image.DateTime" as reference (in 
rev
<147), but it seems that the real reference is "Exif.Photo.DateTimeOriginal" (it
seems to be the original date in jhead, exiv2, eog ...). so jBrout use now
"Exif.Photo.DateTimeOriginal".

It's not a real big problem ... in 99% of the time, they are always the same. 
But if
they differ, and you change the date with jbrout, you could loose the original 
time
defenitivly (jbrout save the same date in Exif.Image.DateTime,
Exif.Photo.DateTimeOriginal and Exif.Photo.DateTimeDigitized)

like always, refreshing folders can correct all troubles (by updating xml/db 
with the
real good date !)

Original comment by manat...@gmail.com on 8 Jan 2009 at 7:50

• Changed state: Fixed

[GoogleCodeExporter]

Obviously, not all tools change Exif.Image.DateTime, but it seems I once used 
such a
tool. When I ask jBrout which photos were taken on that day, he brings me 1460
pictures! So I suppose that day I used something which changed this date in 
about 10%
of my pictures, and I never used that tool again. I don't remember what I did 
that
day (one year ago) and the disk on which this happened has gone to maintenance 
since,
so...

Original comment by davito...@gmail.com on 8 Jan 2009 at 8:22

[GoogleCodeExporter]

Now also fixed for Download plugin in r150

Original comment by r...@wallace.gen.nz on 9 Jan 2009 at 12:39