anyone else willing to put their ego on the line and make something
available? I hate the idea of re-implementing the same crud all over
Something that is ready for review (and use?) is the new Image API for abstracting storage/retrieval and manipulation of images. I've found it useful already for the image based modules on the sites I'm working with (http://archnet.org). http://jkoontz.arsdigita.com/api-doc/procs-file-view?version_id=42&path=packages/image-api/image-api.tcl
Over the next month the photodb will be rewritten to use the yet unreleased content repository. Part of the reason that I don't have the rewrite done is I'm still waiting for an internal release! :) The advantage with the new photodb will be integration with ecommerce, bulk upload, and in another month a screen saver.
I suppose the next photo-db generation will not be ported to OpenACS 3.2.4, but 4 level, right?
Now I can finally put my Sri Lanka pictures online. (Any month now
However, I get an "Access Denied" page when I try to reach /photodb/admin. Do you get this also?
Happy New Year to you all.
The data model sets up an administration group for the Photo Database System, but it doesn't put any users into that group.
We have some extensions to it planned for the next couple of months, mostly group scoping and allowing users to group photo's into galleries.
email me if you're interested and hopefully we'll get a download space set up this month.
I hope to modify it for artists works. I've been playing around and found a minor problem (see below), but I'm not sure if SDM bug reports are appropriate for this situation. So here it is!
The additional code for STATE ("None of the above") in photo-add.tcl and photo-edit.tcl works fine for data entry and successfully sets ph_photos.state = "".
The problems arise when using the Admin is checking recent addtions to the gallery (this brings up the gallery successfully) and then clicks one of the images to get single image plus details. The photodb/admin/photo.tcl has a SELECT which relies on
ph_photos.state = states.usps_abbrev
... which cannot match as that second table has no blank field, and the tcl returns the error condition "this form requires a photo_id".
Solution might be as simple as augmenting the "states" table or as complex as adding code and a new table allowing user entry of non US states. I'm taking the first alternative!
Second minor problem is a type mismatch between states.usps (char(2)) and ph_photos.state (varchar(2)). I have changed the type using
but would appreciate advice on any preferable method
Take a look at the /photodb/photo.tcl page. I made this
adjustment on that page, but I forgot to do it on the
As for the second problem - this won't come up anymore, since
we're not directly comparing the 2 tables, but I probably should
have made state a char(2). The problem is, if you enter a '' into a
char(2), when you get it out, it comes back as ' ' (2 spaces). So, it
doesn't look like an empty string. This is easy enough to fix by
doing a [string trim state].
You're right - this would've been made easier by adding a '' value
to the states table, or by getting rid of the state question
altogether, but I didn't want to change any tables not assoc with
photodb and I wanted this OpenACS implementation to look as
much like the ACS implementation as possible.
I'll upload the fixed version to the file-storage module today.
Thanks for the notice Lachlan. This is the first thing I've ported to
OpenACS, so I appreciate all the feedback!
The main issue is that since the states table doesn't have a 'null' or 'empty' entry, all joins will the states table will fail if photodb.state is null or empty. This could be fixed with an outer join, once those are available in pg7.1.
The workaround that I used is to query for all of the data about the photo without doing a join with the states table. Then later in the page, when we're about to show the location info, then we'll do a query on the states table - only if ph_photos.state is not null.
So this version should capture and preserve city, state, zip & country and also do the right thing if those are not present.
The interface is pretty nice - you can upload up to 6 pics at a time
or you can upload zip files (up to 10mb) and the module will
unzip 'em. It doesn't ask you to fill out captions when you're
uploading. Instead, you can add that data later on when you're
actually looking at the pic. (with photodb, you can only upload 1
pic at a time)
It has a nice slideshow feature that shows the pics and allows
you to edit the captions as you're going through the slideshow -
I haven't looked at it in depth, though, so there may be other
features that I missed.
I did have one problem. I'm on Debian and the latest
ImageMagick is 4.28 (even in Woody!). This version doesn't
allow the use of the -format flag, but Photo-Album-Lite uses that
flag. I just took the flag out and used a regsub to format output
properly for me.
I'm on Debian and the latest ImageMagick is 4.28 (even in Woody!)
It doesn't matter what Linux distribution you run, there are Linux binaries (gzipped tar) of recent ImageMagick (5.2.x) on the ImageMagick ftp mirror sites. Just configure the install script and run it. It'll write over the binaries of your crusty old Debian-provided ImageMagick and your system will never know the difference. I upgraded my Red Hat system the same way and I didn't void the warranty.
That's the one thing that I didn't try. I tried alienizing the rpms and
then I tried compiling from source - both times I was missing
certain libraries (and to be truthful, I didn't really try too hard to
figure out what was missing)
I'll give that a shot.
BTW, welcome back Sean - I've learned a lot from your posts and
it's nice to see you posting again!
The Red Hat ImageMagick RPMs always seem to be a couple of patch versions behind the Latest and Greatest (5.2.5 vs. 5.2.7) anyhow. I've been using ImageMagick for several years now and it's a software package that's worth keeping up to date on. In particular, the command line stuff really rocks. If you can make sure the newer ImageMagick binaries land on top of the old stuff, you shouldn't need to diddle with Tcl regexp in the ACS/OpenACS.
The big Linux distributions seemed to be heavily focused on the GUI tools (e.g., The GIMP, Electric Eyes, xv) and tend to ignore the command line stuff. Even a marketing moron like me can write a shell script that will convert the contents of a Master PhotoCD to 1.8 GB of TIFF files in a matter of minutes using the ImageMagick convert command.
Oops, there is no installation script for the ImageMagick binaries (I must have been thinking about something else). It's just a tar of the binaries. Normally, you would:
# cd /usr # tar -xvzf /var/tmp/ImageMagick-i686-pc-linux-gnu.tar.gz
You can create a temporary work directory, tar there, and test out the binaries before installing it into /usr. Sorry about the misinformation.
No problem - it was pretty self explanatory.
I initially tried the i686 download, but it didn't like my machine, complaining that certain libraries weren't built with the glibc2.2 (Debian Potato is based on glibc2.1, I believe). But I found binaries under the 'linux' folder which worked - ftp://ftp.cdrom.com/pub/ImageMag ick/linux/glibc-2.1/i386/ImageMagick-5.2.5-1.i386.tgz
Debian places everything in /usr/X11R6/ instead of /usr, so I did that, and then I just had to make a few symbolic links from /usr over to /usr/X11R6 cuz the ImageMagick binaries were still looking in /usr.
Now, to dig up all those picture CDs that I have lying around the apartment...