The New FujiChrome: Fujifilm-X and Chromebook

I've been experimenting with the latest breed of Google Chromebooks -- unlike their predecessors, these new Chromebooks can also run Android apps, placing them somewhere between a laptop and a phone or tablet in functionality. Of course a new under-$400 Chromebook is no match for a full-powered $2000+ laptop as a photo workflow machine... right?

Chromebook as a Photo Workflow Computer: Challenges and Opportunities

This article presents a little guide for how you can use a modern Chromebook with your Fuji (and other) digital cameras, and a comparison against a common alternative: a Mac laptop. It's an ongoing project, and several people have already chipped-in valuable advice.

The illustration above shows the “picture flow” possibilities of using Fujifilm X-Series cameras and a Chromebook. The green-shaded nodes in this chart represent places I think of as “end points” in the workflow-- where photos are either stored or shared. Photos flow from the camera to one or more of these end points (or into the trash!).

The blue arrows and blue-bordered boxes show parts of the process where we can exploit Chrome's new Android apps, while the orange arrows show connections via Chrome web browser.

I’ll go through workflow options in more detail later on. It might look a bit complex, but compare to trying to post photos from your Mac directory onto an Instagram story...

The $350 Challenger

In my tests, I’m comparing an ARM-based Samsung Chromebook Plus versus my aging-but-excellent 13” Macbook Air. The Macbook came with all the goodies, and rang in over $2000. The Chromebook was on sale at Amazon for about $350.

A careful look will show that the workflows in the diagram are similar to what you might use on a good tablet like an iPad Pro or a big Samsung -- and they are. But the tablets come at a higher, premium price. Somehow, the Chromebook manages to keep the price down while still delivering good functionality. The Chromebook also has multiple USB ports, for making file transfers between storage devices simpler.

The Goals

To provide a legitimate alternative to the Mac, a new system should be:

• Cheap: if the device is stolen or smashed by a luggage handler I’m not heartbroken
• Lightweight: can a usable system be even lighter than the Macbook Air?
• Working: gets the job done, isn’t flaky
• NOT FIDDLY: no complicated setups or CS degree required
• Cloud-centric: online, mobile-forward, all current buzzwords supported
• Secure: No personal data stored on the device
• Compatible: It works with my main long-term library.

So far I’ve found that using the Chromebook delivers on all points save the flakiness. The flakiness I’ve experienced thus far has centered entirely on the Fujifilm Camera Remote app itself -- sometimes it connects, sometimes it does not. Right now the “not” is the majority of my experience.

It’s also true that there is a little fiddliness -- mostly around restrictions on Android apps with respect to external storage devices. We’ll get to that later on.

Comparative Advantages

Workflow

Camera wireless options: If you're transferring photos wirelessly, don’t forget about transfer-time resize in the camera menu! The camera may be resizing your pictures to optimize speed and phone memory. Each camera is slightly different, but on X-Pro2 and X100F you'll find the important option in the "Wrench" menu under "Connection Setting" then "Wireless Settings" and then "Resize Image for Smartphone 3M" which can be on or off. If you want the original-sized images from Fuji Camera Remote, be sure to turn this off, at the price of slower transfers.

WiFi Connection Issues: I wish I knew what causes the intermittent connection failures I’ve had using Fujifilm Camera Remote from the Chromebook. It either connects and all is well, or it refuses. It might be my X-Pro2, I've had no issues with the X100F. I’ve had great luck with Camera Remote on other Android tablets, phones, and iOS devices too. When it does connect, it works brilliantly.

If a universal solution for inconsistent connections presents itself, I'll be sure to add it here!

Fujifilm Camera Remote provides a crude sort of tethering control over the camera from the laptop -- not just the X-T1 and X-T2 cameras, but any reasonably-modern X camera, like the X-Pro2 or the X70. I wish there was more focusing control in “manual” mode -- you may find, as I have, that it’s good to keep around a few mechanically-focused lenses, like the 16mm f/1.4 or an adapted film-rangefinder lens. But at the same time, using the touch-screen with AF is pretty swell for any lens, and an option not available any other way for most X-cameras.

Physical Media: While Camera Remote can be used to transfer files from the camera to the laptop, it’s a slow process compared to using an SD card. Wireless transfer is also restricted only to JPG files. If you want RAW, you’ll need to use the SD.

One option is to connect the camera directly by its USB port to the computer -- alternatively, you can pop out the SD card(s) and read them by the appropriate adapter.

The Chromebook has a built-in Micro-SD reader, so a hub or reader is needed, or a micro-SD-to-SD adapter. I don’t trust SD adapters for cameras, though I’ve never had a failure. I’d rather have a one-piece SD card. I purchased (for another $50) a USB-C hub that acts as an SD reader and also provides an HDMI-out signal, to add a second monitor.

Transfer-Speed Comparisons

Both the Mac and the Chromebook have curious external-drive limitations. The Mac cannot write to Windows-style NTFS files systems without a special plugin, while the Chromebook cannot write to Mac-style HFS+ drives. Both can read both types. For a speed comparison, I chose to use a 250MB Samsung T3 SSD device, formatted in ExFAT.

For test data, I shot 118 RAW+Fine photos using a Fujifilm XT-1 -- the result is about four and a half GB of mixed data written to a 32GB Lexar Professional 2000x card.

Upcoming: I will try to compare speeds of direct connections from various cameras to the computer. This requires a lot more-tedious testing since each camera may be different.

The timing below are how long it took to copy all the Fuji files from the card to the external drive, using regular operating system tools.

For the Mac, the card was plugged right into the computer. For the Chromebook, I used a Letscom multi-port hub. For both tests, the external drive was plugged into a free port on the computer.

Chromebook Plus	Macbook Air
Via Letscom USB-C hub	Computer's Integrated SD Reader
4:33	0:48

In other words, the Mac was about 5.6x faster than the Chromebook when transferring from one external device to another external device. I'm not sure if this is due more to processing power or just a different, simpler USB bus.

While this variance can make a minute into minutes, if you're primarily a JPG shooter this might not make much practical difference for photo collections of about this size or smaller. JPGs are typically about 10% the size of the matching RAW file. So a few seconds turns into a minute. Considering that the "fixed cost" of setting up the laptop and hard drive is already about the same amount of time, for many uses the effective difference may not be that much.

Copying just the JPGs of those 118 shots took about a minute on the Chromebook. So with one minute of setup time, that's two minutes versus less than a minute and a half total. Slower, but not tragically so for a single batch of photos. You can decide for yourself.

All that said, if I habitually shot in RAW or shot weddings or events with thousands of photos, I'd be leery of runny backups on the Chromebook unless I had a lot of time to burn on archiving ("time to burn" as in: start the transfer, go to dinner, stay out for drinks... come back to discover whether the transfer is complete yet).

Everyday casual shooting: yes. High-volume: ouch.

RAW (err, RAF) Files

I was also surprised to find that the Chromebook Files app could actually recognize Fuji RAF files, and would (slowly) load their thumbnails -- a feat the Mac won't perform without additional plugins. The Chromebook Gallery app, unlike Mac's Preview, will happily open a Fuji RAF file, and even offer to edit it (the results are saved as JPG).

Picture Editing

You can edit pictures on Chromebook using either web apps or Android apps. The Chromebook plus has another advantage here over the Mac -- it’s a “convertible” laptop, meaning that it can flip open to become a full-screen Android tablet, complete with the excellent S-Pen pressure-sensitive stylus.

Web apps like Polarr can do an acceptable job of editing JPG files. Polarr also has an Android version of their app, so you can try both and see which you prefer.

Android-only apps are also available, and some, like Snapseed, can even edit RAW files. I haven’t found much use for Adobe’s Android versions of Photoshop and Lightroom -- despite my long-standing allegiance to their Mac and PC apps.

Web apps have an advantage over Android editing apps in that they can access any storage attached to the Chromebook -- for example, they can load a JPG directly from the SD card. Android apps are not allowed to access external storage, so you must first copy your files to the Chromebook’s storage, which is limited compared to the size of many SD cards.

This restriction is also important if you want to export your photos to Android-centric apps like Instagram or WeChat. Those apps can only access files from the Chromebook local drive, so if you do edit a file from an external drive, be sure to save the edited copy locally, before sending it to those services.

The Android option does give you a lot of functionality, though, such as the ability to send your photos as WeChat Moments, or to be included in Instagram stories -- features that would otherwise be unavailable without a lot of extra fiddling with your PC and phone or helper apps.

Saving photos to a cloud-based service like Google Drive or Dropbox gives you the most options but at the cost of waiting for uploads and downloads.

A Note on Color Profiles: if you have photos that you are editing for use on the web, use sRGB Color Space. Using AdobeRGB or ProPhoto or any other profile may result in having saved results that look quite different from shared results. See this page for more info on the hazards of using color profiles that are not the now-universal sRGB standard.

Chromebook + Mac (or PC)

Via Chrome Remote Desktop, you can connect your Chromebook to the screen of your home or office Mac or PC, or even to a Linux machine. This means that if you've sent your files to the cloud, you can use your home machine to edit them, and see the results as you go, right on the Chromebook. As much as I love Snapseed, sometime I really truly do need Photoshop. Remote Desktop's not always fast, but it really is possible to shoot on my X-Pro, send the result to a far-away Mac, edit in Photoshop, send the result back and “Send a Copy…” from Google Drive to Instagram.

Remote Desktop Hint: You can set the Chromebook's screen resolution before connecting. Use the Ctrl-Shift-Minus or -Plus keys to adjust it. The Chromebook Plus can display an image up to 2400x1600, but for performance has been set to a default of 1200x800. At the cost of speed, you can display a quite large screen from your remote machine -- great for LightRoom or Adobe Bridge usage.

Printing

A Chromebook using Android has direct access to Instax printing via the Instax Share app -- another feature unavailable to Mac or PC. It works just as it does on a phone. Personally I love bringing an Instax printer whenever I travel, the little prints make terrific and often treasured "leave behinds" for the people I meet.

Both Mac and Chromebook can also print full-sized documents remotely using Google Cloud Print, but I find the results less than stellar. If you’re going to use a “big” printer, it's best to see what you're doing, and use a Mac or PC that’s co-located in the same room with the printer. If you’re traveling, the Instax is a stellar addition to your kit bag.

Of course, you can also just send the JPG files from either Chromebook or Mac to a commercial printing service's web page.

Non-Fuji Cameras

These notes describe my Chromebook-based process using Fuji cameras, but there are a few alternative camera brands that may also work well -- as an example, Olympus provides its own camera control app called Oi.share. A Chromebook can make a nice bridge for any digital camera user who wants to connect easily to Instax & other services. If people try out these other systems with Chrome OS, please drop me a line!

The Mac-Only Version

Recasting the diagram above for Mac shows a simpler, but narrower network of possibilities. The Mac gains in directness and hard-wired speed, at the expense of losing the Chromebook's wireless applications and destinations (Including Instagram, whose web-based version is rather poor compared to the mobile-first Real Thing).

Chromebook Software Tools I Use

In the chart, some nodes provide a suggestion, though there may be many alternatives. Here are some Web and Android apps that I’ve found really useful when dealing with photos on Chromebook:

Clarifications

Romantic Heart

December 2010

More Apples

Found in the phone backups -- December 2010

Upgrades

Third St Almost to Minna

It’s been a while since I’ve written about the web tech of botzilla or random photo gear issues. No time like the present.

First off I’ve been slowly updating all of botzilla to use more modern web frameworks, which happily work well with the ratchety old Moveable Type backend. The blog portions were easy to complete, the older Powershot & Streetphoto archive bits will come soon enough. I’m also rearranging some of the tag bins, mostly to reflect the changes in botzilla intent since the original charter.

Given the general growth of the blogosphere since botzilla’s early day, I doubt that anyone other than myself will really notices these changes.

On the camera front, my Canons are being retired, along with my TLRs and Bronica rangefinder (one TLR, the Bronica, a 5D body and a couple of lenses are still for sale!). I initially intended to replace them with the latest Leicasonic LX (LX-7) and later a Fuji X100s… to my surprise the littler of these little cameras was dominant for a while, though over time and practice I’ve come to use the X100s more and more, eventually supplanting it with an X-T1 which is terrific and provdes a second career for my Contax lenses, but the X100s is still doing the bulk of my shooting as of September 2014.

Like everyone, I’m also shooting a lot with my phone, occasionally with a tablet, and intermittently with Google Glass. More entries to come on all of these technologies as I stumbled along ahead.

JavaScript: The Bad Parts

Web Geek Warning

Last night I headed over to the Paypal/EBay offices to see a presentation by Douglas Crockford, titled Programming Styles and Your Brain

I'll admit that I was a little bit skeptical about coming away with much useful information (a general rule: be cautious around tech companies that have had near-zero evolution since, oh, 1995), but in fact the debugging bits were pretty illuminating. Here are some sketchy notes:

Your Brain

Crockford’s lecture had about five introductory minutes of broad speculation (he's earned the right!) mixed with notes cribbed from Daniel Kahneman…

• Computer programs are the most complicated things humans make
• Humans suck at making such things
• They make mistakes
• They confuse “hardly ever happens” with “never happens”
• They confuse reading two threads on a jquery forum with an education
• They write in C++ when the language is not C++ (or Java, HLSL, python, Mel, Fortran…)
• They mistake complex obscurantist “cool” with professional “clear” coding
• The human is almost always the limiting factor in software
• Being consistent in style is the easiest way to avoid common errors (especially forms that are difficult to distinguish rom errors, which in JS are many)
• Anyone can program, few can debug

JavaScript

This was the expected real bulk of the presentation, a longer not-veiled pitch for JSLint and his book “Javascript: the Good Parts” -- especially about how to avoid the bad parts:

• Auto-semicolon closure. This burns people so, so, much, and is one reason where it really does make a difference (for polyglot programmers) to get in the habit of putting the curly open-brace to the right of the if() clause on the same line, rather than on the line below – just like K&R intended.
• Stupid multi-line strings that use “\” at line breaks because the parsers don’t recognize trailing spaces and the editors don’t show them.
• Mistaking the scope of “var” to be block scope (like C, python, etc) – it’s function scope, so avoid declaration-inside-the-block constructions like for (var i=0;…) { … } because it won’t get declared where you think it is. I know I make this error a fair bit.
• Make global variables REALLY_OBVIOUS. Since there are no macros in JS, THIS_IN_ONE_WAY (clearer than, say, Hungarian). In general avoid globals, except that you can’t because that’s how modules link (no linker).
• If using immediate-invocation functions, put the final () inside the encapsulating () parens – e.g. (function() {…}()); not (function() { })(); – the latter wrong construction he called “dangling dog balls style.”
• Avoid “==” because it does type conversion and different interpreters convert differently! Is (‘’==0) true or false? Use “===” instead, for a direct comparison.
• Avoid the “switch” statement or at least be obsessively diligent about having break statement in every clause -- and having a default case.
• Avoid the “with” construct. Consider: with (o) { foo=koda; }
  does it mean:
  • foo=koda;
  • o.foo = koda;
  • foo = o.koda;
  • o.foo = o.koda;
  ??? Different interpreters DO give different results!
• var a = b = 0; in JS is the same as /*global */ b = 0; /*local */ var a = b; -- NOT like C.
• Not only are “var” declarations hoisted to the top of the function scope, so are function declarations. So beware dependencies that are not resolved! NO ERROR WILL PRINT. Better to just put the var and function declarations at the top of the enclosing function
• Avoid the “new” pseudo-class construct, not because it doesn’t work but because people often forget to write “new” and then they may accidentally trash that global class-like definition and you are hosed. Just use simple {objects}
• If you have constructor functions indicate them “LikeThis()” to distinguish them from “all_other_functions()”
• Avoid “++” which is a leftover from pointer arithmetic days. Just use “+=1” it’s just one more character to type, using “++” doesn’t make you more efficient, it makes you sloppy (especially when few people remember that i+=1; is not i++ -- it’s ++i;)

The Bad Parts?

So how does the Javascript on Botzilla stack up? Let's just say, it's an ongoing learning process!

In scanning the scripts here (and at Trion), there appear to really only be a couple of idoms that I need to stamp out from my code to make the analyzer happy. What's yet to be determined is if Javascript's scoping rules will ever really make sense...

Black

Fluid is the new Black goes the saying of the day, but for Botzilla the main message is: get over it.

By that, I mean that if the site needs to work on all possible screen sizes, for future-friendly leanings, then: the pictures are just going to have to be small. And there's the rub for a photo site -- when the pictures are reduced to being upgraded versions of the thumbnails, not the other way 'round. This is tough, and frankly I won't give up without a fight for getting the best possible photographic presentation into place.

At the moment, I'm getting cozy with this little bit of CSS:

img { max-width: 100%; }

Which is a trick to ensure that images are resized downwards as their containers shrink.

The obstacle on a site like Botzilla is that most photo <IMG> tags have both WIDTH and HEIGHT properties specified, so that when displayed on a small screen, "max-width" alone doesn't get you very far -- the images don't scale uniformly down, but instead simply compress horizontally, untill they're long tall sticks.

JQuery to the Rescue!

Including this as the first line in my ready() function does the trick:

$("img").removeAttr("height");

All Minds Think Alike

I'm a bit annoyed at the realization that my most-recent post on fiddling with HTML5 canvas in Moveable Type looks and behaves in a way that's terribly similar to the page header on the official Google blog. I must have seen that before... we rarely know where our ideas and parts of ideas come from! Or is it merely "parallel evolution"? Still, it's not as if I'm launching a product, and hardly expect Google's IP lawyers to appear on Botzilla any time soon (hi guys).

And I like their "version" of the interactivity -- ONLY let the mouse have an effect when moving. Will have to check that out on a tablet.... of course, when they're creating a brand presence for a company with.. what, 30,000 employees? you would only expect that they'd take a little more time on polishing than my slice-of-a-Saturday attempt. Pat on the back, lads.

While not posting for a few days, I've been scraping at Botzilla's underlying CSS structure, so that I can rebuild it once more with CSS that will allow a fairly seamless multi-screen experience -- PC web or mobile phone/tablet. This has meant I've already had to update (internally) my use of jquery to use jquery-mobile, have started playing with Modernizr for those stodgy users who insist on running IE, and trying to make peace with myself over the idea that photos that I felt barely look okay 800+ pixels across will just have to be acceptable at mobile-phone sizes.

More to come as this gels.

791

One more for a Saturday -- see if you can push all the balls off-screen at once! (and no, it won't try to sell you car insurance)

Everything here, on the JS side, is set up using a shared array of initializer functions, just like the previous entry on that topic.

Next step might be to re-cast it as SVG... amazing that SVG seems really powerful, but compared to <canvas>, theres' almost no really good documentation...

HTML5 (& JQuery) vs Moveable Type, Part 2

Following up on the previous post, here are the details on a simple way to add multiple dynamic scripts to a Moveable Type index page.

Like the previous post, try using your mouse on this one! Can you slow down the particles?

Basically, we just need to add an (initially empty) array of function references to the page templates, which we'll use to capture each blog entry's unique scripts (rather than letting them launch themselves), and then iterate on that array for the entire page, once it's loaded and ready.

I'm using jquery, so I declare the array and my $(document).ready() function like so:

var gRActions = new Array(); // initially empty array of functions...

$(document).ready(function() {
  for (var a=0; a<gRActions.length; a++) {
	gRActions[a]();
  }
});

Then in each blog entry, I write the same anonymous javascript function as I might write for $(document).ready(), but instead I just push it into gRActions:

gRActions.push(function() {
   draw_canv739();
   setInterval(draw_canv739,30);
});

Now the page, regardless of how many blog entries it might contain, will include all of them in its page initialization. Remember also to make sure that any "global" javascript values (including function names!) in this entry, and all HTML elements like <canvas>, have unique names so that they won't collide with other blog entries, should they for some reason both be presented on the same HTML index page someday.

Also, as we've learned from the previous post: put some human-readbale text into the post before the scripting portion of the post, otherwise Facebook becomes confused.

HTML5 Canvas vs Moveable Type

With a little fiddling it's easy enough to use <CANVAS> (and jquery) in tandem with Botzilla's somewhat elderly (and modified) installation of Moveable Type.

Minor tricks:

• Remember to suppress Text Formatting -- no automatic <P> tags
• Between different blog entries, don't reuse variable names, or element names, if you think you might ever need to have multiple canvases on the same page (say, in index or search pages). You will disappear into the fourth circle of scoping hell.
• Likewise, if you think that multiple canvases per page is a real possibility, then put each canvas's prep and render code into a distinct function, so that you can move your onload() or $(document.ready() functions into the header template, not the body of the entry itself. In the header, declare an initially-empty array of functions, and have your ready() function iterate through them.
  Then in each scripted entry, add your entry-specific render function(s) to that array. This way, the ready() function can just know what's needing to be set up for the specific page, regardless of which entries are being displayed and the # of visible canvases (A perusal of the initial state of this entry will show that I don't always follow my own advice. But adding that feature to Botzilla is one of my next steps). Be sure to put that array and calling function into all of your index and entry templates!
• Linked sites like Facebook won't show <Canvas> or other animating elements, so if you want a good thumbnail, try adding a hidden image like so: <IMG SRC="/photo/journal//may03e-15.jpg" STYLE="display: none;" />
• MT's preview page doesn't have all this extra js etc built-in. I suppose you can add it, and I probably will over time -- but as a quick workaround, to get a preview, I save my entry, press "Publish," then immediately look at the front index page -- if there's anything wrong, immediately change the entry state back to "Draft" and save again. This will remove the entry from the front page and the RSS feed, but: the "permalink" actual page file (in this case, "/blog/archives/000738.html") will still be there on the server! Download it and debug locally, then transport your changes back into MT. A bit of a shuffle but it's a workflow that can get you from points A to B.
• Beware trying to test-post to Facebook, changing the contents of the blog entry (even for typos) and trying to post it to FB again -- FB caches everything the first time, so... if you want a change that will appear there, you need to make a new copy of your entire post, publish that, and hide the old one (how do I know this?).
• Google+ is smart enough to recognize the difference between javascript blocks and actual human-readable body text. Facebook is not, and may just insert blocks of random code onto any FB link you create pointing to your entry. Maybe they will learn.

Playing All Sides

Despite my belief that Facebook has been a large-than-deserved time sink for myself, I've finally managed to add proper "like" buttons to these pages. Took a little reminding myself how javascript worked, but now every entry has its own "like" button so that, well, so that Facebook can sell more ads.

I've also been poking at Google Currents as a distribution mechanism for mobile devices, in addition to puzzling over how to make botzilla itself tablet-friendly and how to best reduce all photos to 400 pixels (to bend the old saw about cameras, "the best photo gallery is the one in your hand"?).

What's a bit of a puzzle to me is how to best incorporate either of these with some of the other aspects of botzilla that I'm looking to enhance, especially heavier use of <canvas> tags using animation and where possible WebGL. Given that Facebook looks for static images to grab as thumbnails, and that Currents runs off of RSS, how to best show-off fun animation and interactive imaging experiments?

Camputer

Dogs and Lunches, etc

If It Has a Ringtone, It's Not a Camera. Panasonic Lumix's advertising slogan didn't last long -- not, I think, because there would soon enough be a Lumix-branded mobile phone, but because it's a slogan that can easily be interpreted either way: that a celphone is less than a camera, or (oops) that a camera is potentially rather less than a cameraphone.

It's also less than a "camera-puter," which is an aspect that is neither camera nor phone.

In the simplest sense, the camputer is a portal for images direct from your hand to the internet. But what about pictures before they ever leave the phone? If they ever leave the phone?

The utilitarian camera-as-scratchpad notion that's been spreading since the advent of home video (even, for a few, on Super 8) is now something that almost everyone takes for granted. End a meeting with a whiteboard full of scribbles that might be useful later? No time to copy them in a notepad? Use the camera phone. Want to keep a snap of the good-for-once haircut? Want to remember that the car is parked on Level 4 Blue zone? Easy and the photos just as easily cast off when they're done.

Camphone as agent of political change? The jury's out on its genuine effectiveness, but certainly it's had a huge and unpredictable effect on the relations of people, governments, politicians, and the media between them.

Beyond these "useful" applications, though, and beyond the camphone's replacement of point and shoots for a quick facebook-upload fix -- are there new ideas that might be useful creatively? The rapid spread of programs like Hipstamatic and Vignette (or even CamScanner) provide a hint to one other direction, closer to usual photographic practice -- the collapse/reversal of the traditional photo workflow. Sure, you could already take a digital photo and then push it through Photoshop to alter the character of the color and contrast, emulating the look of a particular film stock. The patterns were still the same: capture, process, and (potentially) presentation.

The advent of processing tricks in the camera application collapse the first two steps into one. Just set the camera on "Velvia" and go find some fall foliage. Heck, put the processing and border-generating on "shuffle."

Or even shoot with a different camera and import the images into your phone, rather than spend $500 on Photoshop: which is just what is happening here -- cited by Leica, no less. Established commercial photographer Laura Rossignol shooting on a D-Lux 5 (aka Lumix LX5), and then (after doing selects in Lightroom) "I like to take the post processing one step further and I will email a finished version to myself so I can open it in the Picture Show iPhone app. It allows you to add interesting effects and frames."

(Addendum: Adobe's John Nack made a similar post to this one, wondering: why would you edit on a mobile device?, just a few days ago....)

I used to think that the transparency or negative was the canonical object. As Ansel Adams wrote about it, the negative was like a musical score, to be interpreted by a darkroom performance for each new print. Throw that idea away. Immediate darkroom-ish styling on the fly: whether you think they're insanely great or sentimentally godawful, they're as fundamental a part of the New Beast's nature as is the thickness of oil paint or a trumpet's high notes. Get used to it, this is still just an early wave.

Flashy Foods

What I Ate: 28 Jan 2011

The flash diet doesn't require using flash, and it isn't really a diet per se, but an alternative to keeping a food diary -- photograph everything you eat. A side benefit is that it gives you an excuse to make at least a few photographs every day.

For entertainment value I've given myself a little rubric:
    • Celphone only: twee "FX" apps okay
    • "One bullet": c'mon, it's time to eat
    • Context: ingredients, locations, companions

Here is a great thing about celphone cameras: they're not Hasselblads. They're more like a real "pencil of nature," in that a pencil has incredible range -- you can use the same pencil to jot down the grocery list or to draw a masterwork. The Hasselblad is more like oil paints -- wonderful for what it does, but too grand and technically involved for casual muddling.

eReading, 2011 Edition

The pictures show a recent bargain toy -- a 7-inch Pandigital Novel eReader (aka "PDN," or "WPDN" to specify the white variant), re-flashed to expose its Android underpinnings and updated to Android 2.1 "Eclair." I managed to pick this one up during a recent clearance at the nearby chain store Kohl's for a tidy $59 (apparently, a few folks even managed to get a $20-off deal -- an Android tablet for $40!). Even at the more-usual price of $199 the Novel is no iPad, but at that price you could by three or four of them (or at the discount, a dozen or more!) for the price of a single iPad (Addendum: Apparently they sold 440,000 PDN's in 2010). So here's a quick review of my experience thus far:

Pandigital are known as much for their digital picture frames as for their e-Readers, and the Novel kind of feels less like a slowed-down computer and more like a turbocharged picture frame. This suits its designated purpose: as a full-color eReader. Not a game machine, or a media center, though in fact it's quite capable of playing YouTube videos or being a music player if the mood should strike you to use it that way. But really the CPU wasn't designed for rapid-fire screen updates. It's a device built around a slower, simpler, long-attention-span sort of experience.

I've got several different devices on hand for comparison, including current iPhone, iPad, a couple of new and old Android phones, and various other small computers, MIDs, readers, and so forth. Given this environment, these are the things that stand out about the Novel:

Resistive Screen

A good resistive screen, but it works best with the back-of-the-fingernail strokes rather than just the finger tips used on capacitive screens like the Nexus One or iPhone. This can throw you when moving back and forth between different devices.

Slow

Mentioned this before, but: it's okay. What I don't try to do is cram every possible use case into this device -- I am not expecting tons of animated bells and whistles or HD television or anything of that sort from it. This is one device among several, so I can let it just focus on what it does well. For my uses (more later), it's fine.

No Bluetooth
No Camera
No Phone or 3G/4G Connection
No GPS

If I thought it was really important for me to record my face and location while typing my Engadget responses from the beach, I suppose these omissions would be truly upsetting. Happily, the simple wi-fi connection covers any of the locations where I'm actually likely to be using the PDN, and I can always turn on tethering from my phone if I'm desperate to update my apps while tooling along through traffic on US 101.

No Pentalobular Screws

Easy open, and easy tweak, too -- I doubled the internal memory by simply sliding open the case and swapping a hidden microSD card.

Long Battery Life

I've accidentally left mine on all day and it's still solid later on. It's a charge-daily device, though, unlike, say a Sony E-Ink reader (which can last for many days -- again, designed for intermittent bursts of activity, rather than continuous on-screen spinning and sparkling).

Standard SD Card Slot

The PDN can accept SD cards up to 32GB, though I haven't yet filled the free 4GB card I picked up at MicroCenter (There's also the hidden internal slot mentioned above, for microSD).

USB Port

The device has one, but it's really only useful for communication with other computers via ADB (Android Debug Bridge)

The Case

Not many choices compared to iPad, but I found this book-style folder at Bed Bath and Beyond, also on sale (The PDN is very much not the sort of device you'll find in usual computer stores -- everything has come from the Housewares Dept so far!).
Having the case makes a huge difference in the comfort level (one of the pix above shows it without the case for comparison). It's much easier to hold and I don't worry about banging-up the screen. This cover compares somewhat to the base cover for the smaller and lighter (but less capable & monochrome) Sony PRS-300 E-Ink reader.

Size

The PDN is smaller and thicker than an iPad (which makes it feel heavy and dense, even though overall it's a bit lighter). I prefer this size, it suits my hand better, without being too small to read at a comfortable distance while reclining on the sofa (unlike the Sony, which needs the font size cranked up at that distance).

So what's it good for?

Principally, it's good for its chartered design tasks: reading eBooks and light web browsing. For these, it's excellent. By stripping-away the default Pandigital/Barnes&Noble skin (re-flashing doesn't delete these features, but simply makes them companion apps within the Android Home screen), the full range of Android apps can be seen and tried. I've found that the combination of wi-fi and Google books, Aldiko, & Kindle apps, along with Google Reader and the Skyfire browser, makes it more capable that any other reader save high-end tablets like the iPad or Galaxy Tab.