| Author | Thread |
|
|
07/16/2005 10:47:54 AM · #51 |
textBased on what I've read (not having access to the original file itself), if I was still on the SC, I'd personally be voting "No DQ
Well TY eddieG, and i wished you were there to vote no DQ. I just hope more people come out of the chute prepared with an original. I have done my best to keep these threads active for people that don't know. |
|
|
|
07/16/2005 10:58:23 AM · #52 |
For those who are affected by this... just keep this thought in mind: If you shoot RAW then ACDSee doesn't touch the original.
I know it adds work to the workflow, but there are benefits too. :-)
|
|
|
|
07/16/2005 11:46:08 AM · #53 |
While I'm sympathetic to the problem. I'm not sure what else can be done if the SC is to verify the integrity of the image. Suggestions?
A question: The software field is not the only field that can be used. There are a number of date stamps in the EXIF. If the date modified matches the date created is that good enough? I don't use or have ACDSee, but when it puts itself in the software field does it also change the date modified field?
So I would like the SC to tell everyone what is required in the EXIF to prevent a DQ. What are they checking. This can be put into the rules and everyone will know that whatever software they use needs to be checked against this standard. |
|
|
|
07/17/2005 10:33:48 AM · #54 |
Originally posted by fixedintime:
A question: The software field is not the only field that can be used. There are a number of date stamps in the EXIF. If the date modified matches the date created is that good enough? I don't use or have ACDSee, but when it puts itself in the software field does it also change the date modified field? |
Good question. In the version I have there a few date/time fields. The EXIF data in AcdSee is catagorized; Camera, Image and Misc. In the image catagory there is a Date/time original and Date/time digitized. I cannot find any images that I have where these differ. They are the time from the camera when the photo was taken. When I use AcdSee to edit the image in the camera catagory the Software field appears tagging it with ACD Systems Digital Imaging and another Date/time field of the time of the edit from the pc.
I compared my last submission with the original and the only difference was the additional Software and Date/time being added during prep for submission.
dwterry's earlier comment about it appearing to be the difference in cameras between me and sacredspirit seems right on. I would agree. |
|
|
|
07/17/2005 10:58:14 AM · #55 |
Originally posted by dwterry:
Originally posted by mavrik:
What if auto rotate isn't on, etc? |
I take it back... I use auto-rotate and the images that have been rotated DO have ACDSee listed in the EXIF data. The ones that haven't been rotated do not mention ACDSee at all.
So I guess this is a question for the SC. If the image has been aquired via ACDSee and auto-rotated (and thus the EXIF now says ACDSee in the Software field of the EXIF data), does the file still count as an "original"? |
No.
By rotating the original, it is no longer an original. It has been altered. Once the original has been altered, we have no way to determine what alterations were or were not made to it.
The recommended method for moving an original is a straight file copy using your operating system. This not only preserves your originals for DPC purposes, but also if your images were to be stolen and you needed to prove ownership.
-Terry
|
|
|
|
07/17/2005 10:59:10 AM · #56 |
Originally posted by autobahn123:
If I open and close (don't save) a raw image in Photoshop, does it put that in the exif data? |
No. Changes to the EXIF are only committed upon saving.
-Terry
|
|
|
|
07/17/2005 11:08:32 AM · #57 |
Originally posted by fixedintime:
So I would like the SC to tell everyone what is required in the EXIF to prevent a DQ. What are they checking. This can be put into the rules and everyone will know that whatever software they use needs to be checked against this standard. |
We've done that; the EXIF data has to reflect an original capture out of the camera.
Once that information has been modified by any software, we have no way to determine how/how much it's been altered; at least not one easy and practical enough to work here in this context--we are not a forensics lab. |
|
|
|
07/17/2005 11:17:32 AM · #58 |
Originally posted by ClubJuggle:
The recommended method for moving an original is a straight file copy using your operating system. This not only preserves your originals for DPC purposes, but also if your images were to be stolen and you needed to prove ownership. |
like i said before this sounds like there is a need for a simple utility to handle this part of the workflow... |
|
|
|
07/17/2005 11:25:20 AM · #59 |
Anyone know how to turn off the auto rotate in acdcee 6.0?
|
|
|
|
07/17/2005 11:29:47 AM · #60 |
I don't use this program but if there is an option to turn it off it would be in preferences/options.
You may have to turn off auto-rotate in camera.
|
|
|
|
07/17/2005 12:05:22 PM · #61 |
Originally posted by fixedintime:
While I'm sympathetic to the problem. I'm not sure what else can be done if the SC is to verify the integrity of the image. Suggestions?
A question: The software field is not the only field that can be used. There are a number of date stamps in the EXIF. If the date modified matches the date created is that good enough? I don't use or have ACDSee, but when it puts itself in the software field does it also change the date modified field?
So I would like the SC to tell everyone what is required in the EXIF to prevent a DQ. What are they checking. This can be put into the rules and everyone will know that whatever software they use needs to be checked against this standard. |
It would be great if we could do that, but the down-side is that revealing our exact criteria for determining whether a photo is truly an original also serves to give any would-be cheaters a recipe for forging their EXIF data.
What I can tell you is that we use multiple criteria and compare them to known-good originals.
-Terry
|
|
|
|
07/18/2005 12:38:55 PM · #62 |
Terry,
I would not want to have the SC give away all the secrets they might use to catch someone cheating. But I would like to see a better, and more open, approach to the problem. From what I read people are being caught unaware with the resulting DQ. That does not go over well.
Perhaps a middle of the road approach is to state up front in the rules that people should check the EXIF data on the original prior to entering and make sure that the software field contains only the camera software and that the various date fields should all have the same date/time stamp.
Those seem to be no brainers and would prevent most of the problems. Other checks that the SC uses can be kept under wraps.
Larry........... |
|
|
|
07/18/2005 01:27:49 PM · #63 |
Originally posted by fixedintime:
I think the issue is bigger than just ACDSee. This whole discussion leave me feeling like any download software puts the EXIF data at risk. This is especially true for those of us who like to rename the files when we donwload them.
Does someone know of a good free EXIF viewer that we can all use to view the data to be sure our method does not change the data? |
Irfanview is free and includes a comprehensive exif viewer.
R.
|
|
|
|
07/18/2005 01:29:16 PM · #64 |
Originally posted by Sunniee:
Anyone know how to turn off the auto rotate in acdcee 6.0? |
You can turn off autorotate in your CAMERA menu, and then ACDSee doesn't see a tag and won't rotate it. The safest thing to do in all cases is to disable autorotate in the camera.
Robt.
|
|
|
|
07/18/2005 01:35:54 PM · #65 |
| Does autorotate in the CAMERA cause the software to perform the rotation or does the camera do it using its internal software ??? |
|
|
|
07/18/2005 01:53:50 PM · #66 |
Originally posted by nomad469:
Does autorotate in the CAMERA cause the software to perform the rotation or does the camera do it using its internal software ??? |
IN at least some cases, autorotate "flags" the image with a tag that causes the software to rotate it. I am not specifically aware that any cameras rotate within themselves without an outside editor, although I'm sure it is done.
The point here is that IF ACDSee is autorotating your images, then it can only be doing so because the camera has tagged the image as being a vertical shot. So for those who were asking how to turn this feature off in ACDSee, I am saying turn it off in the CAMERA and it won't matter.
R.
|
|
|
|
07/18/2005 02:37:45 PM · #67 |
Originally posted by bear_music:
I am not specifically aware that any cameras rotate within themselves without an outside editor, although I'm sure it is done. |
the d70 does auto-rotate the image and saves it that way on the card. when i copy the file directly from card to hard drive, the image is vertically aligned.
yes, this is confusing. i understand. but with the advances of the software applications we're discussing here i hope you can understand our point. for instance, in ACDSee you can crop, rotate, adjust colors, select portions of a photo, etc. doing so affects the EXIF data the same way that merely rotating the photo will apparently do. therefore, it's impossible for us to determine whether or not ANY editing has been done to one of these images if the original has got the "fingerprint" of a software package on it.
there is a way to disable the auto-rotate in ACDSee. i'm not in front of my PC right now so i can't tell you the exact command path to perform.
even if you acquire the images via ACDSee (or any other software), they are still located as original, untouched files on your card or camera. perhaps you could go through all of your images and then, once you've decided which you wish to submit for a challenge, go back and manually copy the exact original file from the card and keep it without ever having opened it in the program?
i understand that this might impact some user's workflow, but if you're shooting specifically for a challenge it should not require much more effort. |
|
|
|
07/18/2005 04:09:38 PM · #68 |
Muck,
I got no problem at all with your position (if that's directed at me); I'm discussing wasy to make sure people don't get messed up with this issue, and the simplest, surest "fix" is to disable autorotate in-camera. :-)
I'll be interested to see how the 20D handles it...
Robt.
|
|
|
|
07/18/2005 05:11:13 PM · #69 |
Originally posted by bear_music:
Muck,
I got no problem at all with your position (if that's directed at me); I'm discussing wasy to make sure people don't get messed up with this issue, and the simplest, surest "fix" is to disable autorotate in-camera. :-)
I'll be interested to see how the 20D handles it... |
When Auto-rotate is enabled on my 20D the camera will display a portrait oriented shot in the verticle position on it's LCD. It also embeds a tag in the image file that tells Canon software to rotate the image. To the best of my knowledge, no other software reads this tag. When I open the images in PSP7 they are not rotated. Same for Windows Picture & Fax Viewer, Irfanview, NeatImage, and Paint Shop Photo Album 4. If I use a non-Canon program to rotate the image it will not appear correctly if viewed subsequently in a Canon program. Maybe newer versions, or more expensive programs, will read the 20D's tag.
Besides creating a difference in the way the various programs that I use display the same images, the bigger disadvantage to Canon's approach is that the rotated images show up much smaller on the LCD screen. Maybe if you had a larger LCD like the 2.5 inch screen that the Nikon pro bodies use, the smaller image would not be as much of a nuisance, but on the 20D's 1.8 inch LCD it is a sacriface I choose not to make. I prefer having to turn the camera 90 degrees and seeing the larger size image when I am reviewing in the field.
|
|
|
|
07/18/2005 05:19:26 PM · #70 |
Muck... thanks for picking up on the autorotate with the D70 I thought that is the way it worked but wasn't 100% sure.
Message edited by author 2005-07-18 17:19:57. |
|
|
|
07/18/2005 06:13:55 PM · #71 |
Originally posted by coolhar:
Maybe if you had a larger LCD like the 2.5 inch screen that the Nikon pro bodies use, the smaller image would not be as much of a nuisance, but on the 20D's 1.8 inch LCD it is a sacriface I choose not to make. I prefer having to turn the camera 90 degrees and seeing the larger size image when I am reviewing in the field. |
Excellent point!
It always gripes me that when I play back a vertical image it is so tiny I can hardly see it. Running off to grab my camera now...
|
|
|
|
07/18/2005 06:31:39 PM · #72 |
I find that about 90% of all "features" turn out to be "gimmicks" of which I might maybe find one actually useful enough to be worth figuring out how to program it.
And like, why do people need a utility to copy files from one disk to another--that's what the operating system is there for. If it's not good for that, then maybe you should by a Mac ... : )
In the days of Mac OS 6.x, there existed a utility called DiskTop, which was more efficient for copying (large) files that the OS drag-and-drop method. But unless you are still using a Mac-in-a-box model like a Mac Plus or MacSE, that's no longer relevant.
|
|
|
|
07/18/2005 06:40:07 PM · #73 |
Originally posted by GeneralE:
why do people need a utility to copy files from one disk to another |
For me, the advantage to using ACDSee is that with a click of the button it puts the files in the right place (for me, that is a dated subfolder) and automatically names the files and ... it used to rotate the photos (no more on that one). That's more work performed by the computer than a simple copy and a lot less effort by me than a simple copy would have been. I'm lazy... and happy to let ACDSee do the work. |
|
|
|
07/18/2005 07:12:51 PM · #74 |
You always pay a price for convenience.
It takes me 5-10 seconds to create a dated folder and start copying the files to it; why would I want to re-name my originals? I rename them after/if I open and edit them, when I know what the subject is. |
|
Home -
Challenges -
Community -
League -
Photos -
Cameras -
Lenses -
Learn -
Help -
Terms of Use -
Privacy -
Top ^
DPChallenge, and website content and design, Copyright © 2001-2025 Challenging Technologies, LLC.
All digital photo copyrights belong to the photographers and may not be used without permission.
Current Server Time: 03/12/2025 03:27:35 PM EDT.
