Forum OpenACS Development: New Photo-Album Requirements
photo-album package, and solicit like-minded individuals to work on
the replacement.
My thought right now is that the photo-album should be forked and used
as the base for an entirely new package. I'd love to hear arguments
for making it backwards-compatible, however. My reason for this is
that the photo-album can be a core package in the distribution, and
this new package might be more specialized, and might not be
appropriate for distribution with the core.
My vision for the new package (for want of something better I'll call
it "image-bank") follows. Read on:
First some definitions:
EXIF - Special information embedded into the headers of an image by a
digital camera. Typical information includes camera make and model,
exposure information, date/time, and GPS coordinates.
IPTC - A standard for embedding additional metadata into the image
The International Press Telecommunications Council defines the
standard at http://www.iptc.org/ Programs like Photoshop can edit
this data. It's primarily used by news photographers, and is
supported in many different file formats including psd, tiff, and jpeg.
Next, a bit of context:
I am an ameteur photographer. I have a really nice digital camera
(Nikon D1x) and need a reliable method to store, organize, and display
images on the web. The camera uses a proprietary "raw" format with a
file extension of .nef. This file is the digital equivalent of a
negative in the film world, and I need to save these images because
they contain valuable information that is lost during the jpeg
conversion. Canon users have a similar format using a .crw extension.
My normal workflow is:
1. Take a picture with the camera, which is stored in .nef format on
the removable media in the camera.
2. Transfer that image to an Image Filing program, currently I use
DigitalPro (www.proshooters.com/dp) and use that program to remove
unwanted images and file the good ones appropriately on my local
windows workstation. At this time I also edit the IPTC captions with
a caption, copyright info, and description. The IPTC headers are saved
back to the original.
3. Particularly good images that I might want to print are edited in
a proprietary software package provided by Nikon. All adjustments are
saved as directives in the original image, while keeping the original
data untouched.
4. To print an image, I export it to photoshop, and perform
additional editing and cropping/sizing to the size I want to print.
This file is saved with the same base name as the original, with a
.psd extention.
5. To export the photos for viewing on the web, I'll execute a batch
process to export the images to jpeg format.
So now I'm ready for OpenACS and the image-bank package to do it's
work. (I told you I'd get to that). Here's what I want it to do:
- Look in a location on the local filesystem for new images. Each
image would might have one or more formats of the same image (with the
same base name) .nef, .psd, .jpg
- If it finds a set of images, it would save those images using the
content-repository and extract any EXIF and IPTC headers in the image
and store it in the database.
- All images would be added to an "incoming" holding area.
- All metadata is then indexed for use by the Search function.
Now the images are uploaded, each image has, at the minimum, three
jpeg versions in different sizes, and complete metadata is stored in
the database and is full-text searchable. Optionally, an image might
have one or more high-resolution .psd or .nef files associated with
it, all stored in cr
The web interface serves two functions. The photographer, (someone
with admin rights on an album) will be able to manage his/her
collection of images using the web interface. They could organize
images into folders, edit the metadata as needed, and re-create
thumbnails as needed in different sizes (in case the auto-import
function made bad decisions as to the convert parameters) They also
might want to "publish" the photos to a public folder. A folder also
has an interface to edit it's own template, and that of individual images.
A normal user of the web site could browse albums and view metadata,
add comments, and optionally "rate" a photo as in photo.net (ratings
would be a configurable option for each photo) A user might also be
able to buy a print of the image. I'm thinking of, at the minimum, a
simple PayPal "Buy it now" interface which could be implemented in
html, but we might think about integrating with the ecommerce package.
So the major changes to the photo-album are:
- metadata is primarily image-driven. It can be edited using the web
interface, but it must be able to be fully edited in the IPTC captions
before upload. This allows much more efficient imports of large
numbers of images.
- Many more fields are saved. There are currently 25 or so standard
EXIF fields, and 20 or more IPTC fields. The database structure needs
to be flexible enough to handle different fields on a per-image basis.
(EG: Images taken with different cameras have different fields)
Currently the photo-album stores only 3 fields
- FTS enabled
- general-comments enabled
- bulk uploading from the file system, or zip files
- Linking of high-resolution image formats to the thumbnails.
- E-Commerce enabled
- Each folder has it's own linked template
- Each image can have it's own linked template
Ok, enough rambling from me, now it's your turn!
1. The current photo album module stores binaries of the pictures in it's database using an Acs generated number as filename. Each jpeg size version of the picture has a different number, placed in subfolders of the cr.
Drawback: it is not possible to do a quick human browse through the cr directory. The filenames of the pictures don't give a clue about the picture. Neither of it's size. Should we use a single basename for each picture with a trailing size and format indicator?
2. Should it be possible to store some versions (e.g. the biggest) of a picture on directories outside the acs computer? It seems to be a good thing to save space on your expensive hosted system and keep your uncompressed pictures on a local drive or cd.
The complicated part would be the web form interaction required to allow a user to alter the display order.
As far as storing big images on a workstation, personally I wouldn't want to, in fact that is exactly what I am trying to avoid. I want to use my server to store everything, mine is not hosted it's a linux box in the closet. :) I can see that being a need for many people, however. I'm not sure how to solve this problem without a client software package that communicates with the server.
Tim, your thoughts about the sort-order are the types of problems I had in mind with the customizable template for each folder or image. The templates of course would be standard adp/tcl pairs in which you could display to your liking. As you suggested, It'd be simple enough to implement the sort_order parameter as well for simplicity.
I am very impressed by your requirement list, it's very extensive! I don't have much to contribute other than maybe my own use-case and experience with publishing photos with OpenACS. I am not a very serious or experienced photographer. I take photos with my Ixus on occasion and what to be able to share them easily with my friends and family on the web. The reason I chose not to use the Photo Album app was that it didn't support bulk publishing which I really wanted since I had about a thousand jpg photos organized into folders that I wanted to be able to publish without too much manual work. To achieve this a wrote a couple of shell and perl scripts to generate thumbnails and mid-size photos and to move photos easily between folders. Then I wrote a simple OpenACS application that lets me browse my photos and directories (I use the glob function to list the photos in each directory). To be able to comment on the photos I also created an ACS object for each photo. This simple setup already does most of what I need. Of course, the EXIF metadata that you mention (in particular the date when the photo was taken) would be a neat addition.
Good luck with the Photo Album application!
