Migrating gallery from Gallery2 to Flickr
I’m finally moving apocryph.org over to FutureHosting from DreamHost. I’ve put it off for so long because my 35+GB photo gallery will be a real pain to move over, and will use most of the 40GB of storage I have allotted on one of my two VPS accounts.
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.
Lesson Learned: Face Detection is Hard
A while back I thought it would be a good idea to implement face detection in Gallery2, based on a similar feature in Facebook. I downloaded the OpenCV computer vision toolkit and ran the facedetect sample app against a collection of 60 photos from my gallery, some with no faces, others with a single face, still others with multiple faces, faces in profile, etc. No matter which training file I used, the face detection was horribly unreliable. I would estimate 10% of actual faces were detected, and of all the faces reported by the tool, maybe 5% were actual faces.
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.
Upgraded Gallery 2.1 RC2a to Gallery 2.2 RC1
I just upgraded the Gallery install on bonzo to 2.2 RC1, which has some cool new features like dynamic albums, and (supposedly) performance improvements. It seems to have worked fine.
More fallout from disk full problem on /var
A while back I had some problems with MySQL running out of space on /var. Today I found out my Gallery2 was down, responding to all requests with “An error has occurred while interacting with the database.”
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.
How big is too big for upload_max_filesize?
I recently kicked up the upload_max_filesize parameter to 16MB so I could upload big 7MP images. However, now I’ve taken to shooting incriminating video with my Z750, which gets into the hundreds of megabytes. So, how big is too big? I’m going to try 500MB.
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.
Can't upload large files to Gallery2
When I upload large files to Gallery (meaning roughly > 2MB) from Gallery Remote I get an upload error. Upon checking /var/log/httpd-error.log, I see:
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.
Gallery Remote and ImageMagick
I installed the new Gallery Remote 1.5 on Prospertine, so I could upload some pictures. When I was researching the upgrade to Gallery 2 that Gallery Remote 1.5 was alot faster if you install the latest ImageMagick on the client, so it can pre-process some of the image stuff.
I downloaded ImageMagick 6.2.5-2-Q16-windows-dll, which is the 16-bpp dynamic version for Windows. From this article, you have to munge the im.properties file for Gallery Remote in order to make it use convert.exe in the ImageMagick distribution.
I opened c:\program files\gallery remote\imagemagick\im.properties as instructed. I set the im.convertPath to:
im.convertPath=C:\Program Files\ImageMagick-6.2.5-Q16\convert.exe
Not surprisingly, this didn’t work; instead I got:
“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…