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.

Some layout stuff for the queue page

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. Changing a copy of an image marked good will cause reuploads of that copy to the appropriate places. Changing a copy of an image marked bad or unmarked will not reupload until the image is marked good. Changing a mark from good to bad or unmarked will not delete the remote copies of the old image, it just won't update them for you if things change locally (again, until you mark it "good").

More Misc details about the webpage

• Intelligent autoloading of more images based on where you are scrolled to.
• Non scrolling section on the bottom of screen to show or hide various marked photos.
• Each image section could scroll to the right if there are more copies than can fit on the screen.
• Each image section can be "closed" to make it hidden, without marking it further.
• Background of image section is light green for good, light red for bad, and white for unmarked.
• Unique tags are added in textboxes under each copy and image.
• Right clicking on the image shows a menu of options as appropriate.
  • For original images, the menu contains:
    • Make new copy (default, left click)
    • Mark Good
    • Mark Bad
    • Unmark
    • Edit Metadata
    • View EXIF data
    • View full screen
    • View full size
  • For copies, the menu contains:
    • Edit copy (default, left click)
    • View full screen
    • View full size
    • Make new copy (based on this copy)

The view full screen brings up an new overlaid panel with the image and a little X to close it The view full size brings up a new tab/window with the full image. the view EXIF data brings up a little panel next to the main image displaying the EXIF details and an X to close it. The edit metadata brings up a little panel next to the main image with areas to edit the description, the people tags, and the other tags. Also, a save and a discard on top to close it. Make new copy creates a new copy entry and starts the edit sub application. Edit copy starts the edit sub application. The Mark options just change the mark of the image, possibly making it disappear from the page.

The Edit Sub Application

If we can, this will be a full screen panel with a save and a discard in the corner to close it. The image will be displayed, along with fields to show the final size of the copy. Changing one of those changes the other unless they are unlocked. The image can be rotated around by dragging the upper right corner, and can be cropped by making a box in the image with the mouse. The rest of the image is still displayed, just grayed out a bit. That way you can re-crop to the right view.

Also, there are buttons and sliders to sharpen and blur, gray scale, colorize, emboss, smooth, brighten, contrast, etc.

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 (autoincrement integer, nonnull, unique index)
• filename (varchar(255), nonnull)
• takendate (datetime)
• dimx (int)
• dimy (int)
• description (text)
• peopletags (text)
• othertags (text)
• state (enum(good, bad, unmarked))

In the copytable, there are some other fields:

• id (autoincrement integer, nonnull, unique index)
• image (int, nonnull)
• filename (varchar(255), nonnull)
• modifydate (datetime)
• dimx (int)
• dimy (int)
• isoriginal (bool, default false)
• extratags (text)

So, when inserting a new image, first:

INSERT INTO imagetable (filename, takendate, dimx, dimy, descriptions, peopletags, othertags, 
  state) VALUES(filename, date, length, height, "", "", "", unmarked);

and get the id used for that insertions. then,

INSERT INTO copytable (image, filename, modifydate, dimx, dimy, isoriginal, extratags) VALUES 
  (image id, filename, date, length, height, true, "");

Later copies that get made:

INSERT INTO copytable (image, filename, modifydate, dimx, dimy, isoriginal, extratags) VALUES  
  (image id, copy filename, now(), new length, new height, 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.