Re: *istD creation/modification dates
On 17/3/05, Herb Chong, discombobulated, unleashed: EXIF explicitly says it adheres to FAT16 and FAT32. whether you like the spec or not, it is the spec, and all Windows computers get it right... right up Gates' ass. Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
- Original Message - From: John Francis Subject: Re: *istD creation/modification dates Arguing about what it is called doesn't change the fact that there's a problem somewhere in the Mac software. OH MY GAWD! WW I.will.resist... Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
Give into temptation :-) Dave S On Thu, 17 Mar 2005 08:58:51 +, Cotty [EMAIL PROTECTED] wrote: - Original Message - From: John Francis Subject: Re: *istD creation/modification dates Arguing about what it is called doesn't change the fact that there's a problem somewhere in the Mac software. OH MY GAWD! WW I.will.resist... Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
On Mar 16, 2005, at 3:39 PM, John Francis wrote: Call it what you will. Names are important. There's something on a Mac that lets you bring up a window on a folder, and which shows you the files in that folder, together with showing you various file attributes (which, in the case we are discussing, include creation dates). You don't seem to understand how Mac OS X operates. You shouldn't pose as an expert on it if you don't care about the names of things or the collaboration of independent components. If it shows a date of 31 Dec 1903 for files on a CF card written in a digital camera, it's broken code, because it isn't implementing FAT correctly. Arguing about what it is called doesn't change the fact that there's a problem somewhere in the Mac software. The Finder's list views inconsistent with its Inspector views, but the problem is not really in the Finder. It's in the underlying routines used to pull the creation date from FAT file systems, which are UNIX utility components. However, this optional field should be properly filled in by the camera in the FAT volume when it writes the data. I repeat, it's stupid to make the Created date an optional field. If you use any of the utility applications to transfer your files from FAT to a Mac OS volume (like iView Media Pro, Image Capture, etc), they properly populate the Created date with the Modified date as reported by the underlying utility. For the instance of an image file on an SD or CF card, this is perfectly valid. Godfrey
Re: *istD creation/modification dates
On Mar 16, 2005, at 3:53 PM, John Francis wrote: Godfrey DiGiorgi mused: However, when you're looking at a list view and want to see Created and Modified dates, It's exactly the opposite way around from what you state. The Finder calls the UNIX routines which do not handle the lack of a creation date correctly ... They just report whatever happens to be in the appropriate number of bytes at the appropriate offset and return that. Which will be the Created date - it will just have a value of 0. The field is always present. A numeric value of '0' is not a date/time numeric, and translates inconsistently. Who converts dates from the DOS Epoch to the Mac epoch? The OS, or the Finder? What the fuck is a DOS Epoch? or a Mac epoch? The date/time conversion routines, which are part of the UNIX service component infrastructure that the Finder calls when retrieving values from the file management software in the OS, is responsible for converting date/time numeric values to Date/Time string values. A zero quantity as a Date/Time numeric value translates to a constant, incorrect value. There's nothing broken but the fact that it's stupid for this to be an optional field in the FAT format definition, and that Pentax should populate this optional field properly. No matter how you special case it, 0 in the Created date cannot mean the same thing as a valid number in the Modified date. It's a decision as to how to implement the interpretation of 0 for this field value ... I suspect they simply chose to interpret it literally as other options are even less consistent. Godfrey
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: On Mar 16, 2005, at 3:39 PM, John Francis wrote: Call it what you will. Names are important. There's something on a Mac that lets you bring up a window on a folder, and which shows you the files in that folder, together with showing you various file attributes (which, in the case we are discussing, include creation dates). You don't seem to understand how Mac OS X operates. You shouldn't pose as an expert on it if you don't care about the names of things or the collaboration of independent components. I'm not posing as an expert. But I can see when they are screwing up. Anyway, I thought the whole point of the Mac was that you didn't need to be an expert on the things to use them. And that still doesn't negate my point you quote below. If it shows a date of 31 Dec 1903 for files on a CF card written in a digital camera, it's broken code, because it isn't implementing FAT correctly. Arguing about what it is called doesn't change the fact that there's a problem somewhere in the Mac software. The Finder's list views inconsistent with its Inspector views, but the problem is not really in the Finder. It's in the underlying routines used to pull the creation date from FAT file systems, which are UNIX utility components. However, this optional field should be properly filled in by the camera in the FAT volume when it writes the data. I repeat, it's stupid to make the Created date an optional field. Repeat it as much as you like - it's still a fact that zero is a perfectly well-defined value for the Created date on a FAT filesystem, and that the Mac (viewed as a whole) doesn't handle this case well. Just because you call it stupid doesn't alter the FAT specifications. Either you support FAT, or you don't. The Mac apparently doesn't. Despite what some experts might tell you, the Mac isn't just pulling a random value left around (whatever happens to be at that offset) out of the FAT directory data; it's retrieving a zero value that was explicitly put there, in compliance with the FAT specifications, when the file was created.
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: On Mar 16, 2005, at 3:53 PM, John Francis wrote: Which will be the Created date - it will just have a value of 0. The field is always present. A numeric value of '0' is not a date/time numeric, and translates inconsistently. A numeric value of 0 is every bit as much of a date/time numeric of 5237, or 43702, or any other value you choose to put in that field. Who converts dates from the DOS Epoch to the Mac epoch? The OS, or the Finder? What the fuck is a DOS Epoch? or a Mac epoch? The epoch is the start date for the numbering scheme. It's different for different operating systems (and the Mac, apparently, chose a different base date from regular Unix; that must create some problems). There's nothing broken but the fact that it's stupid for this to be an optional field That's an opinion. It might even be true. But the fact remains that the FAT specifications explicitly permit putting zero in this field. in the FAT format definition, and that Pentax should populate this optional field properly. No matter how you special case it, 0 in the Created date cannot mean the same thing as a valid number in the Modified date. It's a decision as to how to implement the interpretation of 0 for this field value ... I suspect they simply chose to interpret it literally as other options are even less consistent. If they choose to interpret it literally, then it should be the date that would correspond to day zero in the DOS epoch. But it isn't. Instead, we get the date that corresponds to day zero (or day -1?) in the Mac epoch. So for every other numeric value, the dates are correctly offset by the (approximately 76 years) difference between the two epochs. If consistency was the goal, you'd expect zero to be treated the same way, and the files would show up with a date of 31 Dec 1979, or something like that.
Re: *istD creation/modification dates
On Mar 17, 2005, at 10:46 AM, John Francis wrote: Repeat it as much as you like - it's still a fact that zero is a perfectly well-defined value for the Created date on a FAT filesystem, and that the Mac (viewed as a whole) doesn't handle this case well. Just because you call it stupid doesn't alter the FAT specifications. Either you support FAT, or you don't. The Mac apparently doesn't. Despite what some experts might tell you, the Mac isn't just pulling a random value left around (whatever happens to be at that offset) out of the FAT directory data; it's retrieving a zero value that was explicitly put there, in compliance with the FAT specifications, when the file was created. And translating it to the constant that it means. Any other translation would be a guess. It's not a bug in the Mac, it's a stupid oversight in the FAT specification. Godfrey
Re: *istD creation/modification dates
On Mar 17, 2005, at 11:06 AM, John Francis wrote: If they choose to interpret it literally, then it should be the date that would correspond to day zero in the DOS epoch. But it isn't. Instead, we get the date that corresponds to day zero (or day -1?) in the Mac epoch. I disagree that that's an error. Mac OS users are used to the OS showing the proper garbage date on zero values. Is the camera a Windows device? No. Who knows what its epoch is? It's stupid to put a junk value in a created date field and to make filling the field optional in the file system. That's the real bug. And I won't change that opinion. Godfrey
Re: *istD creation/modification dates
On 17/3/05, John Francis, discombobulated, unleashed: I'm not posing as an expert. But I can see when they are screwing up. Hell you're right John, the Mac's a bag of old bollocks - I'm ditching right now. Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: On Mar 17, 2005, at 10:46 AM, John Francis wrote: Repeat it as much as you like - it's still a fact that zero is a perfectly well-defined value for the Created date on a FAT filesystem, and that the Mac (viewed as a whole) doesn't handle this case well. Just because you call it stupid doesn't alter the FAT specifications. Either you support FAT, or you don't. The Mac apparently doesn't. Despite what some experts might tell you, the Mac isn't just pulling a random value left around (whatever happens to be at that offset) out of the FAT directory data; it's retrieving a zero value that was explicitly put there, in compliance with the FAT specifications, when the file was created. And translating it to the constant that it means. Any other translation would be a guess. It's not a bug in the Mac, it's a stupid oversight in the FAT specification. It's not an oversight. It's a deliberate decision. It's apparent that it's a decision you disagree with, but that's irrelevant. You still fail to grasp the point. If the Mac were just translating zero as a normal date value, it would show up as the day before day one. But it doesn't; there's suddenly a gap of 75 years introduced between the two dates.
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: On Mar 17, 2005, at 11:06 AM, John Francis wrote: If they choose to interpret it literally, then it should be the date that would correspond to day zero in the DOS epoch. But it isn't. Instead, we get the date that corresponds to day zero (or day -1?) in the Mac epoch. I disagree that that's an error. Mac OS users are used to the OS showing the proper garbage date on zero values. Is the camera a Windows device? No. Who knows what its epoch is? It's defined. It's in the FAT specs. It's really not difficult. It's stupid to put a junk value in a created date field and to make filling the field optional in the file system. That's the real bug. And I won't change that opinion. Fine. But's it's not a junk value - that's your interpretation. Continue shouting Mac is perfect - the rest of the world is wrong for as long as you like.
Re: *istD creation/modification dates
Cotty wrote on 3/17/2005, 2:43 PM: Hell you're right John, the Mac's a bag of old bollocks Mark this date in your calendars, everyone. cotty has FINALLY come to his senses! :-) -- Christian [EMAIL PROTECTED]
Re: *istD creation/modification dates
On Mar 17, 2005, at 12:43 PM, John Francis wrote: Godfrey DiGiorgi mused: On Mar 17, 2005, at 11:06 AM, John Francis wrote: If they choose to interpret it literally, then it should be the date that would correspond to day zero in the DOS epoch. But it isn't. Instead, we get the date that corresponds to day zero (or day -1?) in the Mac epoch. I disagree that that's an error. Mac OS users are used to the OS showing the proper garbage date on zero values. Is the camera a Windows device? No. Who knows what its epoch is? It's defined. It's in the FAT specs. It's really not difficult. It's stupid to put a junk value in a created date field and to make filling the field optional in the file system. That's the real bug. And I won't change that opinion. Fine. But's it's not a junk value - that's your interpretation. Continue shouting Mac is perfect - the rest of the world is wrong for as long as you like. I have certainly not said Mac is perfect. As I said, the Finder's Inspector and List views are inconsistent, and the reason is the different code used to interpret the values. I feel the Inspector's '-' display is more accurate. However, why should the 0 date case be handled differently based upon a file system stupidity? Anything that does not put a proper value in should be handled in the context of the runtime environment's defaults. That is the expected behavior, as FAT file systems can be read by many different OSes. Handling it any other way is creating a false impression that the data input in this field is meaningful. Godfrey
Re: *istD creation/modification dates
Christian wrote: Cotty wrote on 3/17/2005, 2:43 PM: Hell you're right John, the Mac's a bag of old bollocks Mark this date in your calendars, everyone. cotty has FINALLY come to his senses! That's a premature conclusion... He's only classifying his Mac. He clearly did NOT say he was changing platforms. keith whaley
Re: *istD creation/modification dates
On 17 Mar 2005 at 19:43, Cotty wrote: On 17/3/05, John Francis, discombobulated, unleashed: I'm not posing as an expert. But I can see when they are screwing up. Hell you're right John, the Mac's a bag of old bollocks - I'm ditching right now. It took you a long time to see the light. LOL Rob Studdert HURSTVILLE AUSTRALIA Tel +61-2-9554-4110 UTC(GMT) +10 Hours [EMAIL PROTECTED] http://members.ozemail.com.au/~distudio/publications/ Pentax user since 1986, PDMLer since 1998
Re: *istD creation/modification dates
On 17/3/05, Keith Whaley, discombobulated, unleashed: Hell you're right John, the Mac's a bag of old bollocks Mark this date in your calendars, everyone. cotty has FINALLY come to his senses! That's a premature conclusion... He's only classifying his Mac. He clearly did NOT say he was changing platforms. I just had a Mac bonfire in the garden. Lots of melted plastic. I'm now going to hang on every word John Francis says :-) Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: I have certainly not said Mac is perfect. As I said, the Finder's Inspector and List views are inconsistent, and the reason is the different code used to interpret the values. I feel the Inspector's '-' display is more accurate. Isn't that just about what I said, originally? That both the - and the 31 Dec 03 were different ways of saying I don't know ? If the List view had also displayed - (or ---, like Photoshop) I doubt if the original confusion would have arisen. However, why should the 0 date case be handled differently based upon a file system stupidity? Anything that does not put a proper value in should be handled in the context of the runtime environment's defaults. That is the expected behavior, as FAT file systems can be read by many different OSes. Handling it any other way is creating a false impression that the data input in this field is meaningful. You're the one calling it a file system stupidity. I'm saying it's a deliberate design decision, and it explicitly means not present. The one thing a file system handler can be certain of, when it writes a file, is the timestamp the file was last modifed. On a FAT file system, that date is the last written date, which must be present. As you point out, FAT is used by many different OSes. Not all of those OSes support the concept of more than one file timestamp. In that case they are supposed to use the last written field, and to write zeros into the date created field. I wouldn't be at all surprised to find that the embedded OS used by Pentax in their DSLRs is such an OS, which is why we see those zero dates. Things get really interesting when you copy a file which has both created and modified dates, anyway. Which, if either, should be updated to reflect the date on which the file was copied? There are arguments to be made for just about any combination you choose.
Re: *istD creation/modification dates
Cotty mused: On 17/3/05, Keith Whaley, discombobulated, unleashed: Hell you're right John, the Mac's a bag of old bollocks Mark this date in your calendars, everyone. cotty has FINALLY come to his senses! That's a premature conclusion... He's only classifying his Mac. He clearly did NOT say he was changing platforms. I just had a Mac bonfire in the garden. Lots of melted plastic. I'm now going to hang on every word John Francis says :-) About time, too. Now we just need to get you to concede the intrinsic merits of that place up the M11, instead of the other place ...
Re: *istD creation/modification dates
On 17/3/05, John Francis, discombobulated, unleashed: Hell you're right John, the Mac's a bag of old bollocks Mark this date in your calendars, everyone. cotty has FINALLY come to his senses! That's a premature conclusion... He's only classifying his Mac. He clearly did NOT say he was changing platforms. I just had a Mac bonfire in the garden. Lots of melted plastic. I'm now going to hang on every word John Francis says :-) About time, too. Now we just need to get you to concede the intrinsic merits of that place up the M11, instead of the other place ... Your arrogance is as big as your beard! ;-P Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
No he hasn't, if that were true the OVERPRICED would be in there somewhere. Christian wrote: Cotty wrote on 3/17/2005, 2:43 PM: Hell you're right John, the Mac's a bag of old bollocks Mark this date in your calendars, everyone. cotty has FINALLY come to his senses! :-) -- I can understand why mankind hasn't given up war. During a war you get to drive tanks through the sides of buildings and shoot foreigners - two things that are usually frowned on during peacetime. --P.J. O'Rourke
Re: *istD creation/modification dates
EXIF explicitly says it adheres to FAT16 and FAT32. whether you like the spec or not, it is the spec, and all Windows computers get it right. Herb - Original Message - From: Godfrey DiGiorgi [EMAIL PROTECTED] To: pentax-discuss@pdml.net Sent: Thursday, March 17, 2005 2:34 PM Subject: Re: *istD creation/modification dates I disagree that that's an error. Mac OS users are used to the OS showing the proper garbage date on zero values. Is the camera a Windows device? No. Who knows what its epoch is? It's stupid to put a junk value in a created date field and to make filling the field optional in the file system. That's the real bug. And I won't change that opinion.
Re: *istD creation/modification dates
Macs consider that history began on 1 January 1904, whereas Windows thinks it began on 1 January 1900. That explains why your Mac is saying 31/12/03. There is no date recorded in the field, and rather than display nothing, the Mac goes back to the dawn of time. John On Tue, 15 Mar 2005 22:23:24 -0500 (EST), John Francis [EMAIL PROTECTED] wrote: Tom Lesser mused: When I use the finder on my Mac (OS X) to open the DCIM 100PENTX folder on a CF card shot in my *istD, and select a RAW file in list view, the column headed Date Modified shows the actual date and time that the photo was shot; the column headed Date Created says Dec 31, 1903 ... I would have expected Date Created to show the date and time the photo was shot, and the Date Modified to be empty or show the actual creation date, too. Date Created should show when the file was created. This could be set from an existing file, if copied, or it would reflect the date that the file was imported into the system. Date Modified reflects when the contents of the file were modifed. The two dates start off the same on the CF card (and if I look at the files using a file browser on Windows I see that). If the Mac shows something different in the file browser, It's probably a MAC problem. Dec 31, 1903 is too early a date to have a meaningful representation on most computer file systems. I suspect this really means I don't know In the Metadata panel of Photoshop CS, before you select an image in the browser, the fields available are Date Created and Date Modified, but when you select a RAW image, the Date Created field disappears completely, and the Date Modified shows the actual creation date time. Presumably Photoshop is trying to do something clever and get the image creation date from the EXIF data. Unfortunately it's trying to be too clever - it doesn't know how to get data from RAW files. (I assume you *do* have the appropriate version of ACR installed) Photoshop Elements 3.0 on Windows shows the correct metadata. If you select a RAW file from the finder and do a Get Info command, the Info window shows two dashes -- in the Created field, and shows the actual date and time the photo was made in the Modified field. That's probably another way of saying I don't know Re: JPG files, Photoshop Browser shows correct Created and Modified dates/times, as do the Finder window and Get Info window. So Photoshop does know how to get the data from the JPEG files. That's not really surprising - several file browsers know that. Why are dates and times wrong for RAW files? Is it a Pentax issue, a Mac issue, or a Photoshop issue? Looks like a Mac and/or Photoshop problem. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005
Re: *istD creation/modification dates
Quoting John Francis [EMAIL PROTECTED]: Looks like a Mac and/or Photoshop problem. Hmmm... I just used the Windows Explorer and added some custom fields to the Details view. One field called image created date shows nothing. I agree with you about the interpretation of the file created date, but it would have been nice if the image created date was correctly set as well. Interestingly, the Pentax Photo browser has got a third take on this. Below the thumbnail, it shows a date that varies with local timezone, while the date/time field in the metadata below shows an absolute timestamp. Thus, all the pics from Israel a couple of weeks ago, have literally correct stamp relative to your current timezone, whereas the metadata entry is correct according to the local timezone where the shot was made. :-) I have only raw files to look at, but imo, the mac can't be the culprit here. Jostein This message was sent using IMP, the Internet Messaging Program.
Re: *istD creation/modification dates
On Mar 16, 2005, at 4:20 AM, Jostein wrote: Looks like a Mac and/or Photoshop problem. Hmmm... I just used the Windows Explorer and added some custom fields to the Details view. One field called image created date shows nothing. I agree with you about the interpretation of the file created date, but it would have been nice if the image created date was correctly set as well. Interestingly, the Pentax Photo browser has got a third take on this. Below the thumbnail, it shows a date that varies with local timezone, while the date/time field in the metadata below shows an absolute timestamp. Thus, all the pics from Israel a couple of weeks ago, have literally correct stamp relative to your current timezone, whereas the metadata entry is correct according to the local timezone where the shot was made. :-) I have only raw files to look at, but imo, the mac can't be the culprit here. You're quite right, Mac OS is not the culprit at all. Image files on a card written by the DS do not have the Created date field in the FAT file directory filled out. I used the Terminal to read direct from the SD card's file system using the GetFileInfo development tool: $ ./GetFileInfo -m /Volumes/NO\ NAME/DCIM/100PENTX/IMGP1529.PEF 03/11/2005 22:54:00 $ ./GetFileInfo -d /Volumes/NO\ NAME/DCIM/100PENTX/IMGP1529.PEF 02/05/2040 22:28:16 The -m option returns the Modified date, the -d option should return the Created date, but in the case of the Pentax *ist DS' SD file system, the latter is nil and the system grabs whatever bytes are in that offset on the FAT volume and translates them to a date. The problem can be corrected pretty easily. Drag copy the files to your Mac OS X system, then use a script to pipe the DATE STRING output of GetFileInfo -m filename to SetFile -d DATE STRING filename. Perhaps I'll write the script when I have a few moments... Godfrey
Re: *istD creation/modification dates
Hi, if there is a compilation of JHEAD for Mac (as there probably is), it has an option IIRC that writes the EXIF creation date/time into the filesystem's date/time. Apart from many other features like renaming files according to date/time in EXIF, et cetera... of course JHEAD is only for jpegs :-( Good light! fra
Re: *istD creation/modification dates
On Mar 16, 2005, at 9:30 AM, Frantisek wrote: Hi, if there is a compilation of JHEAD for Mac (as there probably is), it has an option IIRC that writes the EXIF creation date/time into the filesystem's date/time. Apart from many other features like renaming files according to date/time in EXIF, et cetera... of course JHEAD is only for jpegs :-( There are many such utilities available for Mac OS X (I'm not familiar with JHEAD specifically), but again they work primarily with JPEG files. This particular issue is most easily solved with scripting the GetFileInfo and SetFile commands, which are installed with the Mac OS X development tool suite. There are certainly other ways to achieve the same thing as well when/if I have time... Godfrey
Re: *istD creation/modification dates
GD There are many such utilities available for Mac OS X (I'm not familiar GD with JHEAD specifically), but again they work primarily with JPEG Sorry I missed the start of the thread - I though jpgs were in question. Good light! fra
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: You're quite right, Mac OS is not the culprit at all. Image files on a card written by the DS do not have the Created date field in the FAT file directory filled out. . . (Warning: Non-tech-heads might want to bale out now). Actually, Mac OS *is* the culprit. It doesn't support FAT correctly. (I'm including the file browser as part of the software in Mac OS) The FAT specifications explicitly state that the Created date field is an optional field. If you don't supply a value, you must leave the field zero. This is exactly what the file system on the CF card does. Windows checks for the zero value, and elects to display the modification date (aka the Last Write date), which is the only mandatory date field. (I haven't actually checked to see whether the substitution is done in Windows Explorer, or within the kernel. I suspect the latter). When the Mac kernel is asked for information about the FAT volume, it looks as though it recognises the special case of zero, and doesn't translate a zero date offset from the FAT epoch to the Mac epoch. But the Mac file browser doesn't seem to be prepared to handle this case, and simply formats a zero value as the day before time began. Photoshop on the Mac obviously recognises the zero, but displays --
Re: *istD creation/modification dates
Jostein mused: Quoting John Francis [EMAIL PROTECTED]: Looks like a Mac and/or Photoshop problem. Hmmm... I just used the Windows Explorer and added some custom fields to the Details view. One field called image created date shows nothing. I agree with you about the interpretation of the file created date, but it would have been nice if the image created date was correctly set as well. It would be, if you had a Windows Shell Extension that knows how to get those fields from a Pentax RAW file. Windows Explorer knows how to rummage around inside a JPEG file to get the EXIF fields, and it understands quite a few other image file formats as well. But Pentax RAW (PEF) files aren't on that list.
Re: *istD creation/modification dates
On 16/3/05, John Francis, discombobulated, unleashed: the Mac file browser Goddo, what the heck is this? Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
Cotty mused: On 16/3/05, John Francis, discombobulated, unleashed: the Mac file browser Goddo, what the heck is this? It's what you use when you're sitting in front of a Mac and you want to browse through the various folders/directories to see what files are there. As opposed to the Windows file browser, which is what you use if you're in front of a Windows box. Or the Gnome or KDE browser you might use on a Linux system. It's really not that complicated - even a Mac user should be able to understand the concept ... It might be part of the OS software, or it might be just a simple user application providing a graphical interface. None of the points I raised depend on this in any way.
Re: *istD creation/modification dates
On 16/3/05, John Francis, discombobulated, unleashed: It's what you use when you're sitting in front of a Mac and you want to browse through the various folders/directories to see what files are there. So do you mean the 'Find' facility (Command+F) ? Or a plain old window? Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
On Mar 16, 2005, at 12:53 PM, John Francis wrote: Cotty mused: On 16/3/05, John Francis, discombobulated, unleashed: the Mac file browser Goddo, what the heck is this? It's what you use when you're sitting in front of a Mac and you want to browse through the various folders/directories to see what files are there. That's the Finder. It does a HELL of a lot more than the Windows File Browser. Godfrey
Re: *istD creation/modification dates
On Mar 16, 2005, at 11:50 AM, Cotty wrote: On 16/3/05, John Francis, discombobulated, unleashed: the Mac file browser Goddo, what the heck is this? There is no such thing. Godfrey
Re: *istD creation/modification dates
On 16/3/05, Godfrey DiGiorgi, discombobulated, unleashed: the Mac file browser Goddo, what the heck is this? There is no such thing. Yah I thought so. Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
On 16/3/05, Godfrey DiGiorgi, discombobulated, unleashed: the Mac file browser Goddo, what the heck is this? It's what you use when you're sitting in front of a Mac and you want to browse through the various folders/directories to see what files are there. That's the Finder. It does a HELL of a lot more than the Windows File Browser. Yah I thought so too but what the heck, I'm easygoing ;-) Cheers, Cotty ___/\__ || (O) | People, Places, Pastiche ||=|http://www.cottysnaps.com _
Re: *istD creation/modification dates
On Mar 16, 2005, at 11:43 AM, John Francis wrote: Godfrey DiGiorgi mused: You're quite right, Mac OS is not the culprit at all. Image files on a card written by the DS do not have the Created date field in the FAT file directory filled out. . . (Warning: Non-tech-heads might want to bale out now). Actually, Mac OS *is* the culprit. It doesn't support FAT correctly. (I'm including the file browser as part of the software in Mac OS) The Finder handles this situation correctly: select any file on the FAT volume and use the Get Info command, the Created date is simply marked as '-'. However, when you're looking at a list view and want to see Created and Modified dates, It's exactly the opposite way around from what you state. The Finder calls the UNIX routines which do not handle the lack of a creation date correctly ... They just report whatever happens to be in the appropriate number of bytes at the appropriate offset and return that. Aside from that, it's stupid to have a Created date be an optional field. Godfrey
Re: *istD creation/modification dates
- Original Message - From: John Francis [EMAIL PROTECTED] but it would have been nice if the image created date was correctly set as well. It would be, if you had a Windows Shell Extension that knows how to get those fields from a Pentax RAW file. Windows Explorer knows how to rummage around inside a JPEG file to get the EXIF fields, and it understands quite a few other image file formats as well. But Pentax RAW (PEF) files aren't on that list. So EXIF isn't so standard after all, then. :-) Actually, I'm not really bothering with what WinExplorer do, it's not expected that it should recognise any of the proprietary raw file formats anyway. What's more interesting is that not even Pentax themselves have managed to create a browser to sort this out. My previous mail was written from a laptop at work. Here at home, I have checked ThumbsPlus and C1 RAW, and both are able to display the exact second the shutter was tripped. In thumbsPlus, the file timestamp is consequently 12-13 seconds behind Original date/time. So If I have got this right, neither MAC or MS OS'es nor Photoshop CS on both platforms (Raw converter v2.3) can read the creation timestamp, but some other applications can. Would be nice to know if this bug has been fixed in raw-module v2.4 for CS, and to hear if eg. BreezeBrowser or other software packages can read it. Someone recently mentioned another rawconverter as well, that seemed like freeware? Jostein
Re: *istD creation/modification dates
On Mar 16, 2005, at 2:23 PM, Jostein wrote: So EXIF isn't so standard after all, then. :-) No, it isn't. So If I have got this right, neither MAC or MS OS'es nor Photoshop CS on both platforms (Raw converter v2.3) can read the creation timestamp, but some other applications can. Would be nice to know if this bug has been fixed in raw-module v2.4 for CS, and to hear if eg. BreezeBrowser or other software packages can read it. In the Photoshop File Browser' Metadata panel, the File Properties data is generated from the file on disk, not from the EXIF information. The Camera Data is generated from the EXIF info. The two items are different bits of data coming from different places. The File Properties data is written to the FAT file system in the camera, the EXIF data is incorporated and embedded into the image file. Godfrey
Re: *istD creation/modification dates
Cotty mused: On 16/3/05, John Francis, discombobulated, unleashed: It's what you use when you're sitting in front of a Mac and you want to browse through the various folders/directories to see what files are there. So do you mean the 'Find' facility (Command+F) ? Or a plain old window? The latter, I suspect. Assuming that can show you the various creation/modification dates. It's not really part of the OS - after all, OS X is basically Unix. But on the Mac it's sometimes hard to tell where the OS stops and the GUI begins.
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: On Mar 16, 2005, at 12:53 PM, John Francis wrote: Cotty mused: On 16/3/05, John Francis, discombobulated, unleashed: the Mac file browser Goddo, what the heck is this? It's what you use when you're sitting in front of a Mac and you want to browse through the various folders/directories to see what files are there. That's the Finder. It does a HELL of a lot more than the Windows File Browser. Call it what you will. There's something on a Mac that lets you bring up a window on a folder, and which shows you the files in that folder, together with showing you various file attributes (which, in the case we are discussing, include creation dates). If it shows a date of 31 Dec 1903 for files on a CF card written in a digital camera, it's broken code, because it isn't implementing FAT correctly. Arguing about what it is called doesn't change the fact that there's a problem somewhere in the Mac software.
Re: *istD creation/modification dates
Godfrey DiGiorgi mused: However, when you're looking at a list view and want to see Created and Modified dates, It's exactly the opposite way around from what you state. The Finder calls the UNIX routines which do not handle the lack of a creation date correctly ... They just report whatever happens to be in the appropriate number of bytes at the appropriate offset and return that. Which will be the Created date - it will just have a value of 0. The field is always present. Who converts dates from the DOS Epoch to the Mac epoch? The OS, or the Finder? Aside from that, it's stupid to have a Created date be an optional field. That's a poor excuse for not handling it correctly.
Re: *istD creation/modification dates
- Original Message - From: John Francis Subject: Re: *istD creation/modification dates Arguing about what it is called doesn't change the fact that there's a problem somewhere in the Mac software. OH MY GAWD! WW
*istD creation/modification dates
Am I the only one who is bothered by these discrepencies? Is it really a problem? Is there a solution ? When I use the finder on my Mac (OS X) to open the DCIM 100PENTX folder on a CF card shot in my *istD, and select a RAW file in list view, the column headed Date Modified shows the actual date and time that the photo was shot; the column headed Date Created says Dec 31, 1903 ... I would have expected Date Created to show the date and time the photo was shot, and the Date Modified to be empty or show the actual creation date, too. In the Metadata panel of Photoshop CS, before you select an image in the browser, the fields available are Date Created and Date Modified, but when you select a RAW image, the Date Created field disappears completely, and the Date Modified shows the actual creation date time. If you select a RAW file from the finder and do a Get Info command, the Info window shows two dashes -- in the Created field, and shows the actual date and time the photo was made in the Modified field. Re: JPG files, Photoshop Browser shows correct Created and Modified dates/times, as do the Finder window and Get Info window. Why are dates and times wrong for RAW files? Is it a Pentax issue, a Mac issue, or a Photoshop issue? Thanks Tom Lesser Frederick MD
Re: *istD creation/modification dates
Tom Lesser mused: Am I the only one who is bothered by these discrepencies? Is it really a problem? Is there a solution ? When I use the finder on my Mac (OS X) to open the DCIM 100PENTX folder on a CF card shot in my *istD, and select a RAW file in list view, the column headed Date Modified shows the actual date and time that the photo was shot; the column headed Date Created says Dec 31, 1903 ... I would have expected Date Created to show the date and time the photo was shot, and the Date Modified to be empty or show the actual creation date, too. In the Metadata panel of Photoshop CS, before you select an image in the browser, the fields available are Date Created and Date Modified, but when you select a RAW image, the Date Created field disappears completely, and the Date Modified shows the actual creation date time. If you select a RAW file from the finder and do a Get Info command, the Info window shows two dashes -- in the Created field, and shows the actual date and time the photo was made in the Modified field. Re: JPG files, Photoshop Browser shows correct Created and Modified dates/times, as do the Finder window and Get Info window. Why are dates and times wrong for RAW files? Is it a Pentax issue, a Mac issue, or a Photoshop issue? Thanks Tom Lesser Frederick MD
Re: *istD creation/modification dates
Tom Lesser mused: When I use the finder on my Mac (OS X) to open the DCIM 100PENTX folder on a CF card shot in my *istD, and select a RAW file in list view, the column headed Date Modified shows the actual date and time that the photo was shot; the column headed Date Created says Dec 31, 1903 ... I would have expected Date Created to show the date and time the photo was shot, and the Date Modified to be empty or show the actual creation date, too. Date Created should show when the file was created. This could be set from an existing file, if copied, or it would reflect the date that the file was imported into the system. Date Modified reflects when the contents of the file were modifed. The two dates start off the same on the CF card (and if I look at the files using a file browser on Windows I see that). If the Mac shows something different in the file browser, It's probably a MAC problem. Dec 31, 1903 is too early a date to have a meaningful representation on most computer file systems. I suspect this really means I don't know In the Metadata panel of Photoshop CS, before you select an image in the browser, the fields available are Date Created and Date Modified, but when you select a RAW image, the Date Created field disappears completely, and the Date Modified shows the actual creation date time. Presumably Photoshop is trying to do something clever and get the image creation date from the EXIF data. Unfortunately it's trying to be too clever - it doesn't know how to get data from RAW files. (I assume you *do* have the appropriate version of ACR installed) Photoshop Elements 3.0 on Windows shows the correct metadata. If you select a RAW file from the finder and do a Get Info command, the Info window shows two dashes -- in the Created field, and shows the actual date and time the photo was made in the Modified field. That's probably another way of saying I don't know Re: JPG files, Photoshop Browser shows correct Created and Modified dates/times, as do the Finder window and Get Info window. So Photoshop does know how to get the data from the JPEG files. That's not really surprising - several file browsers know that. Why are dates and times wrong for RAW files? Is it a Pentax issue, a Mac issue, or a Photoshop issue? Looks like a Mac and/or Photoshop problem.
