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

B__R wrote: If I soft-proof the image using the Adobe RGB profile, it indicates that basically the whole image is out-of-gamut already at a saturation value of 50. Yet I can continue to change the saturation beyond 50 with noticeable results. In LR 4, which gamut overlay are you looking at? The one on the left always shows OOG for Melissa RGB (yes, I know, seems odd, you would think it would take the gamut of the profile selected but it doesn’t). The overlay on the right shows the OOG for the internal raw processing color space versus the profile you select to soft proof. ... View more

LR and ACR process data with ProPhoto primaries and a linear (TRC 1.0 gamma) encoding. The histogram and RGB percentage values use a 2.2 TRC (Melissa RGB). In terms of the disconnect between the display gamut limit and the editing space, not much you can do. If you are editing by moving a slider and all of a sudden you stop seeing the edit affect the preview, back off, you are probably editing colors outside display gamut. Also keep in mind, there are ‘colors’ defined in ProPhoto RGB that are not visible (and technically can’t be called colors). ... View more

Absolutely. No reason to build a single adjustment for one image while soft proofing and having to reinvent the wheel again. ... View more

Here is another soft proof video: http://digitaldog.net/files/LR4_softp... Very exciting new tool that trumps soft proof in Photoshop big time (way to go LR team). In terms of seeing the out of gamut (OOG) colors with the overlay, useful to some degree but I don’t think it is at all necessary to alter the image using HSL or other tools manually. Why? Because if you have a large gamut original and you are converting to say sRGB for the web, the conversion to sRGB will convert the data using the profile and hand this for you. Same with output to a printer. And with good profiles that take advantage of a Perceptual table, the non OOG colors may also be adjusted to attempt to honor the relationship to all colors. So it is useful to see the overlay to pick an output color space but to spend time adjusting the document to remove the overlay is I think a lot of work that is unnecessary. Gamut clipping is just a fact of life. Now if after conversion, you see something you really don’t like, and I find that very rare, by all means, try selective tools. I just don’t think you’ll find this necessary 9 times out of 10. ... View more

Jao vdL wrote: If you use the standard calibration mode, the Spyder 3 software will measure your room ambient light intensity and suggest a screen brightness based on that. This is actually not a bad idea as many rooms are so brightly lit that you might get the opposite problem (too light prints) if you calibrate to 100-120 cd/m2. 100-120 is good for fairly dark rooms. I’ve never seen a product do an especially good job here, certainly when one is using a viewing booth or system to view a print. Its probably a good starting point but every product I’ve ever used, one has to season to taste (test various settings for cd/m2 as well as white point to produce a visual match). For the OP, this might help: http://www.luminous-landscape.com/tutorials/why_are_my_prints_too_dark.shtml The ‘correct’ values are those that produce a visual match. Without some idea of how prints next to the display will be viewed, any suggestions for WP or backlight luminance are not real useful. YMMV. Newer, out of the box LCD’s have a tough time natively hitting low cd/m2 values (often below 140-150cd/m2). Of course, one can and should adjust the print illuminant intensity if necessary. ... View more

grandpahenry wrote: Does anyone have any experience with these and can share any "gotchas" with me. The flash galleries are not color managed so when you move from say Develop to Web, load a Flash web gallery, the previews will be slightly different (as well the resulting flash web gallery you view). In terms of LUTs, great when used within the panel itself as a tiny number of displays support (Eizo, NEC SpectraView), not useful when used on the graphic system. Ideally the graphic card LUT is totally linear, the LUT in the panel handles everything. ... View more

JFordOrl wrote: I do thing the very bright newer monitors are the real problem. I have the HP f1905b LCD which has the clear glass screen, and I think the 'b' stands for 'bright'. So perhaps the new (especially non-frosted screens) are just too darned bright compared to the output onto glossy hp Premium Photo Paper with hp's dye based ink sets. Thanks anyway everyone! See:http://www.luminous-landscape.com/tutorials/why_are_my_prints_too_dark.shtml ... View more

The reason why I suspect so many want a full 10-bit path on wide gamut displays dates back to a 2004 post by Karl Lang, the fellow who designed PressView and Sony Artisan. 1) A wide gamut LCD display is not a good thing for most (95%) of high end users. The data that leaves your graphic card and travels over the DVI cable is 8 bit per component. You can't change this. The OS, ICC CMMs, the graphic card, the DVI spec, and Photoshop will all have to be upgraded before this will change and that's going to take a while. What does this mean to you? It means that when you send RGB data to a wide gamut display the colorimetric distance between any two colors is much larger. As an example, lets say you have two adjacent color patches one is 230,240,200 and the patch next to it is 230,241,200. On a standard LCD or CRT those two colors may be around .8 Delta E apart. On an Adobe RGB display those colors might be 2 Delta E apart on an ECI RGB display this could be as high as 4 delta E. It's very nice to be able to display all kinds of saturated colors you may never use in your photographs, however if the smallest visible adjustment you can make to a skin tone is 4 delta E you will become very frustrated very quickly. 2) More bits in the display does not fix this problem. 10 bit LUTs, 14 Bit 3D LUTs, 10 bit column drivers, time-domain bits, none of these technologies will solve problem 1. Until the path from photoshop to the pixel is at least 10 bits the whole way, I advise sticking to a display with something close to ColorMatch or sRGB. 3) Unless the display has "TRUE 10 bit or greater 1D LUTs that are 8-10-10" user front panel controls for color temp, blacklevel and gamma are useless for calibration and can in fact make things worse. An 8-10-8 3D LUT will not hurt things and can help achieve a fixed contrast ratio which is a good thing. Only Mitsubishi/NEC displays with "GammaComp" have 8-10-8 3D LUTs at this time. Some Samsung displays may have this I don't test many of their panels as the performance in other areas has been lacking. Only the Eizo 210, 220 and NEC2180WG have 8-10-10 paths. If you really want to know... the path in the Eizo is "8-14bit3D-8-10bit1D-10" go figure that one out 😉 The 2180WG has an actual 10 bit DVI interface with a 10-10-10 path but nothing supports it so you can't use it yet - but for $6500 your ready when it does 😉 ... View more

Barry, none of this solves the big issue and questions in the posts; a full high bit path for all images in Photoshop (and hopefully other products like Lightroom). What appears to be the issue is Apple needing to further support something in the path. We have high bit panels. That’s helpful but not the same as having an entire high bit path. We have high bit cards (presumably the drivers are the issues or something to do with Apple, that isn’t clear to me). We have applications that can access the data (not the same as a high bit file support although that’s necessary too). The ramp.psd file supplied is one that attempts to empirically prove when the entire path is high bit due to no visible banding. ... View more

Barry Rudick wrote: Opened the file "ramp.psd" and see the individual "bars" of different densities but I do not believe I see banding. That’s the banding! And I see it too on the SpectraView II using all the setup steps you describe. So no, while the NEC Wide Gamut LCD monitors holds a 10 bit LUT internally in the monitor You will see banding on a Mac until presumably Apple fixes the bottleneck here (some say drivers for specific video cards if I’m reading them correctly). ... View more

Just to add to the conversation. The NEC Wide Gamut LCD monitors holds a 10 bit LUT internally in the monitor to return a solid 8 bit video data to the video card. You will not see banding. I’ve got a NEC PA271W hooked up as I believe you describe and still see banding using the ‘test file’ provided here: http://www.amd.com/us/products/workstation/graphics/software/Pages/adobe-photoshop.aspx (ramp.psd). I’d sure like to know what the solution is, if any to use this file to prove (if it does indeed prove) I have a full 10-bit path. ... View more

>So, you don't' have any of the apps that you used on those files 10 years ago? Sure, they just can’t be run! Are you a Mac user? Can’t run OS9 on Intel hardware. Can’t run Rosetta under Lion. You have 8 track tapes? Great. You have a machine that can play them? No, SOL. Got any files on Syquest drivers or floppies but no hardware to access that data? SOL. And yet, TIFFs I created in 1990 in Photoshop 1.0.7 can be opened TODAY on the latest hardware and OS. In dozens upon dozens of different software packages. Thanks to it being an open, non proprietary format. DCS files, PCD files, hosts of others? No such luck. Not good, especially when pixels I created 22 years ago the same way are accessible. Pixels I created 10 years ago are not. DNG is the TIFF of raw data (its a variant of TIFF). Based on the history, I’ll stick with that for archive of my precious raw data for obvious (to me) reasons. Sticking with proprietary raw, at least in several examples for me, is like having a 4x5 B&W neg and no enlarger or silver paper to make prints. ... View more

Right on. And yes, TIFF is a smart move if only based on history. TIFFs (an openly documented Adobe owned format) and PSD (not an open format but one still around thanks to Adobe’s longevity) I created in 1990 in Photoshop 1.0.9 and can be opened today in CS5 among other products. The nice thing about DNG is at least there’s a pretty high quality JPEG embedded of the current rendering if so set and desired. And if the history of imaging is any indication, a betting man will probably find DNG will hang in there a long time like TIFF and PSD. But there are no guarantees. I have lots of legacy, proprietary image files that are now saved on what amounts to drink coasters. FITs files from Live Picture, whatever Xres saved, whatever College saved etc. Of course I could render them as TIFFs and probably did if the image was important to me. I could do the same with raws but would rather not, considering them digital negs that improve with age. Improve in terms of new technology such as PV 2010 versus 2003. I fully expect to see Adobe improve their raw processing technology so my preference would be to have a raw format that has the best chances of being processed in the future. Again, based on history and having been burned more than once, DNG seems to be the good bet here. ... View more

>Because Adobe dropped support of the PhotoCD import plug-in from their latest products? The Plug-in was Kodak’s, it doesn’t run in Lion. The standalone Kodak software for DCS process is even older and requires OS9. So while its not impossible today, it requires hardware and OS’s that I don’t own any longer. Even if Adobe did drop support for DNG, its an openly documented format. Anyone who wanted to continue to render that data could. DCS files and probably PCD were not. ... View more

Or in less than 10 years, they might actually want to access the data (which today I can’t do with 10 year old PCD and DCS raws). ... View more

Now all you have to do is convince Adobe why. ... View more

http://forums.adobe.com/message/3245182: >It would be great to have an option whether to imbed XMP metadata into DNG file (as it is write now), or create XMP sidecar files as Lightroom does for proprietary RAWs. Answer why its not useful: Because it's half-baked in backup terms - you can't simply dismiss a swathe of LR work as "image relationships properties" - and it forgets that one valuable aspect of DNG is precisely that it is designed so you can safely write metadata to the format (though you'd be on your own if you do so to your only copy of the image....). Development time spent on sidecars for DNGs (JPEGs too, and why not TIFs?) would be unavailable for more important enhancements. John Beardy Uodate: Since you changed your post while I was writing..... 'And by the way, ACR can be forced to act like this. If you mark your DNGs as "read-only" ACR will not touch them, but will create sidecar XMPs. While Lightroom just removes "read-only" attribute and overwrites original file without shame' Then use ACR..... LR's ethos is to start from scratch, not slavishly replicate earlier tools. ... View more

Adobe feels comfortable writing back to lots of non proprietary file formats and uncomfortable writing back to proprietary formats they don’t control. That’s not a difficult concept for both legal and other reasons. Since there are oh so many proprietary camera formats that continue to come onto the scene every time a new camera is produced, the idea makes a bit of sense. You’re ‘stuck’ with sidecar files. But none of the above explains why DNG isn’t a valid raw choice. Its a different chose but not valid? ... View more

>dng is not a valid raw choice unless I can treat it like any other raw file. Why not? ... View more

Until (and if) Adobe provides this large engineering, there is this useful plug-in: http://regex.info/blog/lightroom-good... Don’t forget to read the reality check behind this plug-in you mention: http://regex.info/blog/2011-04-23/1753 ... View more

Alan, the point is ACPU’s bug is somehow related to output resolution as far as I can see. I’ve output targets of differing sizes and resolution and thus far, the size (40pixels per cm) hasn’t caused any scaling issues. 41 or 39 (or something else?) can’t say. It would certainly be useful to test in terms of reporting to Adobe. ... View more

ACPU is buggy in terms of scaling. It should’t. I don’t know the exact set of parameters that make it scale some targets but obviously not others. Here’s what I’d suggest. I don’t use argyllcms nor know what the resolution of their targets are. But targets built in several X-rite products I use don’t scale incorrectly. The resolution is 101.6ppi or 40 pixels per cm. I suggest you try resampling them (use nearest Neighbor in Photoshop) and see if they output at 100% of what they should. ... View more

Of course, command C, command P, why didn’t I think of that. Hopefully that simple code will do the job of showing you the layers and even let you edit them too. You’re a genius! ... View more

For one (and I suspect many other reasons), it would have to have support for layers, their opacity, blend modes and all the stuff in Photoshop to show you this data. Huge engineering when a solution exists that not only allows you to see the compounded effect of the layers, it allows tons of other applications to do so as well (the rendered embedded TIFF data). Bottom line is, you have to use the compatibility option, it aint going to change anytime soon if at all. ... View more

Bridge is a simple browser, it doesn’t have to alter or effect the layered data. Even the Mac finder can show a thumb of a layered TIFF without the compatibility on but not much more. >Bridge can read un-maximized psd files, so it is outrageous that Photoshop can't. Reading (seeing a preview) and editing the data are quite different tasks. ... View more

Very much so. You’ll save a good deal of disk space. But there is no totally free lunch, opening and saving the data is a bit slower. For me, its worth the small speed hit. ... View more