I don't think Lightroom supports "subject distance" natively. There are other missing exif fields too that motivated me to write the ExifMeta plugin, which you can use for free if you want to.

Rob

I also want to thank the developers for the release candidate --the flickr publishing is so nice and works great --the whole program works much more quickly.

You don't need to update so you can wait if you want.  You don't need the CR plugin, that's for Photoshop.

err.. uhm.. no, shouldn't have any effect at all.  This is just the first update of many for 3.0..

It's not quite the same as "unlocking" your iphone!

Cheers!

I'm not Tom Hogarty, nor an Adobe employee, but I'm thinkin' its the same as for Lr3.0 - i.e. this forum and the feature-request/bug-report form.

I'm sure an insider will come along and confirm or deny...

I can confirm that the display size issue is still a problem in LR3.2 RC.

I have an image with a number of tweaks and when I apply an adjustment brush stroke to it, depending on the display size the stroke will be very delayed and slow, or relatively fluid. Bringing in the bottom panel (F6) makes all the difference. This is on a 1440x900 screen and using an image in portrait orientation.

LR3.2RC now can show a considerable lag between pressing "K" and the adjustment brush being ready to appear. Is that a trade-off that has been made to make the subsequent brushing quicker or avoid the impression that the brush is ready (cursor showing) but wasn't quite?

BTW, only played perhaps a total of 15min with LR3.2 RC and have a nice message overlayed on the top of my image "An unknown error occurred"... Only went back and forth between images and made test applications with the adjustment brush.

Arrrghghhh!!!!

And it sometime crashes completely when using the clone tool.

*sigh*

I thought that behaviour was a thing of the 2.x past.

I then have to restart and the folder I was in, panel states etc. are all forgotten. Can't that info be stored on disk so that when it crashes (and it will) they can be restored? Even microsoft word does that sort of thing.

W.W. Webster wrote: This release includes camera support, bug fixes and new features.  Details here: http://blogs.adobe.com/lightroomjournal/2010/08/lightroom-3-2-and-came ra-raw-6-2-available-on-adobe-labs.html The linked page identifies only one new feature.  Are there others?

The biggest one appears to have slipped under the radar.... sticky filters are back!  If you aren't familiar with them I've written a blog post about them and how to enable them in LR3.2RC:

http://bit.ly/azjaLa

Ian.

Despite the fact that the bug list does not announce any of this, I'm very happy to report that LR3.2 RC seems to run quite a bit snappier in many ways. Local edits are still slower with an image that already had a lot of tweaks applied compared to applying them on a fresh image, but overall the performance seems to be much improved.

Its still early days and I'll have to do some real work but so far it looks very promising. Thanks for the release candidate!

The stuttery cursors of the spot removal and red-eye tool are gone as well. Nice touch. I now have an idea why it had been these two cursors that were different. They are the only ones which may need to change mode if the cursors are run over previous applications (i.e. there has to be a collision test with round shapes other than the handles). In my current testing I noticed that said cursors sometimes can become stuck completely and only move on after a slight pause. I think this is a new bug as I haven't seen it before. Hope it is not Lua garbage collecting. Moving the cursors around shouldn't really be a problem even if there are some collision tests to be performed.

A bug I reported about the spot removal tool not working well in corners also appears to have been addressed.

I've only done a very quick test so nothing is definitive but indeed looks promising.

The only issue that might have gone worse is the jerkiness of scrolling through the grid mode with the scroll bar. It wasn't great before but I now seem to experience more frequent and longer pauses in updating the grid. Please, everyone compare the (on my system jerky) way the scrollbar moves the grid to grabbing the grid with the mouse (move the cursor on a line between images and it will turn into a hand). If you move the mouse while having grabbed the grid, the updates are smooth and allow visual tracking of the images while they move. The movement with the scrollbar is so jerky that I cannot visually track the images as they pass by.

Note that scrolling with cursor keys is very fast without pauses but the movement isn't smooth (jumps with the image height) so again visual tracking is hard.

I have an idea why the scrollbar is as decoupled from the grid movement as it is, but I hope that there is room for improvement. I'd be prepared the grab the grid even though that would mean precision manoeuvres with the mouse, but unfortunately, you don't really get far with this method.