On 23 May 2007, at 09:17, Ian Wood wrote:
Obviously this isn't a problem for images that have been 'saved as'
with the EXIF data stripped out because they will have a new valid
creation date being new files, but people do it to original files
as well (or copies if they know what's good for
Wilhelm Sanke wrote:
On Wed, 23 May 2007,Richard Gaskin [EMAIL PROTECTED] wrote:
Right now Rev uses the OS APIs to get the file info, so it's about as
efficient as it can be.
I can see the benefit of using EXIF, but since this requires additional
work and processing time, and only applies to
On Wed, 23 May 2007,Richard Gaskin [EMAIL PROTECTED] wrote:
Right now Rev uses the OS APIs to get the file info, so it's about as
efficient as it can be.
I can see the benefit of using EXIF, but since this requires additional
work and processing time, and only applies to a subset of a very
On 22 May 2007, at 23:30, Wilhelm Sanke wrote:
These are indeed valid arguments that have to be considered .
As far as I know, however, the situation may be at least different
for Windows and MacOS. I do not know if the OSX finder could access
EXIF data automatically, but WindowsXP surely
On 23 May 2007, at 09:17, Ian Wood wrote:
Obviously this isn't a problem for images that have been 'saved as'
with the EXIF data stripped out because they will have a new valid
creation date being new files, but people do it to original files
as well (or copies if they know what's good
On 23 May 2007, at 09:17, Ian Wood wrote:
Obviously this isn't a problem for images that have been 'saved as'
with the EXIF data stripped out because they will have a new valid
creation date being new files, but people do it to original files
as well (or copies if they know what's good
Wilhelm Sanke wrote:
The best alternative would be to have a choice: There are even tools
that allow you to save the EXIF data before editing and then add them
again after the image has been changed, like Exifer for Windows.-
Another remark concerning my request to add the EXIF creation date
I am not intending to continue this thread endlessly, but I think the
last contributions and questions of Ian Wood and Jacqueline deserve
another response.
I had written:
When a photo is taken, it gets a modification date at the same time,
although it is - as it were - only modified out of
Wilhelm Sanke wrote:
I repeat my recommendation to add the ability to read EXIF data with the
detailed files function:
I don't know if I'd like that. To read the EXIF data, every file would
have to be opened and read individually, which would be very
time-consuming. As it is now, a single
On 5/22/07 2:09 PM, J. Landman Gay [EMAIL PROTECTED] wrote:
Wilhelm Sanke wrote:
I repeat my recommendation to add the ability to read EXIF data with the
detailed files function:
I don't know if I'd like that. To read the EXIF data, every file would
have to be opened and read
I repeat my recommendation to add the ability to read EXIF data with
the detailed files function:
EXIFdata seem to be really reliable data, survive most transfer
procedures, and spare you the trouble to remember in which way you
have transferred image files from one volume or folder to another
Jacqueline Landman Gay wrote:
Wilhelm Sanke wrote:
I repeat my recommendation to add the ability to read EXIF data with
the
detailed files function:
I don't know if I'd like that. To read the EXIF data, every file would
have to be opened and read individually, which would be very
On 5/22/07 3:30 PM, Wilhelm Sanke [EMAIL PROTECTED] wrote:
As far as I know, however, the situation may be at least different for
Windows and MacOS. I do not know if the OSX finder could access EXIF
data automatically, but WindowsXP surely does.
A glimpse of why cross-platform can be
Robert Brenstein rjb at robelko.com wrote:
I am not sure why you would want an operating system to look into the
file content to fetch a date. After all, EXIF data is file content. I
think that detailed files reports correctly file data as seen by the
operating system.
Robert
Robert,
one
The term creation date is misleading here, because what the
detailed files retrieves is basically different from the real
creation date of a camera image. Only in some cases is the
detailed-files creation date identical with the creation date of the
photo.
Regards,
Wilhelm Sanke
I can see
Could the 2038 date be set on the camera? By mistake of course...
Cheers,
Luis.
On 22 May 2007, at 21:44, Wilhelm Sanke wrote:
I am not intending to continue this thread endlessly, but I think
the last contributions and questions of Ian Wood and Jacqueline
deserve another response.
I
Ran the script here, on Mac 10.4.9, Rev 2.8.1 - all detailed files
info matched the finder
Best,
Mark
On 21 May 2007, at 03:04, J. Landman Gay wrote:
Wilhelm Sanke wrote:
The results I get here using your script are exactly the same as
with my slightly different script
I think we
Improved version of the modification date handler in Rev.
This version will parse and deliver the dates and times in separate columns
to make it easier to do comparisons. That's all the time I have for now, so
hopefully this will help soomeone track what's happening
replace the previous
Mark Smith wrote:
Ran the script here, on Mac 10.4.9, Rev 2.8.1 - all detailed files info
matched the finder
Thanks for checking, Mark. It's puzzling why we're getting different
results than Wilhelm. Any XP users who feel like running the script?
Here it is again:
on mouseUp
answer
First a word of thanks to Jacqueline and Jim Ault for their patience
with which they try to help finding out what is going on behind the scenes.
I think I know now where Rev is looking for date information with the
detailed files on WindowsXP.
There are fours kinds of date data with image
J. Landman Gay wrote:
Mark Smith wrote:
Ran the script here, on Mac 10.4.9, Rev 2.8.1 - all detailed files
info matched the finder
Thanks for checking, Mark. It's puzzling why we're getting different
results than Wilhelm. Any XP users who feel like running the script?
Here it is again:
On 21 May 2007, at 20:00, Wilhelm Sanke wrote:
When a photo is taken, it gets a modification date at the same
time, although it is - as it were - only modified out of non-
existence.
The creation date is generated when the image arrives on the
computer, and a new creation date is generated
Martin Baxter wrote:
The dates are OK, although the result does deviate from what the docs
tell you to expect in that items 3 and 11 (unsupported on windows) are
supposed to therefore contain zero, according to the docs, in the same
way as items 7,8,9. But are in fact empty. Unlikely to
Wilhelm Sanke wrote:
When a photo is taken, it gets a modification date at the same time,
although it is - as it were - only modified out of non-existence.
The creation date is generated when the image arrives on the computer,
and a new creation date is generated each time the image is saved
Wilhelm Sanke wrote:
But this does not explain the phantastic date of Jan 18, 2038 which
I got for the creation date - item four of the detailed files - when I
transferred files to my Powerbook with an USB stick.--
Oops, forgot to address this point. It would be interesting to see what
the
Ian Wood, revlist at azurevision.co.uk wrote:
The creation date is generated when the image arrives on the
computer, and a new creation date is generated each time the image
is saved or copied. Simply moving an image to another folder does
*not* change the creation date.
FWIW, that's
On Sat, 19 May 2007, J. Landman Gay [EMAIL PROTECTED] wrote:
I think Rev just makes a call to the OS to get the info. If the detailed
file info matches the Finder (or the info in Windows Explorer) then I
think the behavior is correct. Rev doesn't actually read any of the
files itself, it just
Wilhelm Sanke wrote:
The detailed-files function of Rev appears to be extremely buggy, and
the Rev team should take a close look both at the function itself and
the corresponding information in the docs.
I can't reproduce any problems with it at all. Here is a test I did.
Create a stack
J. Landman Gay jacque at hyperactivesw.com wrote today:
Wilhelm Sanke wrote:
The detailed-files function of Rev appears to be extremely buggy, and
the Rev team should take a close look both at the function itself and
the corresponding information in the docs.
I can't reproduce any problems
Wilhelm Sanke wrote:
The results I get here using your script are exactly the same as with my
slightly different script
I think we need to find out why we're getting different results. A
search in bugzilla gives two related bugs, both now fixed:
4293 The detailed files doesn't return
I have little experience with virus systems or other defenses against
macros, but could it be possible that files may be 'quarantined' or marked
or symbolized in such a way that a security system might interfere with file
info?
Wilhelm: if you run an Applescript that gets the same info during the
Jim Ault wrote:
I have little experience with virus systems or other defenses against
macros, but could it be possible that files may be 'quarantined' or marked
or symbolized in such a way that a security system might interfere with file
info?
Wilhelm: if you run an Applescript that gets the
On Fri, 18 May 2007, J. Landman Gay [EMAIL PROTECTED] wrote:
Wilhelm Sanke wrote:
While trying to add the creation date to the filename in a thumbs
application I noticed that the creation date is actually item 5 of the
detailed files rather than item 4, number 4 really containing the
Wilhelm Sanke wrote:
snip
with item 5 of the detailed files
image M: May 19, and for image O: March 4.
This is correct, yes?
With item 4 of the detailed files I get March 15 for both images,
which is apparently the date I transferred the images from my camera to
the computer, a value
J. Landman Gay [EMAIL PROTECTED] wrote:
Here is the script snippet I use to append the creation date to the
image name field under the thumb:
put item 5 of line i of tdetfiles into Datum
convert Datum from dateitems to long date
put Tabitem 2 to 3 of Datum after fld Feld
Wilhelm Sanke wrote:
With from seconds to long date I get the same results as with
dateitems, namely March 15 for item 4 of the detailed files - which is
the transfer date, i.e. *not* the creation date that is part of the
EXIF information.
I think Rev just makes a call to the OS to get the
The docs contain the following information about the detailed files:
The detailed files form returns a list of files, one file per line.
Each line contains the following attributes, separated by commas:
* The file's name, URL-encoded
* The file's size in bytes (on Mac OS and OS X
Wilhelm Sanke wrote:
While trying to add the creation date to the filename in a thumbs
application I noticed that the creation date is actually item 5 of the
detailed files rather than item 4, number 4 really containing the
modification date.
Since the detailed files was introduced in Rev
38 matches
Mail list logo
