Weird behaviour when soft proofing.

I'm finding that if I open an image in DEVELOP, when soft proofing is ALREADY switched on, the sliders usually grey out as soon as I make a first adjustment, the histogram display disappears as well. Toggling the soft proof check box brings everything back to life.

I'm on Win 7 Pro 64, HP Z800, Nvidia Quadro FX3800, Xeon 6 Core. Wacom Intous.
...and I'm still getting the problem. I suspected maybe the Wacom tablet so disabled the service but still get problem with a mouse. I created a new catalogue and imported some different images,
still get the problem, except for the FIRST time I try it with a new image, then everything's OK but subsequent tries give the problem. The files are either layered tiffs of finalised images or DNG or Hasselblad 3F
originals.
The grey outs occurred after the first adjustment, after choosing "Make Proof Copy". I have now checked the "Don't Ask Again" button and the problem seems to have gone away. Just a little glich I guess.
Cheers.

Similar Messages

Bug: Previews not generated properly when Soft Proofing is enabled in LR5, LR5.2 RC

I am experiencing problems with previews in Lightroom 5.0 and Lightroom 5.2 RC.
I have noticed incorrect previews under the following circumstances when Soft Proofing is enabled:
1. When I make modifications (like cropping), the preview in the Navigator panel does not update until I uncheck (and recheck) the Soft Proofing option.
2. When I am paging through several images at 100% or greater, the view in the main window, while zoomed in correctly, does not provide the correct resolution (blurry) until I either uncheck (and recheck) the Soft Proofing option or zoom out and zoom back in.
I am using:
Lightroom 5.0 64-bit, Lightroom 5.2 RC 64-bit
Windows 7 Ultimate 64-bit
Canon CR2 RAW files
16GB RAM, plenty of local disk space
Note: I have not done extensive testing on this, but many of these files are stored on a network drive, so I don't know if there is some sort of bug in the optimized routines for network drives/folders.

I have the same problem as michaeln2 and adobe 1230931.
I use Lightroom 4.4.
When I am in the Develop screen and I turn on Soft Proofing, then about 20% of the time the image goes blank. If I go back to Library view and reenter Devleop, sometimes the image will show up, sometimes not. If I advance to other images, sometimes they'll show and sometimes not in the Soft Proofing mode. Sometimes rotating an image in Library mode and going back into Develop "wakes up" the Soft Proofing and sometimes not.
In other words, the soft proofing feature is, as michaeln2 says, functionally useless. I'm surprised that no fix has been posted on this thread. No point upgrading to Ver 5 either...as it seems to be buggy there as well. Help!

Cant check the box Simulate paper & ink when soft proofing is on

Need help please,
I cant check the box for Simulate paper & ink, when soft proofing is on. Im using Lightroom 4.1, with a Windows 7 PC
Thanks
Mike

It'll only be available for specific profiles. Which profile do you have selected?

When Soft Proofing in LR4 most of my loaded printer profiles are not visible

I am running LR4 and CS6 on an HP desktop with 4Gig Ram, Win 7 Home, Profiled Monitor using DataColor
In CS6, all my loaded ICC printer profiles appear when setting up the soft proofing...
In LR4, most of the profiles do not appear...
The problem is that I print to an Epson 7600 CMYK printer with UltraChrome Ink and mostly on Canvas so I need to proof for that environment.
The problem is that I print to an Epson 7600 CMYK printer with UltraChrome Ink and mostly on Canvas so I need to proof for that environment.
Photos of the two different pull downs are attached.

dmcrescent wrote:
Not sure what makes you think the Epson 7600 is a CMYK printer, but it isn't. You may be running a CMYK RIP attached to it, but the printer accepts RGB data, not CMYK. The only reason I can think of needing to profile in CMYK would be if you were using profiles generated for a press. I'm sure there may be others, but can't think of one off the top of my head.
Well you can send either RGB or CMYK to the printer but you have to first setup the proper driver for either. Unless you are proofing (make my Epson simulate a press sheet), I can’t think of any reason to send it CMYK data. The limitation is the driver in terms of what you send it. With a 3rd party driver (might be a RIP, might not) it can be possible to send CMYK data to the Epson. Epson bundles the ColorBurst product for this purpose (press simulation, use of CMYK profiles).
Since the Lightroom path is solely RGB, it can’t do anything with CMYK data. So the profiles are filtered out of the list. And don’t expect this to change anytime soon or ever. If CMYK is your game, well you need Photoshop or some other application to handle this data. And you’ll need another driver. So in context of this post, CMYK is simply not a possibility and that is why the profiles are not accessible.

Weird behaviour when applying XLST in PL/SQL

I came across this strange behaviour when applying XSLT to an XML document. Below is a simplified version, based on some code that I found in OTN
declare
indoc VARCHAR2(2000);
xsldoc VARCHAR2(2000);
myParser dbms_xmlparser.Parser;
indomdoc dbms_xmldom.domdocument;
xsltdomdoc dbms_xmldom.domdocument;
xsl dbms_xslprocessor.stylesheet;
outdomdocf dbms_xmldom.domdocumentfragment;
outnode dbms_xmldom.domnode;
proc dbms_xslprocessor.processor;
buf varchar2(2000);
begin
indoc := '<emp><empno> 1</empno> <fname> robert </fname> <lname>
smith</lname> <sal>1000</sal> <job> engineer </job> </emp>';
xsldoc :=
'<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output encoding="utf-8"/>
<xsl:variable name="CR">
<xsl:text>
</xsl:text>
</xsl:variable>
<xsl:template match="/">
<xsl:value-of select="$CR" />
<xsl:value-of select="$CR" />
</xsl:template>
</xsl:stylesheet>';
myParser := dbms_xmlparser.newParser;
dbms_xmlparser.parseBuffer(myParser, indoc);
indomdoc := dbms_xmlparser.getDocument(myParser);
dbms_xmlparser.parseBuffer(myParser, xsldoc);
xsltdomdoc := dbms_xmlparser.getDocument(myParser);
xsl := dbms_xslprocessor.newstylesheet(xsltdomdoc, '');
proc := dbms_xslprocessor.newProcessor;
--apply stylesheet to DOM document
outdomdocf := dbms_xslprocessor.processxsl(proc, xsl, indomdoc);
outnode := dbms_xmldom.makenode(outdomdocf);
-- PL/SQL DOM API for XMLType can be used here
dbms_xmldom.writetobuffer(outnode, buf);
dbms_output.put_line(buf);
end;
I would expect this to output two carriage returns and this is what I get with xsltproc on the Linux server. Instead, it outputs the entire source XML document without the tags, as shown below.
1 robert
smith1000 engineer 1 robert
smith1000 engineer
Now, if you change the definition of the CR variable to add some text, for example to
<xsl:variable name="CR">
<xsl:text>XX
</xsl:text>
It outputs:
XX
XX
which is what I would expect.
Does anyone have any idea what is going on here? Changing the variable definition to <xsl:variable name="CR" select="'
'" /> fixes the problem by the way.

I came across this strange behaviour when applying XSLT to an XML document. Below is a simplified version, based on some code that I found in OTN
declare
indoc VARCHAR2(2000);
xsldoc VARCHAR2(2000);
myParser dbms_xmlparser.Parser;
indomdoc dbms_xmldom.domdocument;
xsltdomdoc dbms_xmldom.domdocument;
xsl dbms_xslprocessor.stylesheet;
outdomdocf dbms_xmldom.domdocumentfragment;
outnode dbms_xmldom.domnode;
proc dbms_xslprocessor.processor;
buf varchar2(2000);
begin
indoc := '<emp><empno> 1</empno> <fname> robert </fname> <lname>
smith</lname> <sal>1000</sal> <job> engineer </job> </emp>';
xsldoc :=
'<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output encoding="utf-8"/>
<xsl:variable name="CR">
<xsl:text>
</xsl:text>
</xsl:variable>
<xsl:template match="/">
<xsl:value-of select="$CR" />
<xsl:value-of select="$CR" />
</xsl:template>
</xsl:stylesheet>';
myParser := dbms_xmlparser.newParser;
dbms_xmlparser.parseBuffer(myParser, indoc);
indomdoc := dbms_xmlparser.getDocument(myParser);
dbms_xmlparser.parseBuffer(myParser, xsldoc);
xsltdomdoc := dbms_xmlparser.getDocument(myParser);
xsl := dbms_xslprocessor.newstylesheet(xsltdomdoc, '');
proc := dbms_xslprocessor.newProcessor;
--apply stylesheet to DOM document
outdomdocf := dbms_xslprocessor.processxsl(proc, xsl, indomdoc);
outnode := dbms_xmldom.makenode(outdomdocf);
-- PL/SQL DOM API for XMLType can be used here
dbms_xmldom.writetobuffer(outnode, buf);
dbms_output.put_line(buf);
end;
I would expect this to output two carriage returns and this is what I get with xsltproc on the Linux server. Instead, it outputs the entire source XML document without the tags, as shown below.
1 robert
smith1000 engineer 1 robert
smith1000 engineer
Now, if you change the definition of the CR variable to add some text, for example to
<xsl:variable name="CR">
<xsl:text>XX
</xsl:text>
It outputs:
XX
XX
which is what I would expect.
Does anyone have any idea what is going on here? Changing the variable definition to <xsl:variable name="CR" select="'
'" /> fixes the problem by the way.

Weird behaviour when spanning colums in GridPane

Using column span seems to influence the size of all the columns spanned in a weird (as in: I can't figure it out) way.
With the code below, you would expect the second column to be the size of the button (the only node placed directly in it), and the first column to take up all remaining space.
But for some reason, the second column is bigger than the button. Note that in my original code (way more complex than the example below) the second column was over 300 pixels too wide.
The only workaround I found was to set the preferred size of the nodes in the first column, and to set a preferred column size as well (see commented lines). Nothing I tried on the second column seemed to have any effect.
Am I missing something here, or is this a bug ?
GridPane root = GridPaneBuilder.create()
        .padding(new Insets(10))
        .hgap(15)
        .vgap(15)
        .gridLinesVisible(true)
        .build();
root.getColumnConstraints().addAll(
        ColumnConstraintsBuilder.create()
            .hgrow(Priority.ALWAYS)
            //.prefWidth(200)
            .halignment(HPos.RIGHT)
            .build(),
        ColumnConstraintsBuilder.create()
            .hgrow(Priority.NEVER)
            .build());
TextField text = new TextField();
//text.setPrefWidth(200);
GridPane.setColumnSpan(text, 2);
root.add(text, 0, 0);
Button cancel = new Button("Cancel");
root.add(cancel, 0, 1);
Button save = new Button("Save");
root.add(save, 1, 1);
Scene scene = new Scene(root);
primaryStage.setTitle("GridPane Span Test");
primaryStage.setScene(scene);
primaryStage.show();

I think it is bug
Re: Strange GridPane behaviour in relation to column width

Weird behaviour when drilling down in time hierarchy

Hi Experts,
We have time hierarchy
year--->quarter--->month--->week--->day.
But when im drilling down from Quarter it is showing the week level and not the month level and then again if i m trying to drill down from quarter then it is showing the month.
What can be the issue here?
Regards

Hi,
just check what u have set into preferred drill path tab for Logical level quarter.
Regards,
Vikas
Edited by: user7312087 on Jul 7, 2009 12:27 AM

Rendering intent when displaying, exporting or soft proofing?

I am trying to make use of soft proofing to adjust my images for a given output device for which I have ICC profiles. The two profiles I am playing with are for a Lambda and a Fuji Frontier. The Lambda working space almost fits within Adobe RGB, it exceeds it in only a few places but is noticeably smaller for a number of other colors. The Frontier working space is for most colors a bit smaller than the Lambda and about equal for only a small number of colors. The Frontier working space would also almost fit into sRGB (to give you an impression of its size).
When soft proofing with Aperture, dark greens desaturate more with the larger Lambda working space than with Frontier one. If the rendering intent were relative colorimetric, colors should be clipped more and limited by the smaller working space of the Frontier. If perceptual is used then colors would in general be somewhat more compressed (ie, desaturated) with the smaller Frontier working space. But I see rather the opposite. In short, neither explanation makes sense.
So I tried exporting from Aperture into Adobe RGB and ProPhoto RGB hoping that both would be big enough to contain most of the internal gamut of Aperture in order not to require much compression or clipping when converting from the internal color space of Aperture (I saw no difference between Adobe RGB and ProPhoto RGB in the exported files, so I guess both are large enough for my purposes). And I then converted/soft proofed these files from Photoshop into my two output profiles. More options (different rendering intents, black point compensation) but none seemed to really match what Aperture was soft proofing. I still have a lot of ideas what to try out but if anybody could shed some light on rendering intents and soft proofing with Aperture, it would be very much appreciated.
(A related question, what rendering intent is used when converting colors, let's say defined in the Lab space in Photoshop, to the screen? I guess this is defined in the monitor profile, which in turn is created by the monitor calibration software, and therefore might depend on the latter. I would guess some kind of perceptual, but how the colors are really fitted and converted from the larger Lab color space into the smaller monitor one might very noticeably been different calibration software and will be different again for the monitor profile supplied by Apple.)

I went on about this a little more scientific by creating an image with three rectangles: red, blue and green.
All of them are 100%, e.g. (255, 0, 0). Colorspace: ProPhoto RGB.
Results when exporting the images to AdobeRGB and sRGB, concentrating on the reds:
- sRGB looks very washed out
- AdobeRGB looks a bit washed out
- Original ProPhoto has so much red that it almost drives me nuts
Now, I would really expect similar results when activiating soft proofing.
But when selecting either AdobeRGB or sRGB, the reds always drive me nuts.
There is just no difference at all to the original ProPhoto image!
Conclusion 1: Dorin, you were right, previews are in AdobeRGB. What I saw in the reds was the difference between ProPhoto and AdobeRGB. Somehow my screen seems to have extreme reds (calibrated recently with an X-Rite ColorMunki Display).
Conclusion 2: Soft proofing with AdobeRGB and sRGB really DOES NOT WORK!

Display profiles and soft proofing Windows RGB / Monitor RGB

This might have asked before, but I did not find any definite answer for this. Sorry this gets a bit long.
Short question:
What's the difference between softproofing with Windows RGB and Monitor RGB targets? I see differences in my image between these targets.
Long question(s):
Here's some reasoning.. let me know when I go wrong.
I have hardware calibrated my display Spyder 3 elite to sRGB standard. I have understood that the generated display profile contains a LUT table that affects gamma values for each RGB component, so that affects both gamma and color temperature. That table is loaded into video card when Windows starts. In addition to the LUT table, the display profile contains what? Probably information on what color space the display has been calibrated to. Does that matches directly with the LUT table information, but may deviate from sRGB in the case my monitor cannot reproduce sRGB 100%?
Now if I have image that that is in sRGB, but the embedded sRGB profile has been stripped away, should any non color management aware image viewer show the colors properly, if it is assumed that 1) my monitor can handle full sRGB space and 2) my monitor was succesfully calibrated to sRGB and the LUT table has been loaded into video card?
Or does it still require a color management aware program to show the image, which implies that the LUT table information alone is not enough and the display profile contains some extra information that is needed to show the image correctly? I would think this is true, as I needed to turn on color management in Canon Zoom Browser to see images in it the same way as in Photoshop.
Now to the original question, what's the difference in Photoshop when soft proofing with Windows RGB and Monitor RGB targets
I read from www.gballard.net that
Photoshop can effectively "SoftProof" our web browser color:
Photoshop: View> Proof SetUp> Windows RGB
Photoshop's Soft Proof screen preview here simulates how unmanaged applications, web browsers, will display the file on 2.2 gamma monitors, based on the sRGB profile. If the file is based on sRGB and our monitor gamma is 2.2 and D/65 6500 degrees Kelvin, we should see very little shift here, which is the goal.
Photoshop: View> Proof SetUp> Monitor RGB
THIS IS WHERE the color-brightness-saturation problem will repeat consistantly.
Soft Proofing Monitor RGB here strips-ignores the embedded ICC profile and Assigns-Assumes-Applies the Monitor profile or color space.
The color and density changes seen here show the difference between the monitor profile and the source profile sRGB.
I'm not sure how to read that. Assume here that my monitor has been calibrated to sRGB and the PS working space sRGB. Do in both cases photoshop strip away color profile from the image at first? What happens after that? Does in Windows RGB case Photoshop pass the color values as they are to display? What does it do in "Monitor RGB" case then? Does it assign my monitor profile to the image? If it does, does there also happen conversion from one color space to another? In either one conversion there must happen as the soft proofing results are different. Does either one cause "double profiling" to the image as the monitor is already calibrated?
Thanks

Windows defaults to sRGB if you don't calibrate your monitor so untagged sRGB files should display (more or less) correctly in applications that don't know about color management on systems with uncalibrated monitors.
When proofing against Windows RGB you're proofing against sRGB, it will show you how applications that don't know about color management on an uncalibrated monitor will show the image. This is what you proof against if you want to see how the image will display in web browsers.
When you proof against Monitor RGB, Photoshop will assign your monitor's icc profile to the image which tends to be utterly useless most of the time.

Can I soft proof in LR4 like I can in PS CS5?

I haven't used LR 4 yet, but did view the soft-proofing tutorial.
I applaud Adobe for adding this functionality in LR4. It was one of the most obvious lacking features in the previous version, and I've still been mostly doing all my printing through PS CS5.
While soft-proofing is not a perfect replacement for test printing, I've been mostly satisfied with proofing in CS5.
Proofing in LR4 seems a little different, but by using a virtual copy it looks like if I use my printer/paper profile I should theoretically be able to not only be able to deal with color gamut issues, but also adjust contrast & brightness to more closely match my original developed image, and could compare the original with virtual copy in compare mode. Is it that simple? And if so, why is there a contrast & brightness adjustment in the Print module? That latter adjustment would be similar to what one goes through in PS CS5 when soft-proofing prior to printing. However, why have it if it can be done in the Develop module......and regardless, from the video tutorial it looks like you can't preview the image after making those adjustments in the print module nor compare it with the original......thus forcing one to make multiple prints until the result is satisfactory.
Just seems to me there is a bit more tweaking to do in LR4 to make the soft-proofing more functional. Or, perhaps I'm too stuck with the paradigm set forth for soft-proofing in PS and need someone to clarify how I can achieve the same result in LR just as confidently.

Beaulin Liddell wrote:
BTW, I've benefited immensly from your and Martin's Evenings books.......you've never steered me wrong.
Thanks for the kind words...but LR4's soft proofing is worth the effort to use. It really is better than Photoshop's soft proofing. I'm still on the fence regarding VCs vs Snapshots for soft proofing It's a tossup but the VC part has been built in while making a snapshot wasn't.
The advantage of LR4's soft proofing is you get the ability to do a Before/After while still using the full range of LR4's controls to adjust the printed version. Makes it really easy to nail great print (assuming you have good print profiles).
As for the Print module Brightness and Contradt...that's really a special case that doesn't involved color managed output. It's a crutch for those who don't have a locked down system. It's east to tweak but you have to make example prints since the controls don't actually display but only impact the output. I tend to avoid that.

Colors in print preview not matching colors in soft proofing

Hi There,
Just wanted to print a new photo and realized that the colors in print preview do not match the colors in soft proofing. In both cases I selected the same icc profile and rendering method. The print colors matched the colors in print preview. I never had a problem so far. All new prints will be checked with soft proofing and adjusted when necessary. I never paid attention to the color rendition in print preview and all prints perfectly matched the colors from the soft proofing. I was surprised when my print came out of the printer and the colors weren't matching the soft proofing colors, but that of the print preview.
I don't understand why Photoshop renders the colors differently in the first place. Please see attached screenshot for the difference in the blue/cyan colors.
I would appreciate if anybody could point me in the right direction in what is causing this difference. I don't care if the print view colors will match the print, but I do care when soft proofing is not working.
Thank you.
Best regards,
D.

Here are some addtional details:
PS 13.1.2
Mac OS X 10.8.4
12 GB Ram
60 GB free disk space
I printed the same photo from two other computers (MacBook and iMac) with different PS versions (CS4 and CS5). The prints turned out identical to the first one which matches the print preview color rendition on my main computer (MacPro) running CS6. Strangely the colors in print preview of CS5 on the iMac renders the colors identical to the soft proofing colors.

[LR 5] Soft Proofing - Monitor Gamut Warning vary with printer profile ?!?!

Hi,
There's something I can't understand when using the soft proofing feature in LR.
The Monitor Gamut Warning feature (top left icon in the histogram when soft proofing is enabled) is supposed to show us what colors in the current image cannot be reproduced on the display. Right ? If I understand well, the warning computation is made by comparing the current image (virtualized by LR in the Melissa RGB color space) to the gamut of the display (read from the active calibration profile).
So why does LR show different "out of gamut" areas for the display when I change the printer profile selected when using soft proofing? This doesn't make sense to me.
Did I miss something?
Thanks in advance.

indeed they are vague about this. My thought about this comes from conversing with Adobe folks here and elsewhere as I am pretty sure I'vce discussed this on the forum before. As far as I know the monitor warning is supposed to be calculated after the conversion to the printer profile so that you get an idea whether the soft proofed color is accurately displayed. That shoud be the correct behavior as proofing can actually take a color either in or out of the monitor gamut. I am not 100% sure on this though but it certainly explains how it behaves.
Also if you calibrate your display and write out a icc v4 display profile, the situation changes again as now the display profile can actually contain a perceptual rendering intent, making it even less precise and the assumption of simple one-to-one linear conversions between color spaces is invalid. Few calibration software packages do this though but there are a few exceptions.
If you only want to know whether your image is outside of the display profile, you can indeed trick the soft proof to allow you to select a display profile as the printer proofing profile. You can in principle select a standard working space such as prophotoRGB there and get results that make sense. But you definitely do not want to have a random printer profile selected for the reasons cited above. I guess they could add some smartness to detect that you selected the profile of the current display and not a profile of another random display and then collapse the interface but that is such an edge case that I doubt Adobe would prioritize this. It works fine if you simply realize that you selected your monitor profile as the printer proof profile.

Soft proofing - implementation suggestions

Reading this thread it seems the Lightroom team is seriously considering or actually implementing soft proofing for LR3.0. Since it's not in the current beta, the users cannot give feedback on the implementation. Instead, let's use this thread to give suggestions on how soft proofing should work.
Here are my suggestions:
availability: soft proofing should be available in all modules: you need it for print and web output, but the necessary corrections are made in the develop and library modules.
UI placement: the film strip seems to be a logical place for a tool that can be used from within all modules.
features: soft proofing would need an on/off toggle, a clipping indicator toggle and a list menu to select/create soft proofing profiles (with a choice of relative/perceptual; black point would be nice but doesn't fit the 'lightroom way').
monitor proofing: make it easy for users to select the profile corresponding to their monitor. That way they get a warning that their monitor may be 'cheating' them (especially on laptops).
further: the tool could show a warning if it is switched on with the 'wrong' profile for the active module. For example, for web you should only use sRGB, for print the same as selected for the printer and for the slideshow perhaps only the monitor profile.
Anyone else?
Simon

Jeff Schewe wrote:
I disagree for several reason: 1) the Develop module is the ONLY color accurate viewing environment, 2) Develop already has a before/after built in that can be adapted to the task of showing a before and an after with the after representing the output space. 3) the Develop module allows the creation and or selection of Develop templates as well as snapshots. Snapshots might make an excellent vehicle for carrying image adjustments.
I am not sure what you mean by the develop module being the only color accurate viewing environment. I just checked it by setting my monitor gamma to 1.0, and all modules applied the necessary adjustments to the images. The only difference I could find is that the other modules use heavily compressed JPGs, leading to the occasional artifact when viewing at 1:1.
I really believe that soft proofing itself is fundamentally an analysis tool that should be accessible from all modules, and not necessarily be linked to image adjustment tools. If someone wants to work on a set of images for a particular output process, he/she should be able to make all necessary changes with soft proofing turned on, and have the effects visible in all modules. Of course, in practice many users will want to target different output media for the same image, and such tools are important, but need not be a show-stopper for soft-proofing to appear.
On your number (2), I personally don't find before/after view essential, or even that useful, when making adjustments for printing. When you want to compress an image into the gamut of a printer, I tend to make small adjustments in the context of that particular image, not with a reference to some master image. The exception to this case would be if you really have something which you would call the 'master' (say, some really famous image), and you want the output to be as close as possible on more restricted printing process. In any case, I wouldn't consider a before/after view as essential. And when it's needed, it could be implemented by an on/off toggle as well, IMO.
I find snapshots quite cumbersome, and especially for the purpose of keeping track of such 'output versions'. The problem is that they exist inside the develop module, they are 'all or nothing', and there is no easy way to transfer partial settings between snapshots. For example, suppose I have three 'output versions' of an image, and I decide to change some of the underlying settings (say, the white balance). Then I don't have an easy way to synchronize these changes between the output versions. Another issue is that there is no easy way to recall snapshots from outside the develop module. If I want to print a couple of images for which I have the necessary adjustments at some other time, I have to go in and select the appropriate snapshot for each of them. In the context of these 'output versions', this is something that should be possible from the library module, where you select the versions you have worked on before.
Also note that while Develop might be the place for adjusting the image for the output, the creation of an output adjustment might be best called up in Print (or Export). So you might create a saved preset that contains the output device, the specific profile, the rendering intent and whatever output based adjustments the image (or images) may need. That could be done directly in the Print module...
The three main factors that soft proofed adjustments require is a change in the tone curve required by differences in dynamic range or outputs, hue and saturation adjustments to counter or alter the way a profile may render a certain (or several) colors and a local area contrast adjustment in the form of Clarity. Ideally, the soft proofing tools should contain a soft proofed histogram, color samples in the output space and tone/color adjustments suited for correcting for the output condition.
Ok, I can see a benefit to a separate output adjustment tool that is specifically aimed for the type of adjustments you'd make when soft-proofing. The settings for this tool could be linked to the output device and profile, so that they would switch automatically according to the profile that is selected. When soft-proofing is turned on in the library module, there could be an icon in the images for which a particular output transformation is defined. And because soft-proofing would be fully functional in the develop module, you could inspect which other images need further adjustments.
I don't think it's very useful to have a 'preset' for this tool for a particular output profile and rendering intent, independent of the image. That's the job of the profile itself. However, it should be possible to easily copy-paste such settings between images. For example, if I have shots a number of images in bright green grass, I will probably need similar adjustments for all of them. Also, settings should be copyable to serve as a starting point for use with a different profile.
The 'output adjustment tool' itself should IMO contain two things:
1) Photoshop-like hue/sat control (with selectable color ranges) [most important]
2) Manual tone curve adjustments.
I wouldn't mind if the tool is only accessible from within the develop module, as long as you can see the soft-proof from all modules. The soft-proofing functionality (separate from this tool) should also take care of adjusting the histogram in the library and develop modules.
Summarinzing, I see room for two separate tool sets that do not necessarily need to be implemented at the same time. The first is an overarching soft-proofing solution that makes the effects of the output transformation visible throughout the workflow. The second is a separate output adjustment tool in the develop module, that is able to link it's settings to the currently selected output device/profile.
Simon

Soft Proofing Alterations Happen on Original aswell as Virtual (Proof) Image

When soft proofing, I split the image horizontally and then create proof image when asked after making first alteration.
However, in both LR4.4 and 5Beta, both the original and virtual (i.e., proofing image) change.
Example. Have l Brightness value of 55 in original. Proofed image is duller. Increase brightness in proof by 10 to match original. (Figures are just for explanation) Now when I compare images again, original image brightnesss has increased by 10 also. This can be seen, of course, on the Develop panel.
Obviously, proofing won't now work properly, I think.
What is wrong here?

After you make a develop-change in <Softproof> you should get a dialog box that gives tyou three options:
<Undo> - <Make This a Proof> - <Create Proof Copy>.
Are you selecting <Create proof Copy>?
Only then a Virtual Copy is created that shows the altered state while the original remains without the alteration.
If you select <Make This a Proof> the original image will be changed.

Photoshop CC quits when setting up soft proof for Moab Slickrock paper

I use a Mac Pro with Mountain Lion and Photoshop CC, all with current updates. I had no problem downloading and using the Moab Slickrock icc profile from their website to make a test print. When I try to set up soft proofing, view-proof setup-custom, and choose Slickrock as the device to simulate, Photoshop quits suddenly. I tried it multiple times, restarted the computer, restarted Photoshop, removed and re-installed the profile all to no avail. I then installed the profile for Moab Lasal, and was able to set up soft proofing for Lasal with no problem. I can set up Slickrock with my copy of Photoshop CS6 with no problem and also with Lightroom 5.3 it will soft proof. I wrote to Moab and they said it was a known bug with no current solution.
Do you have any idea what is going on?
Soft proofing is not critical, but I do like to use it when I can.
Eric Brody

I am having this issue as well. I tried lightroom, but the soft proof is buggy there - it's a known bug I saw written up on MOAB's page. Supposedly Photoshop CS5 worked OK softproofing with this profile, but evidently, CC does not.

Weird behaviour when soft proofing.

Similar Messages

Maybe you are looking for