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.
New Picasa 3 Beta Awesomeness
Last weekend I was playing with the new beta of Google Picasa 3, including the new Picasa Web Albums.
I’ve used the Picasa 2 desktop photo management software for a couple years now, and been mostly happy with it. It can upload directly to Facebook, and it’s not too hard to upload to my Gallery 2 site either. However, I’ve never seen the point in paying for the Picasa Web Albums photo hosting service, when I can host my own photos on my own site for no extra charge.
That changed last weekend, when I discovered the Name Tags feature in Picasa Web 3. This is what I thought Facebook was doing a while back. The idea is simple: after you upload your photos to Picasa Web, Google detects all the faces in the photos, and asks you to name them. Google then uses facial recognition technology to guess the identities of future occurrences of the same faces.
Once you’ve tagged your photos thusly, all the cool Facebook features related to photo tagging are available, like sharing photos of people with the subjects therein, grouping photos by the people in them, and (most important to me) capturing for posterity the identities of the people in the photos.
It’s still beta, and some of the face detection and recognition stuff is weak, but when that is ironed out I’ll gladly pay $25/yr for 10GB of storage so I can migrate my photo collection into Picasa.
I do have one feature request for the devs: let me use my existing Gmail contacts as possible labels for my photos. Having to type names and email addresses a second time blows.
Project Idea: Face detection in Gallery2
This past weekend my little sister and I were going through the Facebook profiles of various cousins, and I noticed something about Facebook’s photo support that I somehow missed before: it automatically detects the presence of faces in each photo, and allows users to tag each face with the identity of its owner. Already-tagged faces have the owner’s name superimposed over the image.
That’s an awesome feature, and reminds me of the stuff Riya was working on a few years back (although FB doesn’t do facial recognition (yet, anyway), so you still have to tag everyone yourself). I was immediately jealous that my photo hosting software of choice, Gallery, didn’t have this feature.
I investigated this a bit, and I found that Intel’s OpenCV library includes open-source face detection code. Using Intel’s sample face detect app, I found it to be both quick (~150ms per photo) and accurate. I wonder how much work would be required to create a Gallery module that used opencv to detect faces in photos, and provided an AJAX UI for tagging the photos. It would certainly be cool.
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.
Gallery 2.1 RC2a
I just noticed that the Gallery project has released RC 2of Gallery 2.1. This version finally includes support for hidden items (photos and albums which are not visible to guests browsing albums, but are accessible to guests if they know the direct URL of the item), and password-protected albums and photos. Both of these basic features are handy for sharing photos with a limited group of people, but not everyone.
The download was uneventful; I extracted the tarball over my existing 2.0 installation, as per the upgrade instructions. I then navigated to my gallery, and was greeted with an upgrade wizard.
After authenticating with the setup password, step 2 of the wizard is an environment check. There were no reds, but I did get some warnings:
Warning: Output buffering is enabled in your php by the outputbuffering parameter(s) in php.ini. Gallery can function with this setting – downloading files is even faster – but Gallery might be unable to serve large files (e.g. large videos) and run into the memory limit. Also, some features like the progress bars might not work correctly if output buffering is enabled unless iniset() is allowed.
and
Old files (3328)
These files are no longer part of Gallery. They probably won’t cause any problems but it is a good idea to remove them to keep your install clean. Gallery can’t remove these files for you, but you can download and run this script in your gallery2 directory to delete them for you.
I’m not sure why output buffering is enabled; I certainly don’t want my server output buffered, for just the reasons the warning mentions. The old files I’ll take care of later.
A quick edit of /usr/local/etc/php.ini:
output_buffering = Off
does the trick. Of course, apachectl restart to restart Apache is required before the changes kick in.
In the next step, the updater was unable to write to config.php; this is not a surprise, as I chmoded it after the initial setup. I’ll put it back to chmod 0666 just for the upgrade.
Step 3 went fine; putting config.php back to chmod 0444.
In Step 4 I elected to upgrade all installed modules to whatever the latest versions are. Apart from a warning that “ImageMagick module needs configuration”, all module upgrades were green.
That was it. All the other steps were without incident. The final upgrade screen said to go to the site admin to upgrade any other modules; I’ll have a look there to see if anything needs to happen…
The only module with an ‘upgrade’ link is ‘ImageMagick’. I clicked ‘upgrade’ and got ‘Successfully upgraded module ImageMagick’; too easy.
Next, I installed and activated the Hidden Items and Password Items modules, the availability of which is the only reason I upgraded at all. Once these modules were activated, I could use the Edit Item function on my albums and photos, and find two new sections: one with a check box to make the item hidden, and one with password boxes to set a password to view the item. Outstanding!
The hidden feature works flawlessly. The password feature has one gotcha that I can see: if the guest user does not have permission to view an item, then the password prompt just continuously reappears, without any indication of the problem. It could be argued that this is a security feature and not a bug, but I think a minor security tradeoff would be worth the usability boost. Oh well.
It seems the ImageMagick module is broken, as it shows up with a red circle w/ a line through it. Upon further investigation, it’s disabled itself because the version of ImageMagick I have, 6.2.2, has a known security vuln. I’m trying to upgrade it via a FreeBSD package, but I can’t find one handy. The vuln is an infinite loop on an intentionally malformed image; since I trust everyone w/ image upload privs, and an infinite loop isn’t a serious compromise, I’ll override this security warning and force the module to use the vulnerable version.
It also seems as though the upgrade, when it purged the cache, killed the thumbnails, so I’m using the Maintenance function in the site admin tool to rebuild the thumbnail/resized copies of all the images. Now that I turned buffering off, this produces a meaningful progress bar, which is kind of novel.