From Gunar is the blog of Gunar Penikis who until last year was Adobe’s manager of XMP and therefore very involved in metadata entry and the File Info panels. He’s recently published 3 posts about CS5 – CS5 File Info Metadata UI – What’s New, Create custom metadata panels, and Making CS4 File Info Panels Work In CS 5.

For me the jury’s still out on whether the move to Flash/Flex-based File Info panels is a good thing. I’m not sure I’ve seen any examples of where people have done anything exciting with the greater UI design possibilities, and for many Flash/Flex is a barrier to getting started with custom metadata. Why would a mainly Photoshop/Bridge user want to acquire the Flash/Flex skills needed? After all, these panels would have been an ideal use for Configurator, don’t you think? But that said, at least Adobe have the good sense to release the generic panels Gunar discusses.

When I return from the Lake District, I’ll update my panels for iView/Expression Media. But I’m in no hurry, partly because my use of Expression Media has greatly declined, but also because this time I’ve had some of the best weather here for a while. This 8 frame panorama shows Blea Tarn with the Langdales in the background. Why would I want to return to London? Indeed, why would I want to make a blog post?

I'll be posting some of my own thoughts on Aperture 3 soon, maybe tomorrow. But I just noticed David Riecks has some issues with how Apple Aperture 3 writes metadata and I recommend you read his article very carefully indeed:

Apple has made some significant changes to how Aperture handles metadata with this latest release. However, the ways in which this has been done should be of great concern to professional photographers that work with other programs, or hand off their metadata-rich files to others who need to be able to access the full range of that information.

You shouldn't be concerned if you use Aperture 3 on your own Mac, don't typically use embedded metadata, and don't share your images with others, or work with other programs such as Adobe Photoshop. Even if you do use metadata to describe your images, and only need to find them on your local computer, you should be fine.

You should be concerned if you use Aperture to write metadata to files you use with other programs, share with others or share on the Internet. For example if you do additional work in Photoshop or Lightroom, and then archive your images using other programs, you need to understand what is happening, or risk having some or all of your metadata disappear.

Good DAM practices aren't just about only ever using any one program, or placing all your trust in one company, even Apple.

Did you see the mocked up shots of what Bin Laden might look like now? Well, it seems the FBI's cutting edge technology was cutting and pasting with Photoshop:

A Spanish politician has said he was shocked to find out the FBI had used his photo for a digitally-altered image showing how Osama Bin Laden might look. Gaspar Llamazares said he would no longer feel safe travelling to the US after his hair and parts of his face appeared on a most-wanted poster.

He said the use of a real person for the mocked-up image was “shameless”. The FBI admitted a forensic artist had obtained certain facial features “from a photograph he found on the internet”.

Like 8 year old Mikey Hicks, whose name seems to have got him on a watch list, you've got to think poor Mr Llamazares isn't going to enjoy travel from now on. Makes you feel so safe, doesn't it?

Also see the TSA Logo Contest.

Adobe's Configurator is another Flash/AIR based program that allows you to create new panels for Photoshop, and a few of panels are in the wild. Maybe its time hasn't yet come, and we're yet to see tutorial and educational material delivered directly into Photoshop (you can run a Flash video in a panel). But even now, it's great for creating panels that fit your specific needs, and I thought I'd post an example.

When creating blog posts or writing other material that requires screenshots, I go through a predictable series of steps. On Windows I'll hit PrintScreen or on Mac I'll use Cmd Ctrl Shift 3 (or 4) to place the screen's contents onto the clipboard. Then in Photoshop I'll create a new file and paste in the clipboard - that's the Paste New File button, a script.

Then I'll use various selection tools or the Crop tool to select around the important detail - hence the second row of buttons.

You get the idea - the panel works from top to bottom. Having selected around the detail, I invert the selection, and copy the detail into its own layer. To crop the image down to what I want to keep, I'd right click the layer and Select Pixels, then crop to that selection. At that point I might resize the image, or use Smart Transform to squeeze it into a defined size while keeping important detail. Finally I might sharpen it, and then save for web.

All those tasks are brought together in this panel for Photoshop CS4. I could use fewer buttons - so I could use a keyboard shortcut for Select > Inverse - but the panel makes it a mouse-driven process. To install it, double click the MXP file and follow the instructions in Adobe's Extension Manager, restart Photoshop, and it's available under Window > Extensions.

Adobe Rome is a technology demo of an Air application that combines features from multiple Creative Suite applications like Flash, Photoshop, Fireworks and Dreamweaver in a single desktop or web app. Every time I see one of these, it reminds me of Mac apps I saw c 1989 or Microsoft Office's c1995 fumblings with OLE. But one day…..

Via John Nack

If you've ever used iView or Extensis Portfolio, or countless other non-Adobe programs, you will have learnt long ago that Photoshop's Maximize Compatibility dialog box did what it said on the tin - it maximised the PSD or TIF file's compatibility with other programs. Or rather, what you would probably have learnt is that if you unticked this setting, you would be saving disc space at the cost of making other programs struggle to display the PSD or TIF file. Short term gain, long term pain?

This is as true of Lightroom as it is of third party programs - after all, Adobe engineers have far better things to do than cater for self-inflicted pain. The remedy is to resave those files compatibly - see Laura Shoe's post for an efficient way to do this.

Let's be reasonable here - maybe the fashion company was actually justified in getting their lawyers to send a DCMA take-down notice for this picture to Photoshop Disasters and BoingBoing:

So, instead of responding to their legal threat by suppressing our criticism of their marketing images, we're gonna mock them.

How dare anyone accuse them of Photoshopping? It's pretty obvious the poor girl has been stretched on a medieval torture rack which I imagine must be easy enough to find in New York. Huh? What? She was born that way? OK, I withdraw, she wasn't Photoshopped and she wasn't stretched on the rack. Shame really - might have been fun.

Update 17th October. Oh dear, Ralph Lauren fires photo-chopped model for being too big.

Last week's DPI show was fun. Only doing one platform session a day, it was a lot less arduous than the three daily sessions I did at Focus, and it meant I spent my time doing Q&A on Lightroom and Photoshop. Working one to one, or with small groups, you're able to establish their needs and explain in real detail, and you feel they go away knowing exactly what they're going to do next. In many cases, that was to buy Lightroom or to use my favourite features - Auto Sync above all.

Anyway, I didn't get much time to go round the other stands, but I did have a closer look at Blurb's books than I'd managed at Focus. I've still not got round to finishing the Civil War book, other things getting in the way, but I was again very impressed with the quality and have got to get mine done. But most of all, I learnt something that really delighted me - this week Blurb are going to….. Oops, I'd better point you to Blurb's blog:

We

Maybe I'm unable to appreciate the subtleties he's trying to express, but I was somewhat underwhelmed with both of Alain Briot's essays on in-camera blurred landscapes (part 1 and part 2). Such images “need to rely both on color, placement of elements and use of shapes and lines to be successful”, “the type of light you use is very important”, “good processing is crucial”, and “setting the black, white and the grey points precisely is crucial to the success, or failure, of these images”. Well, I never. But then at last there is something specific to camera-blurred images:

I found that using a [Photoshop] high pass contrast filter on top of the image, after all the adjustment layers are completed, helps a lot in defining the detail level of the image.

Because these images are by nature less detailed, sometimes increasing the level of detail is necessary. This helps bring up the interest level in the image as well as make the image more engaging visually for the viewer. Of course adding details is not possible. All we can do is increase what is there. We cannot add anything new. And again increasing what is there through sharpening only takes us so far since there is little detail to start with.

This is where High Pass Contrast processing comes in. This approach basically increases the local contrast between objects, or more appropriately here between the different areas of color and contrast. In effect, to my eyes, it increases the contrast of the lines in the image, the black level of these lines I think.

I do something very similar - but in Lightroom. Its Clarity setting has pretty well the same effect.

Here it is set to 100, which is unusually high for me, and in this case I've also given it a second dose using a gradient filter over the whole image (the same technique as in my Ultra Clarity preset, only with a single gradient). Normally I wouldn't go anywhere near that far, and a much more moderate Clarity setting is usually all that one of these blurred image needs (or can stand).

The picture, if you're interested, shows the Kingston Lacy beech avenue which runs for over 2 miles along the busy main road between Blandford and Wimborne in Dorset, and it's a well known location (see one example) that couldn't be much more perfect for the exercise-averse photographer. You park right by the trees, prise your backside from your Recaro bucket seats and you're all set to go….

No, I’m not going to write any tutorials, but Sean suggested writing some thoughts on learning Lua for Lightroom….

Getting this far with Lua has been a real struggle. I am not a trained programmer like Jeffrey Friedl. I know no C, C++, Cocoa etc, so I don’t know if Lua is easy for people with such a background (though it heartened me when he described Lua as “horrid”). But I do have a lot of experience of the various flavours of Microsoft VB and VBA, and of JavaScript, PHP, AppleScript, ActionScript 2 and 3, and other useful technologies like XML, SQL etc, all self taught. That brings a confidence that things should be possible, but it barely overcomes the why the bloody hell should I add features that should have been there in the first place? So over the last year the effort has been pretty sporadic, learning a certain amount, achieving something vaguely interesting, and then finding something else to do with my time.

I’ve always liked Microsoft’s approach to scripting professional applications – the Office suite being the prime example. There’s an assumption that you’ve got to enable the end users to do it themselves. In Cubicleland you don’t want to wait for the IT guys to write that code to automate your budgeting spreadsheet or interface with the MRP system. Bringing in a programmer means jumping through authorisation hoops, and inevitably you’ll find yourself left with something you can’t tweak as you perceive the task has nuances you hadn’t anticipated. Rely on self-interest and provide a user-friendly language and tools, and the end user should be able to do the job. That’s how I began going off the rails.

In InDesign and Photoshop, Adobe provide the perfect triangle of scripting languages, VB+JS+AS, so you can automate and streamline your work. Integration with the non-Adobe world is enabled with two platform specific languages, while cross-platform functionality is there for an Adobe-centric workflow. Imagine how great that would be for Lightroom. Someone somewhere would make Photoshop do something like apply NoiseWare or other noise reduction to a batch of images with different settings for differing ISOs. Or say you wanted to bring into Lightroom all that metadata originally entered in Aperture or that is now in the Excel data exported by some other DAM. Again, one VB or JS or AS script could do the job, and if the coding hits a problem there would be a world of experience and existing code and examples that even an ex-accountant could adapt.

Lua by comparison is a niche language, and what documentation exists is written for programmers. You have to write the code in glorified text editors rather than helpful development environments such as Microsoft’s VB IDE, and when there’s a syntax error it’s in gobbledegook that’s only intelligible once you have enough experience not to have made the mistake in the first place. Lightroom’s SDK is also mainly targeted at the developer, provides just half a dozen examples, and you can no longer learn by taking apart others’ plug-ins because everyone’s now encrypting them.

But Lua is not going away, and after a load of grumbling I usually snap (and funnily enough, as I added that link I realised that I’m wearing my Mt St Helens t shirt).

So what I’ve been doing over the last year is attacking Lua every so often. Little and often. You also need to approach from a number of directions until the penny drops. Once you’ve got the SDK, I would suggest customizing a copy of the web template. As it’s in Lua, it will get you familiar with the syntax and structure. It also has HTML and CSS elements, so you’re not totally on foreign territory, and you can focus your efforts on producing something you can use. In my case I just adapted the built-in web template so my online contact sheets have star ratings to help draw attention to the best images (as if they won’t do so themselves!).

Second, look at customizing the FTP client that’s provided in the SDK. That exposes you to how export plug-ins work, and also to the way the Plug-In Manager works.

The third area of the SDK is custom metadata, and again there’s an example which you need to tear apart and put back together again. Here you can add new fields to the catalogue, new metadata panels, Library Filter columns, and Smart Collection criteria. This area is where I’ve spent most of my real effort, and it typifies something I dislike about Lua – that you need to proceed by trial and error. Change a line, reload the plug-in, see if you’ve broken anything, hope the error message is remotely decipherable, and then see if it still does what it’s supposed to do. Only then is the SDK documentation and attempt to marry up its descriptions to what you think you’ve just done.

That’s not the only reason I keep both the SDK PDF and the API html open all the time – it’s also so you can see what else is in the toolbox. For example, while writing the last few days’ plughini I noticed that you can code the progress bar. While that’s off the critical path for now, sometimes the really hard bit is realising that something can be done. So look at others’ plugins, and note what is possible.

So a lot of of the learning process is about taking apart a series of substantially-discrete components. Adding custom fields, reading and writing fields, calling dialog boxes, accessing operating system properties…. All in a language that glories in making itself doubly obscure by calling arrays “tables” and forcing you to define that each line of code as a “row”. It’s a bit like building your own car – put the effort into learning to make the bodywork, tyres, leather seats etc, and eventually the experience coalesces and you can bolt together something that’s roadworthy. For those who know Trainspotting, and perhaps another volcanic analogy lurks here, it’s all a bit like Renton getting his fix.

So often it takes a fresh pair of eyes to notice something. As I wrote here, I'm designing my Blurb book in InDesign rather than following BookSmart's canned layouts, meaning the recommended workflow is InDesign > PDF > Photoshop > PNGs > BookSmart. While I could set up a Configurator app to automate saving multiple PNG files, these Photoshop batch processing things always break or involve an inordinate - if for some enjoyable - amount of tinkering (hence Lightroom).

But there's an easier way… InDesign > PDF > Acrobat > PNGs > BookSmart. So you create the book layout in InDesign, then export the PDF and choose the option to open in Acrobat. Once in Acrobat, it's File > Save As, and PNG is one option. You get one PNG per page, and they're numbered sequentially so you just import them into BookSmart, check they're sorted by filename, and then use AutoFlow to create the pages in the right order. It makes revising the design and getting it into BookSmart a relatively slick process.

With the workflow wrinkles being smoothed out, I'm now putting more thought into the layout, and the big decisions so far have been about borders and bleeding. My initial inclination was that I wanted all pages to have the non-bled art book style of the above screenshot. So a single image centred on the page, with a brief title, a page number, and no decoration - just lots of white around the picture. And to my eye a plain, fine black border looks as right on the book layout as it does on an inkjet print (it's slightly exaggerated in the screenshot but the one on the left has the border).

Yet the more I've been playing around, the less sure I am that this design works. For one thing, have you ever noticed that pictures in coffee table books never have borders? That's the case even when a bright area lies close to a picture's edge and seems to leak out into the surrounding paper. Of course, it's not a rule or convention that one needs to follow, but “borderless-ness” (an Iain Dowieism?) seems inevitably intertwined with a bigger decision about whether to keep the non-bled fine art look which suits the above portraits, or adopt a mixed layout with fully-bled pages. In terms of my bookshelf, it's Fay Godwin's Our Forbidden Land versus Don McCullin's Sleeping with Ghosts, and a much-published friend put it really well:

I do think these considerations should be primarily content driven. Fay Godwin's landscapes are for the most part timeless, immutable and essentially static so the design should reflect that unlike my dynamic and anything but static pics of musicians!

Don McCullin it has to be .

Photoshop and Bridge CS4's File Info panels are built differently from before, using a Flash-based technology, and iView users are moving over to Expression Media - that is, if they are still hanging on….

So I've just uploaded CS4 versions of my File Info panels to my iView downloads page. I've done panels for both iView and xMedia, and also included an extension to the Metadata panel that's shown in Bridge's main window - click the image to see what I mean (it can also be done in Bridge CS3 as shown here - thanks Peter Krogh).

But, as they say - wait, there's more.

Also included is a JavaScript for Bridge that adds a set of commands to its Tools menu. The most interesting is Expression Media 2 Data to LR Hierarchical Keywords which has a name only its father could love but does what it says on the metaphorically-mixed tin. In particular, it converts xMedia metadata to Adobe format - including Catalog Sets to Hierarchical Keywords.

As usual with these things, they are free but unsupported and there's a subtle nudge towards my Amazon wish list (thanks David Finch if you're reading).

There's never one way to do something, and whether it's climbing a hill or putting together a book, it usually makes sense to have a good look around before setting out. Initially I'm going to do a test book with the minimum number of pages and trying out things like colour images (eek) or double page spreads which the final book probably won't contain. So I've been reading through forum posts (RSS feed) or the Blurberati blog, and playing around with Blurb's BookSmart - pretty well confirming my feeling that it's a bit too limited for how I like to work.

What I mean here is that once I see an image in a layout, there's a pretty good chance I will want to adjust it again. This expectation may be a personal thing, always wanting to fine tune and never saying something's finished. Or perhaps it's more in the very nature of putting together a book where the images have to look right in context rather than individually. Either way, BookSmart doesn't let you do anything smart, and you'd have to reopen the original in Photoshop or Lightroom, create a new JPEG, and replace the one that's in BookSmart's My Imported Photos.

That's a rather pedestrian way to work, and nor do I like the thought of retyping captions which are already in the images' metadata. So rather than do any layout work in BookSmart, I'll take advantage of having InDesign where I simply link to the originals, double click to re-open them in Photoshop, and add captions by scripting. Another advantage is that I could take InDesign's PDF and to an alternative print on demand service, go down an eBook route, or even output to Flash (for no good reason other than being able to do so!). Only at the very end of the process, when I'm happy with how the book looks in InDesign, will I need to go to BookSmart.

The fun is in getting InDesign layouts into Booksmart because Blurb doesn't yet accept PDF files (maybe later this year) and InDesign doesn't export PNG which Blurb say is preferable to JPG for text quality:

Even in the latest InDesign (CS4), exporting to JPGs (300dpi or 600dpi) results in subpar text in your bound-and-finished Blurb book. It is better to export from InDesign as 300dpi PDFs, rasterize those in Photoshop (300dpi, RGB color, anti-aliasing checked) and save out as PNGs (8-bit, non-interlaced). Sounds like a pain, and I admit, PDF support would indeed make life easier for all of us. But if you can set up a batch action in Photoshop, this process is really a breeze. And, most importantly, it results in very clean custom text.

So I'm going to have to go on the rather circuitous route in Designing Blurb books in Adobe InDesign - ie InDesign > PDF > Photoshop > PNGs > BookSmart.

Photoshop is merely a stepping stone between PDF and PNG, but opens each page in the PDF as a separate file - no fun saving between 20 and 100 out to PNG and making sure the files would be numbered so that BookSmart's Autoflow button would put the PNGs in the correct order. As I'd been looking for a good use for Adobe Labs' Configurator, thus was born a very beta Blurbify….

Robin at by theartofengineering has done a really helpful series of posts:

• InDesign to Blurb
• InDesign templates

And here are Blurb's full-bleed page dimensions.

Derrick Story's latest podcast is Adobe Engineer Pops the Hood on CS4:

Meet Winston Hendrickson, Sr. Director, Engineering, Digital Media, for Adobe.

During this chat in a conference room at Adobe headquarters, Winston and I talk about what's happening under the hood for Bridge, ACR, and Photoshop. He explains lots of goodies such as, the difference between the Lightroom and Bridge “databases,” the similarities between the Develop module in Lightroom and the sliders in ACR, improvements in Photoshop, and some great lesser-known features such as Camera Profiles. Terrific, informative interview.

Before the credit crunch washed away O'Reilly's Inside Lightroom blog, its content had only just benefited from a new wave of writers including Seattle-based Laura Shoe.

Her Digital Daily Dose is a not quite daily blog on digital photography with some well-written posts on Lightroom such as snapshots and virtual copies, and on on my favourite Photoshop CS4 feature, content-aware scaling (they should have called it “smart transform”).

This image is from her Photo Illustrations section.

Really enjoyed Focus on Imaging. Presenting was nerve-wracking, of course, and I really felt out of practice, but the most fun was being on the stand answering all sorts of questions, most common being what's new in CS4, should I upgrade to CS4 or get Lightroom, how's Lightroom different from Photoshop, why won't CS3 read my 5DMkII files, and should I switch to Mac for Lightroom (answer: yes if you want to, but don't feel you need to do so - look at the Dell XPS Studio 64 bit Vista with 12Gb of RAM). Hardly any time to look around, and less time to do shopping for myself, but I did get a chance to examine some Blurb photo books and was very impressed with the image quality, both colour and black and white.

It was particularly good to put faces to names I've known online - such as Chris Bishop, Richard Earney of Inside Lightroom, and Sean McCormack. Poor Sean, I was only giving the fella a lift back to his hotel, and we must have discovered every roundabout and closed car park south of Birmingham before - half an hour later - he reached for his iPhone and its GPS. Later that evening (we went for a pint, a bite, and a natter in the loudest darts pub in the Midlands) it didn't take him so long - the first wrong exit from a roundabout and out came that iPhone. But at least he told me one thing he'd discovered - I'm actually friendlier in person than he'd ever expected. Now that's a compliment - and a justifiably backhanded one too. Phew!

Managing Photos in the Library Module of Adobe Photoshop Lightroom 2 is an entire chapter from Martin Evening's Lightroom 2 book, introducing Library's features and how to use them.

linkmuseum.org is a web site devoted to the work of Winston Link. Best known for his wonderful work on the steam trains of the Norfolk and Virginia Railroad, Link wasn't just a wonderful exponent of using flash outdoors in the landscape:

Taken on August 2, 1956, this is the most famous photograph Link took. This was the most equipment-envolved picture requiring 42 No. 2 flashbulbs and 1 No. 0 (on Willie Allen and Dorothy Christian sitting in Link's own 1952 Buick convertible). At the time of night Link wanted to take the photograph, the scene from “Battle Taxi” on the screen [ie the aircraft] would not show up because it was backlit by a flashbulb. Link returned during the day and photographed the movie screen without the use of the flashbulb. Link then cut out the visible screen from the daytime negative and placed it ontop of the nighttime negative.

Who needs Photoshop?

Let's say you have a bunch of raw files adjusted with Adobe Camera Raw, and you want to make a load of JPEGs. It's not a novel nor a difficult task - Lightroom's export function is designed for the job, or if you're using Bridge you might reach for the Image Processor which runs the files through Photoshop. Another Bridge-based solution would be to open all the raw files in Adobe Camera Raw, select them all and hit the Save button.

In each case, your poor computer is having to create the JPEGs by processing all that raw image data. But because it is doing so, you can at least be sure that the JPEG output does reflect all your Camera Raw adjustments.

But it is not quick, and it is a pain when Lightroom or Bridge has already done the hard work of updating thumbnails and previews (particularly when you think that Lightroom now updates Bridge's Camera Raw cache).

A new option is Bridge Export to JPEG (it's called BridgeExportToJpegCS4), a script by Adobe's David Franzen which he has significantly extended for Bridge CS4, adding presets, metadata and colour profile options. Its beauty is that, rather than reprocessing the raw images, the script uses the previews which Bridge has already rendered and stored in its cache. So, if you already have updated thumbnails and previews, it's light years quicker than the other options.

Not long ago I almost linked to Micah Walter's Inside Aperture article Seeing RED. He's now doing more video and is having problems managing the new file types:

What would save my day would be Aperture. If only Aperture supported AVCHD (and many of the other tapeless formats) I could import my AVCHD card just like I do with my DSLR. It could import any stills from my HD camera, as well as all of my native clips. It could allow me to preview my clips, maybe even set in and out markers and I could select a batch of clips and still frames to send off to Final Cut Pro for production. Final Cut could be responsible for converting the clips to QuickTime format (or not) and everything would just be in one place in an Aperture project.

Can't recall why I didn't link to it - probably because he is explicitly talking about "proper" digital video - but now it's worth comparing with Sean MacCormack's post Video and Lightroom:

In these days of convergence, where 2 of the newest DSLRS offer HD video recording capabilities (albeit basic), and almost every compact has some kind of video mode, I'd like to see Lightroom support Video. At minimum, I'd like it to import the video with my images. Preferably, I'd like to be able to playback the video and perhaps add basic metadata (copyright, keywords etc). I have no expectations of being able to edit video, or even work on colour, brightness etc. I just want to have my video managed with my images.

What we're seeing is the start of a battle for the soul of Aperture and Lightroom. Yes, I know that sounds almost as ludicrously-hyped as the Strictly Come Dancing judge saying John "the dancing pig" Sergeant had made the show a laughing stock, but both Aperture and Lightroom users fall into two distinct camps over this issue. On the one side are those who only see the Aperture and Lightroom as Photoshop substitutes for the DSLR era. And on the other are photographers who need a tool for photographers - which need not be limited to photographs.

I have negligible interest in video - photography's decisive moment satisfies me much more than video's hoovering-up process - but I've always been very much in the latter camp. As part of photography-centred projects and tasks, I might have PDFs such as contact sheets or layouts, Word documents such as correspondence or invoices, sound clips to include in the DVD of a wedding shoot, while it's crazy that Lightroom can send to Photoshop HDR merging yet be unwilling to manage the 32 bit output files.

I'm very much a believer in database-powered applications for managing picture collections, so the solution isn't Bridge, much-improved though it is, as it remains a Windows Explorer or Finder with knobs on, which can only ever tell you where files happen to be now, not where they should be. So I've always wanted Lightroom to be an iView with raw processing, not a narrowly-pretty face for Adobe Camera Raw.

I'm not sure if proper video and the convergence issue are a pair of Trojan horses (these are the days of Boris says teach yobs Latin and Greek and Obama's classical oratory) or perhaps they are twin battering rams? Either way, wheel them up, now please.

Update - 5-6 comments were lost during my web site changeover. They were both pro and against.