Forum OpenACS Q&A: photodb?

Collapse
1: photodb?
Posted by Ivan Histand on 04/02/02 05:37 PM
Hi,

I am in need of an improved photo album package, I found This Thread about the photodb package (from photo.net??) but the actual software seems to be AWOL.

Does anyone have a copy of this, or know anything about it? if it's the package from photo.net it would be a good start for my needs.

My basic requirements, on top of the functionality that photo-album already gives are:

  • Postgres support
  • Bulk import from a local file system
  • Reading of EXIF and IPTC captions of the images to automatically populate meta-data.
  • Store more meta-data about an image, db should support all current standard EXIF and IPTC tags, plus emerging standards such as GPS coordinates and print specifications.
  • integration with a shopping cart/ecommerce package, I havn't thought this through but I definately need a way to "Buy a print of this image"
  • use of ImageMagick to add borders/drop shadows on the images for a more professional look.
  • improvement in layout options of album, other choices besides just the number of images per page.
  • Easy way for content creators to copy an html snippet from an album to include the thumbnail on another page.
  • Option to link a JPG gallery image with a .PSD or Nikon .NEF high-resolution image for printing
  • (Blue-Sky) Integration with a desktop image filing system. Possible options include Canto Cumulus (canto.com) or DigitalPro (proshooters.com/dp/)
If anyone has knowledge of the photodb package, or is interested in collaborating on a new package generally fitting the above description, please let me know.
Collapse
2: Response to photodb? (response to 1)
Posted by Jonathan Ellis on 04/02/02 06:04 PM
I think Vinod's still around; he probably has it somewhere.  If not I have a copy of dubious purity lying around I could tar up.
Collapse
3: Response to photodb? (response to 1)
Posted by Vinod Kurup on 04/02/02 06:27 PM
Which version of OpenACS are you planning to use? The photodb module is built for 3.2.x and it's actually included in the OpenACS 3.2.5 release. I could wrap up a tarball if you'd like, but since I'm leaving the country today and won't be back for a couple weeks, you may just want to download it yourself 😊 I also patched a bunch of bugs after the 3.2.5 release, so you'll want to apply this patch as well.

There's also 2 packages included in the OpenACS 4.5 beta release — photo-album and photo-album-lite. I haven't investigated them much.

Collapse
4: Response to photodb? (response to 1)
Posted by Roberto Mello on 04/02/02 06:38 PM
Vinod's patches are applied to the 3.2.x CVS tree on sourceforge. I'm making effort into releasing 3.2.6 soon (i.e. in may).
Collapse
5: Response to photodb? (response to 1)
Posted by Dave Bauer on 04/02/02 07:11 PM
Also, photo-album has been ported to postgresql for OpenACS 4.5

It uses the content repository and would probably be able to be extended to do what you need.

Collapse
6: Response to photodb? (response to 1)
Posted by Walter McGinnis on 04/02/02 07:54 PM
Photo-album-lite has some of the features that you are looking
for (bulk uploading being the big one that comes to mind).  It
hasn't been ported for 4.5 because we are planning to take its
best features and add them to the photo-album package and
have one code base in the future.

If you are interested in extending the photo-album let us know.

Collapse
7: Response to photodb? (response to 1)
Posted by Ivan Histand on 04/02/02 11:05 PM
Thanks for your responses, I am working with 4.5 so that's why I didn't find the module.

Walter, yes I am interested in extending photo-album. Rather than developing it for my needs only, collaboration sounds like a great idea.  I'm a beginner with openacs but have a lot of experience building standalone aolserver apps.
Question, Is the content-repository appropriate and efficient for storing a large amount of binary data?  I would like to use the extended photo-album to store the raw images from my camera, which are 8MB each, in a proprietary format.  Add three different size JPeG images for each, it all adds up to maybe 10MB per image. Currently I have over 5000 images and counting that could be stored in the system: 50GB+

Collapse
8: Response to photodb? (response to 1)
Posted by Walter McGinnis on 04/02/02 11:19 PM
Great.  Glad to have the help.  Talk to Don about getting
appropriate access.  Andrew Grumet wrote the photo-album-lite
and is also apart of our effort to consolidate the two packages.

You are aware that the content-repository in its present form can
store the binary data in the file system or the database, right?
The photo-album, using the content-repository, stores binary
files in the file system.

As far as scalibity, maybe others that have used the content-
repository with large amounts of binary files can speak to this.

At some point soon maybe we should start a thread in the
design forum about direction the photo-album package should
take .

Collapse
9: Response to photodb? (response to 1)
Posted by Jun Yamog on 04/03/02 04:03 AM
Hi Ivan,

I am not sure how scalable is the content repository (CR) on large files but so far it is ok for our use.  The CR can either use the file system or the database to store the binary files.  Using the file system seems to be more appropriate with large and many files.  So what is stored in the database is just the file name and path.  All the files are stored in acs_root/content-repository-content-files.

I am not familiar with the photo-album package but ETP, CMS and file-storage stores the filename in the table cr_revisions at column content.  Setting the cr_revisions.storage_type to "file" and some other tcl api stores the file in the file system, look at how file-storage does this.  The storage of the binary files should be scalable since it just putting the filename and path on the db.  The fetching of the file is done via the Tcl api cr_write_content.  The code looks pretty straight forward but if there is a bottle neck it may arise from fetching the images.  After all I would assume that there are more readers than writers.  Don B wrote the tcl api cr_write_content he should have a better opinion regarding its performance, as for me I am happing with the Content Repository. I use it for practically everything that I need to store binary files when extending other apps.

Collapse
10: Response to photodb? (response to 1)
Posted by Jun Yamog on 04/03/02 04:03 AM
Hi Ivan,

I am not sure how scalable is the content repository (CR) on large files but so far it is ok for our use.  The CR can either use the file system or the database to store the binary files.  Using the file system seems to be more appropriate with large and many files.  So what is stored in the database is just the file name and path.  All the files are stored in acs_root/content-repository-content-files.

I am not familiar with the photo-album package but ETP, CMS and file-storage stores the filename in the table cr_revisions at column content.  Setting the cr_revisions.storage_type to "file" and some other tcl api stores the file in the file system, look at how file-storage does this.  The storage of the binary files should be scalable since it just putting the filename and path on the db.  The fetching of the file is done via the Tcl api cr_write_content.  The code looks pretty straight forward but if there is a bottle neck it may arise from fetching the images.  After all I would assume that there are more readers than writers.  Don B wrote the tcl api cr_write_content he should have a better opinion regarding its performance, as for me I am happing with the Content Repository. I use it for practically everything that I need to store binary files when extending other apps.

Collapse
11: Response to photodb? (response to 1)
Posted by Ivan Histand on 04/05/02 11:04 PM
As suggested, I've started a new thread in the design forum to discuss
a new photo-album package.  Feedback is appreciated:

https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0004Wu&topic_id=12&topic=OpenACS%204%2e0%20Design