Searching for 'version 4' and 'Lightroom 4' in the guide and reference, here are new or changed items: Info.lua LrForceInitPlugin LrExportFilterProvider.supportsVideo LrShutdownApp URLHandler LrApplication LrApplication.appStoreReceiptHash() LrApplication.backupAtNextShutdown( pluginId ) LrApplication.macAddressHash() LrApplication.purchaseSource() LrApplication.serialNumberHash() LrCatalog catalog:createKeyword( keywordName, synonyms, includeOnExport, parent, returnExisting ) catalog:getKeywordsByLocalId( ids ) catalog:triggerImportFromPathWithPreviousSettings( path ) catalog:triggerImportUI( path ) catalog:type() catalog:withPrivateWriteAccessDo( func, timeoutParams ) catalog:withProlongedWriteAccessDo( params, timeoutParams ) catalog:withWriteAccessDo( actionName, func, timeoutParams ) LrColor color:type() LrDevelopPreset preset:type() LrDevelopPresetFolder folder:type() LrExportRendition exportRendition:type() LrExportSession exportSession:type() LrExportSettings LrExportSettings.applyVideoExportPreset( exportSettings, preset ) LrExportSettings.extensionForFormat( format ) LrExportSettings.removeVideoExportPreset( presetObject, pluginObject ) LrExportSettings.supportableVideoExportFormats() LrExportSettings.videoExportPresets() LrExportSettings.videoExportPresetsForPlugin( pluginObject ) LrHttp LrHttp.post( url, postBody, headers, method, timeout, totSize, totalSize ) LrHttp.postMultipart( url, content, headers, timeout, callbackFn ) LrLogger logger:type() LrPhoto photo:getDevelopSettings() - new fields for PV2012 photo:getRawMetadata( key ) - new fields, including pickStatus photo:setRawMetadata( key, value ) - new fields,  including pickStatus, gps photo:type() photo.localIdentifier : (Read-Only) LrPlugin plugin:type() LrProgressScope progressScope:getParentScope() progressScope:type() LrPublishedCollection pubCollection:publishNow( doneCallback ) LrPublishedPhoto publishedPhoto:type() LrVideoExportPreset - new in 4.0 LrView viewFactory:catalog_photo( args ) viewFactory:scrolled_view( args ) viewFactory:simple_list( args ) SDK - Export service provider exportServiceProvider.allowVideoExportPresets : (Read-Only) exportServiceProvider.disallowVideoExportPresets : (Read-Only) SDK - Metadata tagset provider items : (Read-Only) - Many new items for video and DNG SDK - Publish service provider publishServiceProvider.deleteFirstOnPublish() Message was edited by: John R. Ellis: Added 'Lightroom 4' hits. ... View more

To get rid of the ISO country code: Click on one or more of the location labels except "ISO Country Code" to commit them. Then select another photo, then select this photo again -- you'll see that ISO Country Code no longer contains an uncommitted (italicized) value. ... View more

Very interesting -- confirms that method A is practical on large catalogs. Also, it looks like there is a performance anomaly with LR's use of the database with method B.  In the application, you can do filename starts with <filename> and the results for the entire catalog appear very quickly, indicating that there is a text index on that field. But the timings of catalog:findPhotos() in method B are not providing the same performance.   Not worth pursuing, though. ... View more

Similar complaints: http://feedback.photoshop.com/photosh... As a clumsy workaround, you can first “commit” the italicized location fields by clicking on their label (e.g. click on “Country”). This records them permanently in the metadata, and you can then edit them without fear of them disappearing on you. Interestingly, if you don’t have an active filter on a location field, then the italicized location fields aren’t cleared as you edit them until you select another image. ... View more

The Lightroom forums discussion view has been coming and going for me, and the "Discussion view of this forum" link has disappeared.  I work around this by clicking on one discussion (thread) and then clicking "Discussions" in the breadcrumbs at the top: and then I bookmark the URL, which has the "view=discussions" parameter: http://forums.adobe.com/community/lightroom?view=discussions ... View more

I did a quick performance measurement, and using catalog:findPhotos() to get the "hasAdjustments" status of all photos of the catalog into a table is far faster than doing it one photo at a time. Details: We've discussed two variants: A. Extract the status of all photos from the catalog at once and put them in a table for fast access:             hasAdjustments = false B. Extract the status one photo at a time using the "filename" criterion to limit the search.             hasAdjustments = false AND filename startsWith <filename> I tested on a LR 3.6 catalog with 19K photos, 17K of which didn't have adjustments. Method A took a total of 0.14 seconds for the entire catalog, while method B took 0.2 seconds/ photo.  So clearly, method A is always better to use.  LR 4 has made many catalog operations faster.  In LR 4.1 RC2, method B took 0.02 seconds/photo, ten times faster.  But method A is still superior if you're handling more than a few photos. I think it's quite reasonable to expect that method A would still perform comparably on a catalog 10 times as large.  The resulting table would take just a few megabytes of memory. I agree that it would be more convenient if photo:getRawMetadata() supported "hasAdjustments".  But method A would still be faster, since catalog:batchGetRawMetadata() can only process a couple thousand photos per second, whereas method A goes two order of magnitudes faster. Here's the test script: --[[-------------------------------------------------------------------------- Profile the performance of using catalog:findPhotos () to extract whether a photo has adjustments. ----------------------------------------------------------------------------]] local Require = require 'Require'.path ("../common") local Debug = require 'Debug'.init () require 'strict' local LrApplication = import 'LrApplication' local LrFunctionContext = import 'LrFunctionContext' local Util = require 'Util' local catalog = LrApplication.activeCatalog () local showErrors = Debug.showErrors local function findPhotosOnePhoto (filename)     return catalog:findPhotos {         searchDesc = {combine = "intersect",             {criteria = "hasAdjustments", operation = "isFalse",              value = true},             {criteria = "filename", operation = "startsWith", value = filename,              value2 = ""},             {criteria = "filename", operation = "endsWith", value = filename,              value2 = ""}}}     end local function getPhotoFilename (photo)     return photo:getFormattedMetadata ("fileName")     end local function findOne ()     local nFound, nExamined = 0, 0     local photos = catalog:getAllPhotos ()     for i, photo in ipairs (photos) do          if i > 100 then break end         local filename = getPhotoFilename (photo)         local foundPhotos = findPhotosOnePhoto (filename)         for i, foundPhoto in ipairs (foundPhotos) do             nExamined = nExamined + 1             if photo == foundPhoto then nFound = nFound + 1; break end             end         end     return nFound, nExamined     end     local function findAll ()     local foundPhotos = catalog:findPhotos {         searchDesc = {combine = "intersect",             {criteria = "hasAdjustments", operation = "isFalse",                        value = true}}}     local hasAdjustments = {}     for i, photo in ipairs (foundPhotos) do         hasAdjustments [photo] = true         end     return #foundPhotos     end     LrFunctionContext.postAsyncTaskWithContext ("test", showErrors (function (context)         findOne = Debug.profileFunc (findOne, "findOne")     findAll = Debug.profileFunc (findAll, "findAll")     findPhotosOnePhoto = Debug.profileFunc (findPhotosOnePhoto,                                             "findPhotosOnePhoto")     getPhotoFilename = Debug.profileFunc (getPhotoFilename, "getPhotoFilename")     Debug.logn ("findOne", findOne ())     Debug.logn ("findAll", findAll ())     Debug.logn (Debug.profileResults ())     end)) ... View more

Adobe wants all bugs and feature suggestions for Lightroom to be posted here: http://feedback.photoshop.com/photoshop_family/products/photoshop_family_photoshop_lightroom Those few of us developers active here generally start the subject lines with "SDK: ". ... View more

The LrKeyword methods, along with most methods that access objects represented in the catalog, are very slow.  But at least they got about 6 times faster in LR 4 compared to LR 3.  LrPhoto has batch methods for getting metadata from many photos at once, but there's no equivalent for keywords.  I think it's a big deficiency in the SDK. ... View more

Just curious -- did you try catalog:withPrivateWriteAccessDo()?  ... View more

Copied from the merged thread: There are three separate issues here: 1. As Steve just pointed out, Google Maps shows both the exact coordinates and the nearest named entity, but LR just shows the nearest named entity. Please see these other feedback threads for more details: 2. LR 4.1 RC2 doesn't allow coordinates of the form "30.832783, 111.109783‎" to be entered into a photo's GPS field in the Metadata panel. You have to add compass directions, e.g. "30.832783N, 111.109783E‎". See this thread: http://feedback.photoshop.com/photosh... Please add your vote to it. 3. In Internet Explorer, selecting and copying the text "30.832783, 111.109783‎" from your post in this thread results in a Windows clipboard containing an invalid character at the end. Pasting that clipboard into Google Maps results in the error message "We could not understand the location 30.832783, 111.109783‎". Pasting that clipboard into the LR 4 Map search box results in a similar error message. Weird bug in IE. ... View more

Perhaps the best you can do is      Folder contains words f1 f2 ... fn where f1..fn are the elements of the path of the folder, e.g.      Folder contains words c users ellis desktop test pics for c:\users\ellis\desktop\test pics. As with everything having to do with LR search, though, the dismaying lack of exact-match operators would make such predicates at best "approximate". (There's always Any Filter, though as a plug-in it's far from completely satisfying.) ... View more

While every database technology has various resource issues with long-running, voluminous transactions, I wonder in this case whether the problem might not be with the relational database (SQLite) but rather LR's undo facility.  A quick experiment: Try catalog:withPrivateWriteAccessDo() instead. From the SDK: Provides write access to custom fields defined by your plug-in. Use this instead of withWriteAccessDo() if you are only modifying metadata for your plug-in and do not want to add the operation to the undo stack. The documentation is ambiguous, not differentiating between the intended use and actual semantics. But I'd guess that the only difference between withWriteAccessDo() and withPrivateWriteAccessDo() is that the latter doesn't add all the catalog changes to the LR application undo stack. If that quick change doesn't work, then I agree with Rob that breaking up the changes into smaller batches will give much better overall performance. ... View more

To close this thread: The plugin's code had a number of undeclared variables, some of which were causing the progressScope to not get properly created.  By default, Lua errors are not displayed, so these were slipping past the author silently.  I recommended that he use the Debugging Toolkit or Rob Cole's plugin framework (which incorporates the toolkit). ... View more

LrView.viewFactory appears to support these new methods: square_button catalog_photo simple_list scrolled_view catalog_photo() has been discussed in another thread.  The other three look curious.  Scrollable lists and general scrollable views are understandable, given how many plugins have used less satisfactory approaches to scrolling.  But what's a "square_button"? ... View more

I may have time to look at it later this week.  You can see my email address here. ... View more

Right.  But if you can't get the progress scope to work incrementally, another way to show "signs of life" is to have the collection building appear incrementally as it occurs, as sketched out above.  Personally, I would prefer that, since that's the way LR itself works with all of its long-running operations.  If performance of incremental collection-building becomes an actual problem (it may not be), then you can avoid that problem by processing the photos in batches of, say 5 at a time.  The Any Filter plugin, which searches entire catalogs of tens of thousands of photos, uses that simple approach to show incremental results without sacrificing performance. ... View more

I couldn't get your approach to work either.  But I was able to use a property-table observer to make it work: local Require = require 'Require'.path ("../common") local Debug = require 'Debug' require 'strict' local LrBinding = import 'LrBinding' local LrDialogs = import 'LrDialogs' local LrFunctionContext = import 'LrFunctionContext' local LrRecursionGuard = import 'LrRecursionGuard' local LrView = import 'LrView' local bind = LrView.bind local f = LrView.osFactory() local recursionGuard = LrRecursionGuard ("check") local function userReallyWantsToDoThis (prop, key, newValue)     recursionGuard:performWithGuard (function ()         if "ok" == LrDialogs.confirm ("Do you want to do this?") then             prop.check = newValue         else             prop.check = not prop.check             end         end)     end LrFunctionContext.callWithContext ("", function (context)     local prop = LrBinding.makePropertyTable (context)     prop.check = false     prop:addObserver ("check", userReallyWantsToDoThis)     LrDialogs.presentModalDialog {title = "Test",          contents = f:column {bind_to_object = prop,             f:checkbox {title = "Some Title",                 checked_value = true, unchecked_value = false,                 value = bind {key = "check"}}}}     end) ... View more

Another report: http://feedback.photoshop.com/photosh... ... View more

LR 4.1 RC2 now lets you manually set the altitude of an image in the Metadata pane, and it gets properly written to the file's metadata. I haven't tested how it handles track logs. ... View more

Maybe we get API cropping for Lightroom 5.0? Almost all the mechanism is already present: photo:getDevelopSettings() returns the a photo's current crop settings, and LrApplication.addDevelopPresetForPlugin() lets a plugin create new presets. The only problem is that develop presets don't allow crop settings. ... View more

Here's an updated list that includes video fields and Whites2012: photo:getFormattedMetadata() gpsAltitude is now in feet rather than meters: "2500.0 ft" rather than "762.00 m" I don't know if this is localized to each country. Video fields: duration = "01:04.0", frameRate = "30.000 fps", photo:getRawMetadata() The representation of photos not in a stack has changed. In LR 3.6 it is: countStackInFolderMembers = 1, stackInFolderMembers = {--table: 3 [1] = LrPhoto( id "14000" )}, stackPositionInFolder = 1, topOfStackInFolderContainingPhoto = LrPhoto( id "14000" ), In LR 4.1 RC2 it is: countStackInFolderMembers = 0, stackInFolderMembers = {}, stackPositionInFolder = 1, LR 4's representation is inconsistent but more memory-efficient. At last, there's pickStatus! 0 = unflagged 1 = flagged -1 = rejected I haven't tested whether pickStatus can be changed via photo:setRawMetadata(). There's a new field root_uiid: root_uuid = "545E7456-C7D3-40F1-8E65-6F4225D057A4", Video fields: album = "This is Album", altTapeName = "This is alternate tape name", audioSampleRate = "44100", cameraAngle = "Birds Eye Shot", cameraModel = "This is camera model", cameraMove = "Truck Left", client = "This is client", comment = "This is comment", composer = "This is composer", description = "Hello world"}} dimensions = {--table: 5 director = "This is director", directorPhotography = "This is directory of photography", dm_artist = "This is  artist", dm_scene = "This is  scene", durationInSeconds = 64.066666666667, durationRatio = {--table: 6     numerator = 961,     denominator = 15}, engineer = "This is engineer", genre = "This is Genre", good = "True", instrument = "This is instrument", logComment = "This is log comment", projectName = "This is project name", releaseDate = "This is release date", shotDate = "This is shot date", shotDay = "This is day of shoot", shotLocation = "This is shot location", shotName = "This is shot name", speakerPlacement = "This is speaker placement", tapeName = "This is tape name", trimmedDurationInSeconds = 64.066666666667, trimmedDurationRatio = {--table: 4     numerator = 961,     denominator = 15}, videoPixelAspectRatio = 1, photo:getDevelopSettings() ProcessVersion has these values: "5.0" = PV 2003 "5.7" = PV 2010 "6.6" = PV 2012 beta "6.7" = PV 2012 These fields represent the new settings of PV 2012: AutoLateralCA = 0, Blacks2012 = 0, Clarity2012 = 0, Contrast2012 = 0, DefringeGreenAmount = 0, DefringeGreenHueHi = 60, DefringeGreenHueLo = 40, DefringePurpleAmount = 0} DefringePurpleHueHi = 70, DefringePurpleHudeLo = 30, Exposure2012 = 0, Highlights2012 = 0, Shadows2012 = 0, ToneCurveName2012 = "Linear", ToneCurvePV2012 = {--table: 6 ToneCurvePV2012Blue = {--table: 5 ToneCurvePV2012Green = {--table: 3 ToneCurvePV2012Red = {--table: 2 Whites2012 = 0, Video fields: TrimEnd = {--table: 7     denominator = 15,     numerator = 961}, TrimStart = {--table: 6     denominator = 1,     numerator = 0}, ... View more

It's unfortunate the moderator marked this a "Not a problem", since it clearly is a problem for many people, and it understandably and needlessly annoys them. Topics in this forum can be marked with a number of statuses; here's my understanding of the relevant ones: Not a problem -- the user has reported a problem but in fact there is an adequate solution or product feature that the user wasn't aware of. Under consideration -- Adobe is considering the idea or problem solution but hasn't made a decision yet. Not planned -- Adobe understands what the user's issue is but has decided not to address it in the foreseeable future. Based on Jeffrey Tranberry's response last month, "The team is looking to see if both the old behavior and the new behavior can be supported", it would seem that "Under consideration" would be a more appropriate status. ... View more

This is fixed in LR 4.1 RC2. ... View more

Re the progressScopes, it's not obvious what might be going wrong.  But it's not clear from your code fragment whether you've addressed the underlying issue, which is you'd prefer the collections and photos to appear in the user interface immediately when they're added.  Your code fragment appears to imply that the collection set and collections are all being created within one single catalog:withWriteAccessDo(). I suggest that you restructure your code to create each collection set/collection and add each photo to a collection within separate calls to catalog:withWriteAccessDo: catalog:withWriteAccessDo delete collection set create collection set for each photo ... catalog:withWriteAccessDo create collection ... catalog:withWriteAccessDo add photo to collection Then it's more likely that the changes made to collections and their contents will appear incrementally on the screen as the plugin executes. ... View more

Hmm, I just tested LR 4.0 on Mac OS 10.7.3, and getmetatable() applied to an SDK object produces an error message, the same as on Windows: Are you sure about what you're observing? ... View more

I just remembered that there is an undocumented module LrPhotoPictureView: http://forums.adobe.com/message/4140432#4140432 In a quick test, it shows a thumbnail for .mov files in the catalog: --[[-------------------------------------------------------------------------- Shows a 400 x 400 thumbnail for the selected file. ----------------------------------------------------------------------------]] local Require = require 'Require'.path ("../common") local Debug = require 'Debug'.init () require 'strict' local LrApplication = import 'LrApplication' local LrDialogs = import 'LrDialogs' local LrFunctionContext = import 'LrFunctionContext' local LrPhotoPictureView = import 'LrPhotoPictureView' local LrView = import 'LrView' local showErrors = Debug.showErrors local function main (context)     local f = LrView.osFactory()     local catalog = LrApplication.activeCatalog ()     local photo = catalog:getTargetPhoto ()         if #photo == nil then         LrDialogs.message ("No photo selected")         return         end             local pictureView = LrPhotoPictureView.makePhotoPictureView ({           width = 400, height = 400, photo = catalog:getTargetPhoto ()})     local result = LrDialogs.presentModalDialog {         title = "Thumbnail test", contents = f:column {             f:static_text {title = photo:getFormattedMetadata ("fileName")},             pictureView}}     end     LrFunctionContext.postAsyncTaskWithContext ("test",     showErrors (function (context) main (context) end)) ... View more

The ipairs() iterator in the code fragment above will skip over entries in the top-level table whose keys are not integers (e.g. "status").  The headers are a common Lua idiom, adding a non-integer key to an array (a table where the keys are integers). Also, though you don't need it in this case, here's the more concise way to test whether a value "v" is a table: type (v) == "table" ... View more