I looked at the calibration of the monitor, but i know it’s not the monitor because the image looks fine in “windows picture viewer” application Windows Picture Viewer isn’t color managed. It is incorrect (even if you prefer the appearance). Camera Raw, Photoshop, Lightroom are color managed. The appearance is correct** even if you don’t like the way they look. Assuming the documents have the correct embedded profile and the display profile is correctly defining display behavior. ... View more

Marcin S wrote: Anyway, why Labs offer ICC profiles, when sRGB turns out to produce better result (closer to what could be seen on monitor)? They don’t and shouldn’t. There is no such thing as an sRGB printer. The sRGB color space is based on a theoretical emissive CRT display of the early 1990’s. I’ve never, ever seen an output profile that defines a print process that looks anything like sRGB and for good reason. Labs should supply output profiles used to transform sRGB or any RGB working space to the output space. Then you could soft proof the results, pick a rendering intent etc. When labs say  “give us sRGB” it is because they have decide to setup a workflow that benefits them in terms of pushing lots of files through the system. Not a workflow that produces the best options for their customers. Further, many of us are working with extended gamut displays. Those closer to are exceeding Adobe RGB (1998) gamut. So the idea that sRGB turns out better and is closer to the display doesn’t wash, especially if you look at the color gamut of these printers from good profiles: They often exceed the gamut of sRGB, sometimes greatly. ... View more

This may clear up a few of your questions: http://www.ppmag.com/reviews/200701_rodneycm.pdf ... View more

trshaner wrote: Blurb only provides one (1) printer profile for all paper types. It is CMYK and not useable in LR, only PS: http://www.blurb.com/resources/color_management I sent an email to Blurb Tech Support concerning the use of only one (1) printer profile. There response was that "they adjust the images" at the CMYK printer engine for the different paper types. Which makes the idea of using the profile for soft proofing pretty idiotic even IF LR could use it. What’s the point? Other than to try to convince users Blurb is somehow color managed. If you can’t load the profile used to convert the data, if you can’t control the rendering intent, if you can’t control the CMM (for Black Point Compensation), then you don’t need a profile. Just pretend it is pre 1995 and Photoshop and most other applications don’t have a clue what an ICC profile is. ... View more

In the past, the Edit In functionality could be flaky depending on the order you installed LR and Photoshop. Might want to reinstall Lightroom after Photoshop CS6. May work. ... View more

zut alors 5 wrote: I had the same problem and same error message (I run a Imac OSX 10.6.8). uninstall/reinstall didn't work. CS5 Clean script didn't work neither. I found a file named "Adobe PCD" in Usernam/application support/Adobe I removed it (I placed it on the desktop) I reinstalled Indesign CS5, an operation that created a new file "Adobe PCD" I started the application without any problem. I had to reenter the serial number of photoshop when I started that application. This was the fix for me as well! I had the same errors installing InDesign CS6. Removing the Adobe PCD folder and doing a new install fixed the issue. ... View more

So you only have CMYK? Too bad. At this point, ColorMatch RGB might be your best option due to the gamma encoding. Then there will be yet another conversion from ColorMatch to the actual RGB output color space for the ink jet. You’ll need a profile for that of course. ... View more

If you are going to use the native print driver from Epson, Canon etc, you want to feed it RGB. ... View more

The question becomes, do you want black to be defined as 100% K only or using the process the profile describes for black? For type, you’d probably want 100% K only and that is what should happen in ID. But for an image, not necessarily the case. You’ll get black assuming the profile correctly defines the CMYK process (for process black). ... View more

Adobe treats process black (which is what you are getting with the CMYK conversion) versus Rich Black (for say type) where the later is always 100% K with zero CMY. ... View more

Andrew, I don't think there is much progress, so I think it is time to not continue this discussion. That is a smart tact considering you ignore the points made, the questions asked of you but worse, and put words in my mouth such as “ Educate yourself before you talk further nonsense" or “ You were thus suggesting that LR (kitchen knife) cannot be turned into something that supports layers (screwing in screws).“ ... View more

You were thus suggesting that LR (kitchen knife) cannot be turned into something that supports layers (screwing in screws). This is incorrect. No, I stated (didn’t suggest) one should use the right tool for the right job, I stated that given much time and money, “LR Pro“ could do everything all single Adobe App’s do today. I never said it was impossible. I said it was impractical and unnecessary. And a Kitchen Knife is a great tool... in the kitchen (I’m not knocking that specific tool). The perceived chasm between "pixel pushing" and "parametric editing" is often used to explain to people that LR cannot do things that PS can do. So you say, but it wasn’t here. What was stated is that there is limited engineering time and money to make a kitchen knife into a screw driver. Both tools exist. Just get one of each. Or maybe you subscribe to the $10,000 military toilet seat mode of software among other things. The statement just says LR and PS are no different in how they need to change working copies. I disagree in terms of the results of the processed data. I could care less about the original since I never alter the original data in either application (the old Save As point). In the case of PS, nothing ever needs to be destroyed ever, as long as you keep inventing new names for every iteration. So the adjustment layer that has to be flattened doesn’t alter the data? And if it does, you are saying there are no rounding errors which are destructive to the data? BTW, whether the original is RAW or not is irrelevant. In either case LR does not overwrite original image data. In either case PS need not overwrite original image data. For the third time, the original data isn’t under discussion, it is what results from the original data! If you never want destructive edits of pixels, don’t edit them! ... View more

>>My point was to destroy the myth that is based on the assumption that "pixel pushing" and "parametric editing" are so fundamentally different that "pixel pushing" supports certain operations that "parametric editing does not". Who said otherwise? Myth? I took umbrage with something you wrote quite clearly: Here's how Lightroom is destructive just as Photoshop is: For instance, when you clone one area over another, the target pixels get destroyed. Ouch! >If you do not save over the original what gets destroyed? In the case of Photoshop, the iteration. In the case of LR, with raw data, nothing. >The only difference: LR uses metadata to remember how to "push"/"destroy" those pixels in the working copy again. The original data is unrendered raw data. There is nothing to destroy. If you edit that rendered data in Photoshop, then yes, there can and is some data loss. ... View more

>As far as previewing is concerned, the data used for creating the proxy preview is the "actual data". It is a proxy generated from the original data. How do you explain that the preview is the raw data? Clearly it isn’t. It was generated from that raw data source as a proxy preview, based on the current rendering instructions. And that preview (depending on the module) is a low rez version simply used to show you the current state of what the rendered data might look like IF you render it. >Rest assured I understand the difference between rendering a preview and rendering a final output file. Good. Because it is the rendered data we all end up with (whether we send it though the print module, ask for it to end up on the web, or export). There IS an option to print the data from a existing preview if you want to get precise here (Draft Mode Printing). >>However, you should have just included the part that followed the quote you truncated: "... in the true sense of the word when you don't save over your original but always keep inventing new names for your image versions." No, I think you are still contradicting yourself because the original data in this case of a raw is always left untouched. I’m referring to the rendered data. To say that applying a clone stamp as a metadata instruction in LR destructive and the same in Photoshop where one app takes the raw data and the instruction and renders virgin pixels from the two, and suggesting the same is true in a pixel editor is a poor way to describe the differences in the processing and resulting data. IF you want to say that non destructive editing is such that the original is left untouched, without taking the iterative data into the discussion, you can say we’ve had non destructive editing in every application ever made, since computers have provided a Save As command. With an Adjustment layer, the data (source) is non destructive. And the iteration is too, until you flatten the layer (or print the data). 99 times out 100, that has to happen. You started with exiting rendered data, you edited that data. There is some data loss due to rounding errors (we can agree that it is moot but the facts of the resulting data are what they are). When you take raw data and instructions, you render data for the first time. How then is this destructive? >>In my initial comment, I was using "destructive" as many use it in this context. Later on, in a different comment, I remarked that "destructive" is a problematic term. Yes, it is. Especially when one doesn’t separate the original data from the derivative. ... View more

>>The preview, i.e., the image you see in the Develop module, is the result of a sequential application of changes to a working copy. It is a proxy preview and has no direct bearing on the actual data which as yet has not been edited (let alone, as you incorrectly point out, have an destructive edit applied). You’d do yourself some good, save the rest of us some time if you would read the Adobe White Paper (URL above) by Peter Krogh. You don’t need an engineer here, the paper was produced by Adobe and written by an authority on the subject. >The term "destructive" is somewhat inappropriate in discussions like these because even pixel editors like Photoshop are not "destructive" And yet today you wrote: Here's how Lightroom is destructive just as Photoshop is : For instance, when you clone one area over another, the target pixels get destroyed. Ouch! ... View more

http://www.adobe.com/digitalimag/pdfs... ... View more

>Here's how Lightroom is destructive just as Photoshop is: For instance, when you clone one area over another, the target pixels get destroyed. Ouch! That, like much of your post is incorrect and shows a huge misunderstanding of the processing. There are no pixels affected until you render the data (original, be it raw or existing rendered data plus instruction of edit used to create new set of pixels). The area you see in the preview is simply what will, I repeat will result only if you render the data to a new iteration. It is not destructive, it has no effect on pixels that as yet have been rendered. ... View more

>It would be great to have better local adjustments a simple rotate control on the clone tool would be fantastic. Now you’re talking. Probably not huge engineering and something you don’t see at all in Photoshop with parametric edits. I still think that for the foreseeable future, selective cloning in LR will be far less robust than Photoshop which is after all a pixel editor with very precise controls. I’m not asking LR to do the kind of work a high end retoucher could do in PS (cause I own PS and would use that anyway). Take out a row of telephone poles and lines in an image in LR? Crazy. But remove a pole sicking out of one person’s head? OK, I’m game. It boils down to using the right tool for the job. You can use a Kitchen Knife as a screwdriver. Occasionally. Maybe with one screw. If you are a carpenter, you’re going to use that high quality electric drill to do the job. And you are not going to use that tool to cut your steak. Trying to make LR into Photoshop is as folly as trying to make Photoshop into InDesign or Premier. Given the time and money, probably possible. Would be hugely expense for all users, hugely complicated to use. ... View more

>So why so anti layers? Because there are existing tools that exists that were built to do this, Photoshop (or Elements) and because adding this would be huge engineering and would suck resources from a much smaller engineering team to implement functionality more beneficial for the larger LR audience and it’s core aim. I suppose if a year ago folks could vote for either, PV2012 or Layers, they would vote for Layers? You’d really prefer to duplicate functionally that already exists in many products and continue with poorer raw rendering processing? Or you’d swap Soft Proofing using metadata edits on Virtual Copies that interface with the Print Module for Layers? Just about anything could probably be built into LR but at what price? It is all about resources and building a tool that is designed for a specific task and audience. You want layers, get Elements or Photoshop. You want a word processor, get MS Word or similar. ... View more

>There is no reason why Lightroom couldn't be developed to be both a parametric adjustor as it is at the moment plus a bitmap pixel editor with layers. Well there is no reason why Lightroom couldn’t be Illustrator, InDesign and Photoshop all rolled into one huge, expensive application assuming you are willing to wait for engineering to do this (and Adobe was willing to spend the time and money too). Yup, LR Pro that does all of the above, due to ship summer of 2016 at a mere $3000. Anything is possible. Now back to reality... ... View more

Challange? I asked a question which so far is unanswered about viewing CMYK in a product that has only an RGB processing path. We can all vote that the moon should be made of cheese. That will not change it to cheese. ... View more

>I think CMYK softproofing is a good idea and validates that LR is an end-to-end workflow solution for professionals... one of LR's most important constituencies. So you’d soft proof CMYK, knowing you can’t get CMYK out of LR? ... View more

I'd like to be able to reset individual colour curves without affecting the RGB curve. For example, if I have changed the colour curves and am applying the same settings to several photos but then decide to convert some to black and white, they will be tinted because of the colour curve adjustments. Easily corrected with Saturation/Vibrance or HSL controls. The effect is built into the curves since it is desirable in most (more cases). Also see:http://www.luminous-landscape.com/ess... ... View more

>>Nothing much sees to have improved and all the (supposed) new items have been borrowed from Aperture 3. You’re either kidding or really haven’t looked very deep! Just the 2012 PV is a huge improvement in raw rendering over PV2010. Just the improvements in highlight recovery alone within PV2012 is huge. Let alone Soft proofing, better smart collection options, DNG improvements etc. Nothing at all like Aperture. As for Layers, don’t hold your breath. And LR has to render out all additional parametric edits you make from a layered doc (it has to be processed through it’s engine) so you lose the layers. If you follow a logical workflow for processing your raw data, using LR as the tool it is, then pass the rendered data to Photoshop which is a pixel (not parametric) editor, use layers and be done with the Develop module as you should, you’ll be far better off. The two tools are vastly different! You can’t turn a kitchen knife into an effective tool to handle screwing in screws any more than you can use Photoshop’s type tool as a substitute for MS word or InDesign. Use the right tool for the right job instead of hoping all your tools are Swiss Army Knife compromises. ... View more

Bill_Janes wrote: You didn't give a link to Eric's post, http://forums.adobe.com/thread/947403?tstart=30 The current behavior is a bug and will be fixed. All you have to do is toggle differing profiles and you’ll see that the display OOG overlay doesn’t change a lick. That is because the profile you select isn’t being used along with the display profile for the OGG overlay. That is the bug. ... View more

Bill_Janes wrote: I think there is some misunderstanding here. I don't have Lightroom but have looked at Julieanne Kost's video on softproofing in LR4, and what you stated is not my understanding of how the softproofing overlays work. As I understand things, the overlay toggled by the icon on the left does not compare the gamut of Melissa to that of the monitor Yes it does, Eric Chan of Adobe had confirmed this in another thread on the beta4 forums and confirmed this behavior is a bug! It is supposed to compare the gamut of the display to the gamut selected in the soft proof mode. As for Kost’s video, the use of the gamut overlay appears to me (and at least a few others) in terms of editing to remove said overlay, a bad idea. See:http://digitaldog.net/files/LR4_softproof2.mov As Eric states in the same thread where he confirms the bug, this is more educational than a useful means of editing. Let the ICC profile clip the gamut. ... View more

What part of “LR has an RGB processing path” wasn’t clear? You’d be willing to have LR develop a big, ugly set of CMYK preferences as we have in Photoshop, only to soft proof and not convert the data? You have two copies of PS, one more than you need to soft proof and convert. What’s next, pop Illustrator or InDesign into LR? The book feature isn’t going to fly here because there are no actual CMYK profiles for it to use (just one generic profile that doesn’t define the print process). Even if you could load the generic Blurb profile for an LR soft proof, what you were viewing would be incorrect. So that we have a book module, at least for this one provider doesn’t justify CMYK anything. If you can get Blurb to provide all the ICC output profiles for all CMYK processes, you’d be much closer to justify the ability to soft proof in Photoshop let alone LR. ... View more

Here is a 2nd video that I think illustrates why trying to manually deal with OOG colors is not all that useful: http://digitaldog.net/files/LR4_softp... By all means, test the waters yourself and report back. ... View more

Considering LR is a fully RGB processing path, it can’t convert to CMYK, what would be the point of soft proofing CMYK? You can (and should) do both in Photoshop. ... View more

The Left Gamut overlay is kind of useless IMHO. It compares the display gamut to Melissa RGB. The Right Gamut overlay compares Melissa RGB to whatever profile you select. More useful. The Left overlay could be more useful if it was based on the profile you select (show me how my sRGB-like display gamut compares to the gamut of a profile I just selected to make a print). But alas, it doesn’t do this. I’m trying to find out the logic of the current behavior. I feel it would be far more useful in Develop without a soft proof since you are editing in MelissaRGB (kind of, it is 1.0 TRC), and seeing how that color space is out of gamut compared to the display would be real useful. ... View more