DonovanKirkwood wrote: ...and more importantly, the ability to update metadata direct into the original raw file (in my case Canon CR2), even when applying ACR settings via sidecar files to the .CR2 files. If you are talking about writing the .xmp metadata directly into an undocumented raw file format, that's a really bad idea. The .xmp metadata can actually be rather large (particularly if you have snapshots since each snapshot doubles the metadata size). The proprietary raw files from camera makers don't fully document where and how large the areas may (or may not) be reserved for adding metadata. So, writing any kind of metadata directly into a proprietary raw file formats is risky... ... View more

Removing duplicate posts...seems like a system error occurred. ... View more

Removing duplicate posts...seems like a system error occurred. ... View more

Removing duplicate posts...seems like a system error occurred. ... View more

dan3430 wrote: I'm often using the adjustment brush while zoomed in at 100% to move the photo I have to use the hand tool, then go back and select adjustment brush, and if the pin is no longer visible I can't select it again... so the only way to continue is to zoom out on the photo. You can temporarily access the Hand tool by holding down the Space bar, drag the image where you want and let go of the Space bar. Not need to change tools... You can also use the Page Up/Down keys to scroll one screen's worth when zoomed in. Command/Up/Down (Control for PC) will pan one screen. You can also use the Home key to move to the upper left or the end key to get to the lower right. Personally, I'm not sure what having scroll bars would add other than a lot of people don't seem to know the keyboard shortcuts already available... ... View more

thewhitedog wrote: Dan has told us that he works on troubleshooting in free moments here and there but that he is tasked by Adobe with other work that prevents him from putting in any serious time on the effort. This speaks far more clearly of Adobe's priorities than your self-serving assumptions. Unlike you, Dan actually works at Adobe, on the Photoshop Lightroom project. No doubt he revealed more than he intended when he told us of how difficult it is for him to find time to work on Lightroom troubleshooting. He was trying to discourage this kind of bootless crosstalk "chatter" so that he could more easily find the meat of the issues being discussed here - if any. At the risk of increasing the "chatter", what Dan wrote (and may regret even getting into the fray) is what HE'S tasked at doing. He ONLY spoke about what HIS role is and what HE'S doing at the moment. Dan is not the only engineer at Adobe. And while the Lightroom engineering team isn't big, there are more than one engineer working on Lightroom. So to draw any conclusions about Adobe's priorities are based on what Dan has said he's doing is to blow things way out of proportion. In fact there is a whole QE team that tracks bugs in the internal database. Melissa is one of those people (there are others) whole sole job it is to track bugs. How they are assigned and to whom is Adobe's business...but the odds are, every confirmed bug has been assigned to somebody for fixing. The fact that Dan doesn't get to spend as much time doing bug fixing (and laments the fact on the forums) is a testament to the passion and involvement Dan has. Rather than punish Dan for posting by concluding the Lightroom team is ignoring current bugs while "everybody" is focused on new features is doing Dan and the entire engineering and QE team a miss justice and will only serve to further separate users from engineers. Really, you don't want to be twisting Dan's words around. It will only make him even more reluctant to be as open as he has been. And the sad thing is that NONE of this crap will do diddle squat to actually fix any bugs. So, again, while some people CLAIM to have posted bug reports (and we only have their words for that, the BEST way to help the Lightroom team fix bugs is to report them fully and in detail. What does and doesn't get fixed is out of the user's (and Dan's) hands. ... View more

areohbee wrote: - Adobe would be foolish to exlude things from Lightroom soley to boost Photoshop sales. - Adobe would be foolish to not take Photoshops capabilities into consideration when choosing features to add to Lightroom. Both are true...if Adobe wanted to avoid competing with Photoshop at all, they wouldn't have produced Lightroom in the first place (and they almost didn't) and yes, some things that CAN be easily done in a pixel editor is factored in when they decide what to add to Lightroom. Since the primary mandate of Lightroom is for workflow and not low level image manipulation, there are things better left to Photoshop which is the reality of the situation. ACR/LR is tasked with those things that are appropriate for parametric editing...the rest is left to Photoshop. ... View more

TK2142 wrote: I'd have to accept if Adobe chose to never make LR a 80/20 application for portrait photographers because they want to sell PS too. I wouldn't like it but I would have to accept it in an adult way. Then accept it because in terms of workflow, any photography involving substantial retouching (well beyond a few sensor spots) is not what Lightroom is designed for...do the tone and color corrections in LR but the serious retouching is really gonna need to go elsewhere. ... View more

AlanUniqueName wrote: Ignoring for one minute perceived or subjective quality or performance issues with the Bibble 5 product today - it does appear to support Layers, non-circular regions for develop adjustment or painted regions for develop adjustments and also supports non circular heal and clone.    All of which are parametric and non-destructive in Bibble. Lightroom has painted in regions (and gradients) for develop adjustments...as far as I know, Bibble doesn't have multiple pixel layers. The one thing it does seem to have (aside from it's own performance issues) is non circular healing...which is indeed possible parametrically, but hasn't as of yet, shown up in ACR/LR (not saying it will or won't, just that it ain't there yet). But when you look into the technical aspects of storing edits in metadata, there is indeed a hard line between what can be done in pixel editing (PS) and parametric edits (ACR/LR). The more you pack into metadata the less efficient the metadata becomes. As it stands, spot healing and the adjustment brush and gradient masks are not really real...they are stored metadata description of what WILL happen once the file is processed. The more you add, the more complicated the instruction set becomes. That's one of the reasons that local adjustments in ACR/LR are limited to a subset of all the image controls. All of this is to say, it ain't easy and it's also something that doesn't really fall into the Lightroom/Camera Raw mandate. Past a certain point, the returns diminish and aren't worth the efforts. But this isn't a direct explanation for why some people are seeing severe performance problems...clearly something else is afoot. And that is something I'm pretty sure really does want to address. ... View more

TK2142 wrote: If I believed, as you did (and maybe still do), that LR cannot support substantial edits on single images for fundamental technical reasons then I would argue the same way as you ("horses for courses, use PS & LS what they were designed for"). However, I know that there are no fundamental technical reasons stopping LR to become an efficient image editor. Well, Lightroom hasn't changed from being a parametric editor, so yes, I sill believe that Lightroom prevue continues. Substantial imaging involved with retouching, layers, compositing–the things that Photoshop is designed for–won't be put into Lightroom because it's not technically feasible with the parametric editing paradigm. Could Lightroom force fit a pixel based editing module into Lightroom? Yes, I suppose but the interest in producing yet another pixel editing tool is simply not there. TK2142 wrote: As you know (and told me before): What is in LR's Develop module (e.g., the fact that there currently is no good cloning/healing/retouching support) is dictated by what is in ACR. What is in ACR is largely dictated by Thomas Knoll. If this is true -- and you told me it is -- then there is a problem for LR because LR developers cannot add cloning/healing/retouching on top of ACR, they have to rely on what is in ACR. But if Thomas Knoll is primarily interested in PS he has no need to add anything to ACR. Thomas is primarily interested in raw image processing (and the image quality of that processing) and Lightroom has benefited from that interest. No, he's not particularly interested in retouching or massive image manipulation, he's been there, done that. And Lightroom couldn't survive at all if it didn't leverage the Camera Raw processing pipeline. So, yes, Camera Raw and Lightroom are joined at the hip. I see no interest in anybody at Adobe severing that (as far as I know). So, the line in the sand is gonna be (as you paraphrased it): "We are offering two programs that have slightly overlapping functionality but if you are dealing with many images and occasionally have to considerably edit a single image then you need both programs". ... View more

thewhitedog wrote: You can purge your history one file at a time, which has been recommended to improve performance. However, I don't think Lightroom caches as much data as Photoshop so I doubt it would be comparable. The History in Photoshop is completely different than the History in Lightroom. In Photoshop, the History is part of the scratch file and stored on disk. PS's History is a real time cache of the actual pixel changes and that can indeed take a lot of HD space. Lightroom's History is really just a list of changes not the actual pixels. So it takes a lot less storage in the database. Lightroom's History is also persistent-meaning stored in the database, image by image and even after Lightroom is closed. Photoshop's is temporary and is lost when you close an image. I really don't think Lightroom's History is at all involved in the slowdowns some people are seeing so I wouldn't suggest clearing LR's History (unless you really don't want to keep the History of what was done to an image). ... View more

TK2142 wrote: What if people don't care about the "Shadowland stage" anymore? Also, note that no one asked for all of PS to be replicated in LR. Most would be happy if they could use the existing local adjustment without performance issues (I'm talking about "editing performance" not "rendering performance") and some additional support for healing/cloning/retouching. I don't think LR can aspire to an 80/20 claim if the spot removal tool remains the only support for healing/cloning/retouching. Well, I don't think they necessarily should...but if you want to understand the fundamental differences between "pixel editing" and "parametric editing" then you have to understand from where Lightroom came. When you edit pixels, the edits happen on the image pixels immediately (adjustment layers defer the processing until you flatten). But a healing or clone stamp tool actually applies the changes to the pixels. So there is no "growth" of data Photoshop has to track. In Lightroom (and ACR), the edits don't actually happen when the spots are places...the edits are stored in metadata as parametric edits that are deferred until actual processing (exporting). Keeping track of all the edits in metadata places a burden on Lightroom that Photoshop doesn't have to deal with. The more you add, the more complex the tracking of the metadata. When you then add in the increased processing time required for Process 2010 and add to that the Lens Corrections or other local based mask edits such as the Adjustment Brush or Graduated Filter, there is tremendous amounts of processing instructions that need to be stored. These instruction need to be updated and applied in the Develop module and processed and applied to the LR Previews, but they don't actually happen to the file until it's processed. This is really the line in the sand. Do you edit the parameters or edit the pixels. If you edit the pixels, the pixels change upon application of a process. In the case of parametric edits, they don't really happen (except for previews) until the image is processed. This "edit decision list" can become quite a heavy processing burden. But I agree in the grand scheme, users don't need to really understand the internal processing engines. But they should understand that there is a big difference between the way Photoshop and Lightroom handles image processing. LR is designed for spending time on lots of images while PS is designed to really work on one image at a time. Massive retouching and image compositing simply isn't in the cards for Lightroom because of the original "Shadowland" design decisions...it's really an either/or situation. ... View more

tgutgu wrote: My point was rather, that acknowledged and reproducible bugs and issues, don't get attention in visible results, and that no follow up communication takes place, even if the bug was acknowledged publicly here. So it is always a lottery game for the user, once a new release is announced: will my issue be fixed? Well, I don't disagree with this...it is somewhat a lottery. What does and doesn't get fixed is above my pay grade (meaning it ain't my job to decide). Regardless of the size of the Lightroom engineering team relative to the size of the Photoshop team, there is a thing called "triage" which tries to identify the most critical issues impacting the largest group of users. Those are the bugs that are deemed mission critical. But depending on the severity of the bug or issue, it may get deferred. There X number of hours times X number of engineers times X number of bugs that determine whether or not a given bug gets attention in a dot release. Clearly, Lightroom could use more engineers but not unlike a pro sports team, it's not a guarantee that throwing more engineers at a problem will result in improved productivity...there is a thing called "Team Chemistry" (I would point to the Miami Heat NBA team as an example of anti-gestalt). The best thing for users to do is to make sure they report issues and do so as completely as possible. The more people experiencing a give issue, the greater the likelihood it will get attention. That's really all users can do (and should do). ... View more

thewhitedog wrote: Jeff has managed to find a workflow that places no demands on Lightroom beyond what it can comfortably handle. But it's not clear if his strategy is anything more than a compromise with Lightroom's limitations. Nor is it clear whether those limitations are intrinsic to the software and unavoidable or if they are a result of the program's lack of maturity and unresolved flaws. Opinions seem to differ on the question. I'm intimately familiar with Lightroom's strengths and weakness...as a result I use it for what it's good at and avoid trying to do things it's not good at. If you are laying down a ton of spot healing spots on an image, I would suggest you are overextending the use of a tool that was designed for removing sensor spots. If you are trying to use spot healing as a major retouching tool, then yes, the parametric design of LR is not what you need. You need Photoshop. And while some people are trying to force fit Lightroom into a complete image editor, from the beginning back in the Shadowland stage, what it's genesis and reason for being was to provide a reasonably efficient workflow application. Think of Camera Raw with a mouth (import) and an anus (export). The goals were to provide an 80/20 or perhaps a 90/10 proposition-not a complete end to end image editing solution. If that's what you are expecting then I don't think Lightroom is the solution for oyu. On the other hand if doing what Lightroom does best–workflow-you are seeing severe performance issues, that's a different story. About all you can do is to try to help the LR team by reporting bugs and performance issues in as complete a manner as possible. The QE team for Lightroom does do it's best to get bugs logged and those reproducible bugs and performance issues are what gets worked on. The rest is just chatter... ... View more

imajez wrote: Besides if it were indeed the issue of parametric editing as a paradigm failing under heavy usage, ACR would have the same problems as LR. It doesn't from my experience. Images that cause LR to grind to a halt and crash work just fine in ACR. Well, Lightroom doesn't crash for me. But my experience indicates that the same images tend to behave about the same way in both ACR 6.x and LR 3.x's Develop module. I often go back and forth working on an image in LR (usually first) and then often in ACR (sometimes as a Smart Object) and the pain points of a lot of healing spots, Process 2010, noise reduction, and local adjustments seem about the same regardless of the application. That's the way parametric edits tend to add up to performance hits. If you are seeing a much slower LR performance than ACR edits, then that is a clue that something else is going on. If you wish to find that out and have the LR team do something, then bug reports; with all required system info, is what can help find the issues. And, until you provide that to the LR team, continued harping isn't gonna get you anywhere...look at the most message from Dan Tull (one of the brave LR engineers that does make an effort here in the forums) for the type of info required... The bug reports, when properly documented do indeed end up in the bug database and those bug reports whose info is sufficient to document and duplicate by QE get worked on... ... View more

imajez wrote: Jeff has said on several occasions he is not an Adobe employee, though he certainly does advise and give them useful feedback. Correct, I do not work for Adobe (otherwise there would be the employee tag by my name). But I do sometimes work with Adobe–primarily ACR, LR and Photoshop. Most recently working on image sharpening in ACR & LR (including the output sharpening in Print and Export). Look, there is a very clear line in the sand here for me. If you need to work on a hundred or a thousand images and optimize the tone, color and detail of the images, that's what Lightroom was designed to do. If you want to take your hero selects and spend time "perfecting" them which would include substantial retouching, masking and composites, you don't really want to do that in Lightroom–that's what Photoshop is for. Two separate tools with two different working philosophies. The fact that Lightroom can do as much as it does is a testament to the ingenuity of the engineers who came up with the parametric editing approach-largely Thomas Knoll and the ACR team and Mark Hamburg and the Lightroom team. And yes, the very existence of the spot healing tool (originally designed to eliminate sensor dust spots) tends to encourage users to use it for purposes it was really designed for such as retouching. The Adjustment Brush was similarly designed to do softer, local adjustments of tone and color that you couldn't do with a global tool. It is not designed to take the place of accurate masking and adjustments that you can do in Photoshop with adjustment layers. The fact that Lightroom users tend to try to finish off and "perfect" an image in Lightroom is where the parametric paradyne tends to bog down. Also, don't read what I write as an indication that neither I nor the Lightroom team fails to care about the future of Lightroom. We do...but general ranting and Pi$$ing & Moaning™ and attacking Adobe and presuming motives that don't really exist is simply unproductive...this thread is a prime example of a thread that was started to get specific information which then spun completely out of control and became a waste of bandwidth...oh, some good things did come out but it was precious little. If you want to have a positive impact, when you find a bug, report it. The bugs that get fixed are the bugs that can be duplicated by the QE team. If they can't duplicate, they can't fix it. If a particular bug is cropping up for a number of people on various platforms and is deemed mission critical, those are the bugs that get the most attention and are more likely to get fixed. Dot releases are primarily designed for new camera additions and maintenance updates (which include bug fixes where possible), not for changes in the functionality of the app. It's STILL not clear why some people have very poor performance while the vast majority don't. Personally, for me, LR 3.x is just about as fast as 2.x except when you factor in the greater processing requirements of the Process 2010 version and the addition of Lens Corrections. It should also be noted that new cameras tend to produce yet larger files. I'm using ACR/LR for processing 60MP P65+ MF files and I can tell you that adding a ton of spots and Adjustment Brushes will really slow down processing...but I don't really try to "finish" those images in ACR or LR. I use LR for selection editing and global adjustments (with the odd locale adjustment when needed) and do the heavy duty imaging on my hero selects in Photoshop and take them back to LR for organization. If you are having issues, a dispassionate description of the problem with enough information (platform, OS, camera, etc.) is the most useful thing you can contribute...all the ranting and raving is really rather counterproductive because it just makes noise without any useful signal... And I would caution against trying to read the tea leaves about Adobe's alleged motives about anything. Everybody I know who works on Camera Raw and Lightroom are highly dedicated and very hardworking. ... View more

JayS In CT wrote: Interesting history.. At what point did Raw Shooter Pro enter in..  I remember the day it was announced as we waited for LR 1.. Adobe bought Rawshooter in the summer of 2006. They bought it not so much to get the tech (although several features have been incorporated although rewritten from the ground up). But Adobe didn't really want the company Pixmantec so much as getting the main engineer Michael Johnson who ended up moving from Copenhagen to San Jose. Michael was a former engineer at Phase One working with their raw processing engine till leaving and starting Pixmantec. Ironically, another Phase One engineer, Christian Poulsen left Phase One to make the Imacon scanner and somehow ended up as CEO of Hasselblad (although he is gone now). ... View more

dougryan wrote: To address your statement above, you're right on one account. LR IS designed as a database driven app. But this isn't the underlying "issue"... The fact that Adobe took the time to develop this app as such, means that they had every intention of it running smoothly with thousands of images in tow. And I really don't get the logic of your saying that just because you can do something, it doesn't mean it's smart to do so?  If the Adobe engineers aren't thinking like a photographer when working on LR, then they have no business putting it on the market in the first place. I don't know how other photographers work, but I think that your example of x amount of healing adjustments and x amount of gradient filters is perhaps both exaggerated (would imagine that would be your intention to make a point) and irrelevant, given that most people here are likely experiencing slow downs with the absolute bare minimal of these adjustments. I know that I certainly am. Not exaggerated, the slow downs are from personal experience when adding too many spot healing and Adjustments Brush adjustments...LR/ACR is NOT designed to be a "final retouching and editing environment" but to address 80/20 of the edits photographers usually need to make. As you add spot healing and Adjustment Brush/Gradient Filters up to a certain point you go through the threshold of what's reasonable in parametric vs pixel editing... If you doubt my understanding of how and why Lightroom was developed, maybe you should do a little reading regarding Lightroom's initial development, read: THE SHADOWLAND/LIGHTROOM DEVELOPMENT STORY and see just how close Lightroom was to not being released...ironically, Mark Hamburg who was the founding engineer for Lightroom (AKA Shadowland) left Adobe and went to MSFT but came back to Adobe last year. It's not real clear what role Mark will have with future development of LR but he's at least back and involved (to a certain extent). ... View more

TK2142 wrote: I cannot shake off the feeling that some things are left as they are to give people a reason to look into Photoshop ($$$). It appears that Adobe keeps the LR team cheap to run because they lack the competition from other vendors and earn the bigger $ with Photoshop. I know that these thoughts are not popular among some forum members here, but what are we supposed to think? That it is impossible to remove the many remaining problems in LR? It would be useful if you understood the marketplace. As is stands, the market segment that represents "photographers" is a bit less than 10% of the total Photoshop user base. So, Adobe isn't spending too much time thinking of ways to maximize the buy into Photoshop by photographers. In the grand scheme of things, photographers really don't matter much to Photoshop sales (although traditionally, photographers tend to have a high degree of impact regarding features). As far as the size of the team, Photoshop's is very large relative to Lightroom or Camera Raw (whose primary engineers can be measured on a single hand). Lightroom's engineering team is small when compared to Photoshop's. Yes...why is that? Well, part of it is the relative size of the marketplace. As much as photographers like to think of themselves as really important, they simply aren't. A recent market survey indicates there may be 70K+ "professional photographers" in the US. Compared to Photoshop's 4+ million users, photographers are a drop in the bucket. Sorry, the marketplace simply doesn't support an engineering staff to equal Photoshop's staff. Part of Lightroom's underlying issues is the fact that LR is designed as a database driven application. Lightroom deals with thousands of images...Photoshop really is designed to deal with a single image (people who open multiple images in Photoshop often complain about Photoshop's performance because they don't understand how to work in Photoshop). So considering Lightroom's mandate, it actually does deal with thousands of image rather well. Clearly, there is a limit to the parametric edits done to a single image while maintaining efficient speed. Adding hundreds of spot healing or 10+ Adjustments Brushes and multiple Gradient Filters is gonna slow Lightroom (or ACR) down. Sorry, that's the reality of parametric editing. If you are adding more than 10-20 spot healing spots and more than 3-4 local adjustments, you are trying to force parametric editing into the realm of pixel editing better (and more efficiently) done in Photoshop. Just because you CAN do something in LR/ACR doesn't mean it's smart to do so. And no, I really don't think there's a conscience effort on Adobe's part to segment parametric/pixel editing and some sort of attempt at driving photographers to buy Photoshop in addition to Lightroom. If you have half a clue about the fundamentals, it's pretty simple; if you need to do a lot of specific local retouching and manipulations, you are better off doing so in Photoshop. If you need to adjust hundreds (or thousands) of images, you are better off doing it in ACR/LR. You use the tools provided for the purposes they are designed to do. And just to be perfectly clears, the Adobe User to User Forums are designed to have users help users. It's simply ignorant to presume that the inclusion or lack of posting by actual Adobe reps on these forums means anything in particular. Some of the engineers and product managers do come into the forums (essentially on their own) to try to drill down on specific issues they may be working on. This has been the way the forums have been set up and designed to run–even the beta versions of the various forums over the years. If you don't like it, you are welcome to quit visiting the forums but the odds that your complaints will change things are very slight. Deal with the reality instead of baying at the moon. You'll be better off in the long run. ... View more