Photo management

I need some scripts that, when my camera is plugged into my computers, or a memory card reader, or whatever, it is detected by the system, automatically mounted, and the pictures automatically saved off to the repository. Note that this needs to be fairly robust: If there are IO errors, etc., it should detect that and not delete the old file. If the new file is not a valid jpeg, or not the same size as the old file, that should be detected as well, and the new file possibly deleted, and the old file left as is on the card. It should also alert me that some files had this happen to them.

Hopefully that doesn't happen too often, but I gotta be prepared.

After the files are saved to the repository, they should also be placed into a database table of photos to process.

The Processing Queue

A local webpage should be made for me to see all the pictures to process, in a queue format. A php generated thumbnail, correctly oriented, should be displayed, with details as to when it was taken. Next to each image should be some options: View full size image, view full screen image, work with meta data, mark as bad, mark as good, or work with copy.

Viewing does what you would think it does, and work with meta data displays all the EXIF data from the picture, as well as a small view of the picture, and gives the ability to edit some of the EXIF fields, and add tags, descriptions, etc.

Marking the image as bad means it gets taken off the queue. The original image is not deleted from the database or the repository, but it won't be sent anywhere else, like a gallery program, flickr, etc.

Marking the image as good means that it also gets taken off the queue, and send would be sent to galleries, flickr, etc.

Work with copy creates a copy of the image in the repository and the database, linked back to the original, and goes into a simple photo processing mode. It allows rotations, resizings, croppings, some simple filtering, etc. These affect the copy only. The copy gets all the meta data from the original, even if it changes later. Several copies can be made, and appear in a drop down when work with copy is selected, along with create new copy. They list date and time of copy, and image size.

Alternatively, in the original queue list, the copies appear horizontally next to the original, and the one to work on is clicked. Clicking on the original will create a new copy.

The queue normally will display all photos that have not been marked as good or bad. Photos marked good will allow one of the copies (or the original) to be tagged as to what to use it for, independent of the data set for all copies. Example: gallery, flickr, blog, etc. Actually, each copy can essentially get all sorts of unique tags, if that is desired.

After a photo is marked good or bad, good photos will be directed as appropriate (good photos marked gallery will be uploaded to the gallery server, ones marked flickr will be sent to flickr, and ones marked blog will be sent to the blog server, etc.). Bad photos will just not be sent anywhere.

The queue can display: all photos, unmarked photos, good photos, bad photos. This allows later changes to the photo, or changing how it is marked.

DB Tables

In the database, there will be a table for all real taken images, and another table for the copies, including the original copy. So, at minimum, each image will have at least one entry in each table, and it could have multiple entries in the copy table.

In the imagetable, there are several fields:

• id
• filename
• takendate
• dimensions
• description
• peopletags
• othertags
• state (good, bad, unmarked)

In the copytable, there are some other fields:

• id
• image
• filename
• modifydate (for the original, which can't be edited, this is equal to the taken date)
• dimensions
• isoriginal
• extratags

So, when inserting a new image, first:

INSERT INTO imagetable (filename, takendate, dimensions, descriptions, peopletags, othertags, state) VALUES(filename, date, dimensions, "", "", "", unmarked);

and get the id used for that insertions. then,

INSERT INTO copytable (image, filename, modifydate, dimensions, isoriginal, extratags) VALUES (image id, filename, date, dimensions, true, "");

Later copies that get made:

INSERT INTO copytable (image, filename, modifydate, dimensions, isoriginal, extratags) VALUES (image id, copy filename, now(), new dimensions, false, "");

And, with all the above, updates could occur to change the tags and descriptions and whatnot, and for the copies the date and dimensions could also change, and for the images, the marked state could change too.