Forum OpenACS Q&A: photodb for openACS

Posted by Ken Mayer on 07/15/00 12:14 AM

Since the aD folks are too busy to release their photodb code, is
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
again.

2: Response to photodb for openACS (response to 1)

Posted by Don Baccus on 07/15/00 05:26 PM

e-mail Adam Farkas (mailto:afarkas@arsdigita.com) and ask him for help in getting the code in your hands ...

3: Response to photodb for openACS (response to 1)

Posted by Jesse Koontz on 08/10/00 05:42 PM

You can get a download of December 1999 and June 2000 version of the photodb here http://jkoontz.arsdigita.com/photodb-dev/. However, I would recommend you wait just a bit for the rewrite we are working on for photo.net's installation of the photodb ("the Gallery").

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.

4: Response to photodb for openACS (response to 1)

Posted by Adam Pennington on 08/10/00 09:04 PM

Actually, a slight correction on Jessie's post. I'm the person writing the image API backend which jessie mentioned, more up to date documentation for this (and a link to a package containing a few implementations of it) can be found at <a href=http://jkoontz.arsdigita.com/api-doc/procs-file-view?version_id=61&path=packages/image-api/image-api.tcl>http://jkoontz.arsdigita.com/api-doc/procs-file-view?version_id=61&path=packages/image-api/image-api.tcl</a> This is a newer version.

5: Response to photodb for openACS (response to 1)

Posted by Vinod Kurup on 12/29/00 06:50 AM

I just finishing porting the photodb module to openACS. I used the June 2000 version at http://jkoontz.ars digita.com/photodb-dev/

I've uploaded it to the file-storage module here at openACS.

Hope it helps someone!

6: Response to photodb for openACS (response to 1)

Posted by Anton Bajri on 12/29/00 07:20 PM

Thanks, Vinod!

I suppose the next photo-db generation will not be ported to OpenACS 3.2.4, but 4 level, right?

Saludos,

Jorge

7: Response to photodb for openACS (response to 1)

Posted by Ola Hansson on 12/30/00 12:40 AM

Thanks Vinod,

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.

8: Response to photodb for openACS (response to 1)

Posted by Vinod Kurup on 12/30/00 12:50 AM

Hi Ola,

The data model sets up an administration group for the Photo Database System, but it doesn't put any users into that group.

Login as the site-wide-admin and go to /admin/ug
Click on Administration
There should be an entry 'Photo Database Staff' - Click on that and add a user to the group. That user will then have admin access to photodb.

Can't wait to see the pics of Sri Lanka 😊

9: Response to photodb for openACS (response to 1)

Posted by Carl Coryell-Martin on 01/04/01 12:01 AM

Oops, We here at civilution finished a port of the photodb module a couple of weeks ago for the Green Media Toolshed. We did end up stripping out some outer joins and removed the camera and roll information since it was inapproriate for our audience.

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.

10: Response to photodb for openACS (response to 1)

Posted by Lachlan Myers on 01/04/01 01:32 PM

Thanks for the photodb for OpenACS ... its very exciting!

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

text(ph_photos.state)= states.usps_abbrev

but would appreciate advice on any preferable method

11: Response to photodb for openACS (response to 1)

Posted by Vinod Kurup on 01/04/01 03:24 PM

I wasn't sure of the best way to handle this. I think we should
take the states join out of the main query. The only reason we
want the states query is to find the long name of the state, so we
can just do a simple select further down the page, if the state
variable is not empty.

Take a look at the /photodb/photo.tcl page. I made this
adjustment on that page, but I forgot to do it on the
/photodb/admin/photo.tcl page.

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!

12: Response to photodb for openACS (response to 1)

Posted by Lachlan Myers on 01/05/01 12:41 AM

I agree - the states issue is probably an internationalisation issue that aD have almost certainly started to consider and we shouldn't try any quick fixes in any one module. So leaving it out makes sense at this point. But the photographers probably need some location data ... any thoughts?

13: Response to photodb for openACS (response to 1)

Posted by Vinod Kurup on 01/05/01 01:54 AM

Actually, I didn't mean that we should take that states information out, but rather that we should take it out of that specific query and instead query for it later in the page.

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.

14: Response to photodb for openACS (response to 1)

Posted by Lachlan Myers on 01/06/01 01:09 AM

And again, thank you.
It's a beautiful module to use!

15: Response to photodb for openACS (response to 1)

Posted by Janine Ohmer on 01/06/01 05:22 PM

Does anyone know how photodb compares to the Photo Album
Lite available from aD?

16: Response to photodb for openACS (response to 1)

Posted by Vinod Kurup on 01/09/01 01:51 AM

I just took a quick look at the Photo Album Lite and I really like it.
The photodb (3.x) is really meant for photo-enthusiasts, so it
asks for a bunch of details about each photo, like camera-type,
film-type, etc., etc. Photo Album Lite, on the other hand, is
tailored for the person who just wants to upload photos to show
friends and family (or whomever)

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 -
very convenient!

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.

17: Response to photodb for openACS (response to 1)

Posted by S. Y. on 01/09/01 02:11 AM

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. 😉

18: Response to photodb for openACS (response to 1)

Posted by Vinod Kurup on 01/09/01 02:23 AM

Thanks Sean,

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!

19: Response to photodb for openACS (response to 1)

Posted by S. Y. on 01/09/01 04:57 AM

Compiling graphics software on Linux isn't much fun (which is why I avoid doing it). There are a bazillion libraries to download, configure, compile, install, maintain, when all you want to do it open up a Kodak PhotoCD and write out TIFF files, JPEGs, and PNGs, do an occasional unsharp mask, change levels, add copyright info, etc.

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.

20: Response to photodb for openACS (response to 1)

Posted by S. Y. on 01/09/01 05:06 AM

Oh yes, libraries. If you have recent versions of libjpeg, libtiff, zlib, libpng (and possibly one or two others), you should be good to go, especially for web stuff. Basically speaking, if you can get <a href="http://www.helixcode.com/">Helix Code</a> GIMP to work, a recent version of ImageMagick should work too. I've never had problems. Rolling your own (i.e., compiling) is different story though...

Good luck.

21: Response to photodb for openACS (response to 1)

Posted by S. Y. on 01/09/01 06:17 PM

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.

22: Response to photodb for openACS (response to 1)

Posted by Vinod Kurup on 01/09/01 09:57 PM

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...

Thanks!