I have a lot of photos that aren’t shared properly, which makes them less useful than they could be. Considering that it has been possible to publish photos on the Web for over a decade, I find it interesting and annoying how many unsolved problems there still are.
I have a lot of old undigitized 35 mm negative photos and 10 cm by 15 cm paper copies sitting in boxes. I haven’t even solved the problem of digitizing those, so I’m not considering them further. (Of course, money could buy scanning to PhotoCD, which yields higher quality than random shops scanning directly to JPEG, but so far I haven’t been willing to pay. It isn’t cheap.)
I have a couple of thousand photos on Kodak PhotoCDs. I recently migrated them to JPEGs. I’m sure there was dataloss in theory, but in practice it is more useful to have a bunch of JPEGs around on a RAID than to have the data in a mostly obsolete proprietary format on CDs.
The recent data is, of course, from digital cameras that produce JPEGs directly.
I sometimes take my camera to parties, picnics and similar social situations. People usually like getting photos of the private gatherings they have attended, but some people don’t like it if the photos are available for all the world to see and searchable with their names. I don’t want to be viewed as a flickrazzi who invades in people’s privacy. Hence, there needs to be a way for limiting who gets to see the photos. In addition to the social need for access control, there’s also a legal need. Publishing such photos is illegal without consent of the people depicted.
When I travel, I take photos of places. I also take some photos of the people I travel with, but I consider those photos part of the previous use case. When the point of a photo is to show a place, I don’t want anyone posing in front of the place. This way, the place is neither obscured by a posing person nor the photo encumbered by the privacy rights of a posing person.
I think it is nice pictures and stories of where I’ve been with friends and family. The story part is important. When the viewers didn’t participate in the situation where the photos were taken, it is nice to provide some context textually. When the photos of people are factored to a separate photo set, the photos of places are suitable for publication on the Web without access control. They may or may not interest people, but when something is suitable for putting on the Web, it is uncool not to put it on the Web.
The previous use case leaves me with a bunch of photos of more or less famous places that may have surplus usefulness potential. That is, they might be useful to someone else in addition to fulfilling the travel documentation use case—hence surplus. However, if the photos sit on my hard drive they are really useful—hence potential.
So how am I doing with addressing these use cases. Not well.
Currently, when a share a social photo set, prune the set in the “Browser” view of GraphicConverter and then use GraphicConverter to generate a gallery with 120 px by 90 px thumbnails and 568 px by 426 px scaled down images. I afterwards, I add the gallery title and possible links to videos or full-size photos in TextWrangler. I upload the gallery to an HTTP server and limit access using HTTP Basic Authentication. Often, I have to edit the password file and the server configuration to create per-gallery credentials. Then I email the URL, the userid and the password to the people involved.
Doing the above is not hard, but it still involves the kind of drudgery that should be automated and that makes it easy to procrastinate.
I don’t like the details of how GraphicConverter generates the gallery. I don’t like its naming and placement of HTML files. I don’t like the lack of links to original full-size photos. However, it is still better than many other gallery generators. At least the galleries work with Opera’s Fast Forward feature. (I think checking if a gallery works with Fast Forward is the minimum bogosity test for gallery generators.)
However, despite the flaws of this approach, friends and acquaintances seem to like it. (Or if they don’t like it, they are too polite to tell me. But some people have explicitly commended my setup.) In particular, people seem to appreciate the privacy protection measure even if they sometimes complain about the passwords being too secure and not usable enough.
The travel case is a lot harder to solve, because gallery generators don’t integrate well with prose. I’ve tried to write text to go along with the photos. This rules out the usual gallery generators.
Last summer, I used generated an HTML skeleton of photos on a single page and used Nvu to add prose. I liked the result myself. Instead of having to wait for network when you are ready to move to the next image, all the images were loaded up front. The page could be scrolled with arrow keys, although scrolling didn’t snap to images. I also made a projection style sheet for Opera Show.
A couple of friends said they liked the photos. However, the vast majority of feedback was unusually negative. And the people who didn’t like the arrangement weren’t on dial-up or on GPRS. They had 100Base-T Internet connectivity and enough RAM to load the pages.
Since my attempt at coming up with a solution for this use case was a failure, I pulled the links to photo pages for my trips to France and Germany from my front page and didn’t bother to put the photos from the trip to California online at all (pending a better solution).
In case you are interested in what people didn’t like, here are links to the photos from France and Germany. (Follow the links at your own risk. :-)
I haven’t been addressing this case at all. I have considered how I could address it, though.
It’s amazing how many problems there are after all these years of photo-capable Web.
People buy cameras with so and so many megapixels and huge screens, but the photos are scaled down to about 600 pixels in width when shared. That’s just stupid!
When I visit a friend’s gallery of travel photos, I want a slide show that gives me the best that the camera and my screen can provide. Sadly, with most galleries this is impossible, because the originals aren’t available. Sometimes it is possible to use recursive wget to leech the originals that can be watched in a slide show. However, that’s not user-friendly.
And no, JPEG2000 is not the solution for adapting photos to bandwidth and screen size. With JPEG2000, you can truncate the bit stream anywhere and get less precision. Sounds cool right? Well, the problem is that if you want to decode only a quarter of the total number of pixels (width and height of the image halved), you have to pull half of the total image data. That is, you have to pull twice the number of bits that you’d have to pull if the server scaled and recompressed the image for you. And if you only want one sixteenth of the pixels, you still have to pull a quarter of the total image data, so compared to the server scaling the image for you, you have to pull four times as many bits. (Yes, I have test files.) And on top of that, there are the issues of installed base and possible submarine patents.
Even the Flickr slide show (Flash, eww…) shows small images. Still, I think the Flickr API may offer a remedy with time—even if the remedy will be Flickr-specific, which is uncool from the point of view of the Web as a whole. I’d like to be able to navigate to a Flickr photo set in my browser and be able to activate a bookmarklet which handed the URL to a helper app that did whatever Flickr API magic necessary to show the photo set as a full-screen slide show with image sizes appropriate for my screen.
I’ve already been reading Cocoa API docs. Perhaps one day…
Even if one forgoes the idea of one-click full-screen slide shows, often there’s no easy, one-stop way for downloading the whole photo set in full size.
The most uncool and annoying thing with online photo galleries
that too often you have to use a pointing device to get to the next
photo. That totally sucks. What’s wrong with the people developing
gallery generators? How hard would it be to generate a rel="next"
attribute on the link to the next image page?
When a friend sends me a link to a gallery of travel photos and the gallery does not work with Opera’s Fast Forward (would be nice to have in Firefox, too, BTW), I tend to view a couple of pictures based on thumbnails and then leave. If the photos seem really interesting (based on thumbnails), I might make the effort to leech them with wget. But I’m not going to click links to navigate forward.
Unfortunately, photos need human-entered metadata in order to be searchable by entering words. Digital cameras have made things a lot better by automatically recording the date when the photo was taken. Hopefully in the future cameras will automatically tag images with the GPS position where the photo was taken. (I’ve read that some camera phones tag images with the Bluetooth IDs of other devices that are in range when taking photos, but that is problematic from the privacy point of view.) Anyway, if you want your photos to be searchable for e.g. bunnies so that they could be used for vlogging, you need to enter textual metadata.
Data entry in itself sucks no matter how good the UI is. Unfortunately, the UIs suck pretty badly, making the task even worse.
In many desktop apps the UI for entering keywords and other metadata for photos is mind-boggingly bad. You have to open a dialog on a per-image basis! Sadly, even the tagging UIs of Flickr Uploadr and 1001 suck (in different ways). Flickr’s online tagging UI isn’t even on par with del.icio.us and Flickr—in theory—has more context available since a photo is likely to share tags with the previous photo.
I want a Flickr Taggr that gives me full keyboardability and as much context-aware autocomplete a possible considering the tags I have used, the tags I have used together, the tags I’ve used in the set being tagged, the tags others have used and the tags others have used together.
I take more photos than people care to look at. There are bad shots and redundant shots. Pruning the photo sets actually adds value.
The UIs for pruning redundant shots or picking the particularly good ones could be vastly improved. The current UIs just suck.
Then there’s the problem of sheer size of photos compared to text and programs. (Only serving scaled-down versions is uncool. See above.)
Having a few gigabytes of photos as part of your own site making backing up more difficult. It also make it more difficult to move between hosts or to respond to temporary hosting crises.
Since I hadn’t developed a solution for sharing my California photos in a year and since I wanted to address the Commons use case, I bought a Flickr Pro account a couple of days ago. (The California photos aren’t there, though. I already exhausted my bandwidth quota for this month. :-)
Flickr doesn’t work for the social use case, because I can’t make per-event credentials for mailing around. Also security by obscurity with photo URLs doesn’t not build confidence (see below).
As for the travel use case, I intend to give up writing prose. I’ll just dump the photos on Flickr.
For the Commons use case, Flickr works great. Due to critical mass, people know where to look. I chose the Creative Commons Attribution 2.0 license. (Flickr is stuck at 2.0. I’m not sure what ShareAlike would exactly mean for photos. Almost no one can tell what NonCommercial really means. Allowing derivative works is part of the point of sharing the photos.)
Flickr solves the size problem. There’s “unlimited” storage somewhere and keeping it running is Someone Else’s Problem.
The API.
Not paid per gigabytes downloaded, so no need to worry about people looking at the photos.
No storage limit.
Tagging. (As an experiment, I allow any Flickr user to tag my photos.)
CC licensing.
Generates scaled-down versions on its own.
Uploading is easy.
The Organizr is cool!
Reasonable upload quota (although not enough for bootstrapping with a large backlog :-)
Works as an off-site backup.
Flickr owns the URI space, so I will have to stay with them or break URIs. Cool URIs don’t change.
Removing a tag from a group of photos is tedious.
1001 does not normalize text data to NFC.
Flickr does not normalize text data to NFC.
Flickr Uploadr crashes.
Flickr Uploadr seems to upload photos in the reverse-alphabetic order. Why?
Original file name not preserved when downloading. I keep the titles ugly in order to match Flickr photos with my own records.
When downloading files, the metadata entered in Flickr doesn’t travel inside the file.
Can’t set a different license default for photos uploaded as private. (If you want to keep them private to friends, you don’t want to grant your friends a license to distribute.)
Security by obscurity: The private photos are available to anyone who knows the URL that includes a “secret” salt. There’s no HTTP auth or cookies required. For years people who are clued about Web matters have been saying that your private stuff isn’t really private if it is available via a plain HTTP GET. For example, Google could use the Google Web Accelerator to harvest URLs that a normal crawler does not find.
Private photos hosted outside the EU.
Lack of a really good UI for marking photos as redundant junk or picking out particularly good photos.
Lack of a really good tagging UI with full keyboardability and autocomplete.
A bug in Organizr makes the UI hang on multiple selection in some cases.
P.S. I really should have a comment system on my site…
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。