I really wanted to move my photo hosting to Picasa Web Albums, on account of the awesome new face detection/recognition feature they have in beta, but in the end I was swayed by value.

Here’s the price schedule for Picasa Web Albums:

• 10 GB ($20.00 USD per year)
• 40 GB ($75.00 USD per year)
• 150 GB ($250.00 USD per year)
• 400 GB ($500.00 USD per year)

Here’s the schedule for Flickr:

• Unlimited ($24.95/yr)

Since I’m almost at 40GB, inside of a year I would be spending $250/yr for Picasa storage. Sorry, but face recognition coolness isn’t worth that sort of a premium.

I’m currently in the process of migrating my entire gallery over to Flickr using the Gallery2Flickr plug-in for Gallery 2. It’s slow going; I’ll have a separate post about the jigger-pokery required to make that work. Once I’m done, I’ll use my Gallery 2 install solely for hosting photos for my family, which is a small enough dataset that I can fit it on my VPS without difficulty.

This was pretty disappointing, so I uploaded the same corpus of photos to Facebook to see how well it did with them. Imagine my surprise when it didn’t detect any! The face detection I was seeing on my sister’s profile was due to manual tagging of the photos from within the upload applet, and was not driven by computer vision algorithms. That explains that.

I still think a similar feature in Gallery would be nice, but with the CV aspect removed it doesn’t seem quite so fun.

In the config.php file in the gallery2 install folder, there’s a line that sets the debug mode. By default it’s:

$gallery->setDebug(false);

For debugging I changed it to:

$gallery->setDebug('buffered');

and reloaded the Gallery main page. That displays a shitload of debug messages at the end of the page. In my case, I saw the familiar MySQL message about a table being corrupted. This time, it was g2_CacheMap. I did a quick repair table g2_CacheMap in mysql, and voila!, Gallery is back up.

insha’allah, this is the last such problem.

In /usr/local/etc/php.ini:

; Maximum allowed size for uploaded files.
upload_max_filesize = 512M

Let’s see what happens…

UPDATE: Nothing happened. The latest beta of Gallery Remote seems to not care for enormous video files; it just hangs at ‘Preparing to upload…’ indefinitely. I’ll have to FTP my videos up for the time being.

PHP Warning: POST Content-Length of 8503267 bytes exceeds the limit of 8388608 bytes

In /usr/local/etc/php.ini there’s this line:

  ; Maximum size of POST data that PHP will accept.
  post_max_size = 8M

8M seems plenty, but apparently there’s a helluva lot of overhead associated with uploading an image. I’ll double it, to 16M:

  ; Maximum size of POST data that PHP will accept.
  post_max_size = 16M

Hmm….the error msg is gone but I’m still getting meaningless ‘upload failed’ errors…I think the error msg was from a couple of MPEG videos which were in fact more than 8MB; my photos are <3M but still failing…
I’ve uncommented error_log = syslog in php.ini; perhaps that will clarify things.
No; nothing new in httpd-error.log…
Aha, there’s another php.ini settings. post_max_size is the maximum length of the POST form data, but upload_max_filesize controls the max size of a single file uploaded via POST. On bonzo, it’s 2M. I’ll make it 16M:

  ; Maximum allowed size for uploaded files.
  upload_max_filesize = 16M

Yup, that did it. Works now. I wish the error msg would’ve been somehow apparent; it’s as though Gallery or PHP simply eat the failure.

“An optional part of Gallery Remote, ImageMagick, could not be found…”

This is due to my inability to follow instructions; the docs specifically use the short form of the path, with ‘~1’s and all, presumably because spaces in file names are too much to handle. So:
im.convertPath=C:\Progra~1\ImageMagick-6.2.5-Q16\convert.exe
Hmm, same message. This time I even ignored the comment in the im.properties file directly above the line I was editing:

# path to the convert executable installed with ImageMagick, including the name of the executable (jpegtran)
# use forward slashes (/) rather than back slashes (\) even on Windows

So, forward slashes matter too:
im.convertPath=C:/Progra~1/ImageMagick-6.2.5-Q16/convert.exe
That seems to work. Now let’s see if it resizes faster on the client…