Author | Thread |
|
11/19/2004 09:33:43 AM · #1 |
In response to the thread about someone being disqualified for exif falsification I wanted to pose two questions question... (no, it's not me who was dq'd!)
I am peeved by image organization utilities that store metadata outside an image file uneccisarily, and subsequently break when you move an image. As such, I've been working on finding ways to edit the EXIF comment field from a command line / script to embed XML for decription, keywords, etc. Without knowing the methods DPC uses to validate EXIF, I wanted to know if doing this would put my images in jeopardy of being snagged by a DQ filter somewhere? It's only the comment field I'm messing with.
I'm guessing that what I'm trying to do is probably supported by the IPTC fields, but I haven't spent much time exploring them, or their ability to be queried. I can use Bibble to batch edit for input, but it's the searching capabilities later that I'm mostly interested in... Anyone else tried to mess with homegrown image searching via EXIF or IPTC?
|
|
|
11/19/2004 09:45:31 AM · #2 |
Originally posted by cghubbell: In response to the thread about someone being disqualified for exif falsification I wanted to pose two questions question... (no, it's not me who was dq'd!)
I am peeved by image organization utilities that store metadata outside an image file uneccisarily, and subsequently break when you move an image. As such, I've been working on finding ways to edit the EXIF comment field from a command line / script to embed XML for decription, keywords, etc. Without knowing the methods DPC uses to validate EXIF, I wanted to know if doing this would put my images in jeopardy of being snagged by a DQ filter somewhere? It's only the comment field I'm messing with.
I'm guessing that what I'm trying to do is probably supported by the IPTC fields, but I haven't spent much time exploring them, or their ability to be queried. I can use Bibble to batch edit for input, but it's the searching capabilities later that I'm mostly interested in... Anyone else tried to mess with homegrown image searching via EXIF or IPTC? |
As long as you have the original image file with intact EXIF data, I don't think you are in any danger of DQ. I don't know what organization s/w you are using or what it does to the EXIF data. I would suggest saving the file associated with your entry, unedited, during the challenge and making changes to or deleting the unedited version after the end of the challenge.
|
|
|
11/19/2004 10:10:29 AM · #3 |
I've been working for a couple of years, off and on, on a project to organize photos. My biggest requirement is easy and flexible categorization and searching, but I have lots of little things I want too, like version tracking (kinda) so that my processed versions of an image are all associated with the original from-camera image. The image EXIF info is used to a great extent, and is stored into a database when the image is imported for faster searching.
Once the image database is complete enough, then I have other programs I've been thinking about that can use the API to access images in the database in a simple, flexible way.
But I've been too busy with school and stuff to work on it lately. Oh, and challenges too. ;-) |
|
|
11/19/2004 10:11:48 AM · #4 |
I'm trying to integrate an image indexing database into my workflow in an automated manner, so by default everything coming out of the camera would go through a similar indexing operation via automated EXIF/IPTC editing. That would inherently make it difficult for me to exclude challenge submissions, since I often don't know when a challenge will align with a session I shot previously (within the period).
I guess I might be in the minority, but I tend to go out and shoot without regard to challenges, and submit when the planets line up. there are exceptions when I'm inspired by a theme to do something I'd been putting off (like this b/w challenge!) but for the most part, I'd need to make my workflow DPC-safe.
I'm not really happy with my options for commercial organization software because they are not: command line friendly, priced appropriatey, available on Linux, <...>. That's why I'm going down the road of developing something myself. I try not complain unless I'm willing to do something about it :) I just want to make sure that I do it in a DPC-safe manner.
Message edited by author 2004-11-19 10:12:50.
|
|
|
11/19/2004 10:13:02 AM · #5 |
Originally posted by cghubbell: Without knowing the methods DPC uses to validate EXIF, I wanted to know if doing this would put my images in jeopardy of being snagged by a DQ filter somewhere? It's only the comment field I'm messing with. |
Hmmmmm, excellent question. I would definitely hesitate to even touch the file without finding out from the SC if editing the comment field would be a problem... |
|
|
11/19/2004 10:14:36 AM · #6 |
Originally posted by skylen: Hmmmmm, excellent question. I would definitely hesitate to even touch the file without finding out from the SC if editing the comment field would be a problem... |
Ezzactly!
Anyone from SC able to comment on this without giving away too much? Basically just need to know if the EXIF police applies to the whole EXIF structure, or is isolated on a field by field basis.
|
|
|
11/19/2004 10:20:10 AM · #7 |
Could you upload an example that we could examine the EXIF of?
|
|
|
11/19/2004 11:49:34 AM · #8 |
Manic,
Not yet... I'm still trying to find the best way to do it. Not sure yet if I want to try to use an existing utility, or use an API to do it.
If you'd prefer to do a dry run with whatever secret check method you use vs. being able to provide guidelines, then I'll just contact the SC when I have a sample. It's not a problem either way, I just thought that if there were any obvious gotchas I could avoid it might help me narrow down my options.
Thanks for the quick response!
|
|
|
11/19/2004 11:54:01 AM · #9 |
I think you might be opening a pandora's box here. Technically speaking- any image file that is processed thru an automated workflow that changes (or even just adds to) the EXIF info is not the original image file as from camera. Can you imagine the chaos if we all wrote our own automated workflows and wanted them approved in advance?
|
|
|
11/19/2004 11:55:40 AM · #10 |
TBH, I think it'd probably be best if you kept copies of your challenge entries that had no EXIF editing at all, so that you know that you're submitting a "clean" version should you be requested to do so, as opposed to running the risk with an edited version...
|
|
|
11/19/2004 12:00:13 PM · #11 |
Originally posted by Manic: TBH, I think it'd probably be best if you kept copies of your challenge entries that had no EXIF editing at all, so that you know that you're submitting a "clean" version should you be requested to do so, as opposed to running the risk with an edited version... |
this goes a little further than dpc. one thing you might consider from a workflow standpoint is a path like this:
1) images from card to pc
2) review to eliminate anything not worthy or archiving
3) images from pc to fixed media (cd or dvd) that includes a copyrighted index
4) images to a backup server/harddrive/whatever
5) then start doing whatever post processing you want.
this way, you will always be able to get back to your in-camera image |
|
|
11/19/2004 12:24:03 PM · #12 |
Originally posted by skiprow: Originally posted by Manic: TBH, I think it'd probably be best if you kept copies of your challenge entries that had no EXIF editing at all, so that you know that you're submitting a "clean" version should you be requested to do so, as opposed to running the risk with an edited version... |
this goes a little further than dpc. one thing you might consider from a workflow standpoint is a path like this:
1) images from card to pc
2) review to eliminate anything not worthy or archiving
3) images from pc to fixed media (cd or dvd) that includes a copyrighted index
4) images to a backup server/harddrive/whatever
5) then start doing whatever post processing you want.
this way, you will always be able to get back to your in-camera image |
I'll give this some consideration... I was trying to minimize redundant storage where appropriate since:
(1) NEF original
(2) NEF --> Optical
(3) NEF --> File server
(4) NEF edited revisions
(5) edit backups
Makes for a a minimum of 25mb / image. Adds up fast, and I'd rather buy glass than disks (even with current pricing). I do filter for keepers early in the workflow, so that's not an issue... But I'll often do 2-5 interpretations of a RAW file, so it gets to be a lot of storage.
What I'd like to do is store metadata with an original so all of its context can be extracted regardless of where that master resides, and rebuilding the indexes can be performed at any time simply. As a general statement, ignoring DPC rules, the most intuivie solution for this was EXIF comments. IPTC will work for a lot of what I intend, but I don't yet know how those fields are embedded, and whether or not they impact the EXIF pieces which DPC analyzes.
I appreciate the responses - I knew there would be some good insight out there :)
Message edited by author 2004-11-19 12:25:27.
|
|
|
11/19/2004 12:31:47 PM · #13 |
Originally posted by cghubbell: Makes for a a minimum of 25mb / image. Adds up fast, and I'd rather buy glass than disks (even with current pricing). |
I'm in the process of researching configurations and prices to augment my server space. 200gig HDs are under $150, and that will hold a fair amount. I know you have to balance glass vs storage, but, all the same, the requirements for managing digitial negatives are so much different than supporting a catalogued shoebox... |
|
|
11/19/2004 12:32:13 PM · #14 |
What about extracting the EXIF data to a file (or DB entry), editing that file (or entry), and then indexing that? This way you'd preserve the original without requiring multiple redundant copies...
|
|
|
11/19/2004 12:57:45 PM · #15 |
Originally posted by Manic: What about extracting the EXIF data to a file (or DB entry), editing that file (or entry), and then indexing that? This way you'd preserve the original without requiring multiple redundant copies... |
The thing that always bugged me was when an organizing app kept things in a way that broke if I moved the image elsewhere. So by embedding all metadata in the image via IPTC or EXIF comments, I would be able to regenerate the index with a filesystem scan on my workstation, my backup server, an archive DVD, etc. It really provides a lot of architectural flexibility to keep the image file as a self-contained object.
My workstation has most of my "in progress" stuff, and my complete archive on dual 120gb disks. My backup server has the latest point in time of all archives (updated nightly), and also shares out the archive so my wife or I can browse from laptops. It would be great to easily rebuild the indexes for searching on either box just by scanning the files rather than having a separate repository I'd need to transfer, and then check for broken links.
|
|
|
11/19/2004 01:01:32 PM · #16 |
Originally posted by cghubbell: Originally posted by Manic: What about extracting the EXIF data to a file (or DB entry), editing that file (or entry), and then indexing that? This way you'd preserve the original without requiring multiple redundant copies... |
The thing that always bugged me was when an organizing app kept things in a way that broke if I moved the image elsewhere. So by embedding all metadata in the image via IPTC or EXIF comments, I would be able to regenerate the index with a filesystem scan on my workstation, my backup server, an archive DVD, etc. It really provides a lot of architectural flexibility to keep the image file as a self-contained object.
My workstation has most of my "in progress" stuff, and my complete archive on dual 120gb disks. My backup server has the latest point in time of all archives (updated nightly), and also shares out the archive so my wife or I can browse from laptops. It would be great to easily rebuild the indexes for searching on either box just by scanning the files rather than having a separate repository I'd need to transfer, and then check for broken links. |
what about storing the image itself as a blob field in the database? you could still extract the exif into separate searchable/sortable fields while maintaining the completeness of your data.
edit: can't spell
Message edited by author 2004-11-19 13:08:53. |
|
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: 09/14/2025 05:12:03 AM EDT.