If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Monitor calibration and color managed workflow question
On Mon, 19 Dec 2005 05:12:12 -0500, "Ed Ruf (REPLY to E-MAIL IN
SIG!)" wrote: On Mon, 19 Dec 2005 10:04:53 +0100, in rec.photo.digital Stanislav Meduna wrote: .... The Spyder generates an ICC profile, puts it somewhere into windows directory and registers it with the graphics card. On startup the ProfileChooser takes the default profile and loads it into graphics card. That means that I am able to see accurate colors with applications that are not color managed - web browser, ... I thought this was the case as well, but was corrected by Bill Hilton. The colors on non-managed apps will be better, but not as good as in a color managed app. Just checking... What part of the original post needs to be "corrected"? I think it is true that a spyder app, or Adobe Gamma, or a third-party monitor adjustment app, will make a profile and register it with the OS. And that Adobe Gamma Loader, or a third-party equivalent, will set graphics card registers at startup so that the "profiled" monitor shows an sRGB image from any application (or the OS itself) correctly without any intentional color management. ("Correctly" being to the limits of whatever process created the profile in the first place, of course.) Does a color-managed app fed an sRGB image add any accuracy to this process? It can't be changing the graphics card registers, or you would see all the other open windows change color when it took control. So the color-managed app must be sending unmodified sRGB to the graphics card, just like a browser would. Granted, if fed an image in any other color space, the color-managed app will provide more accurate rendering by intelligently converting it to the monitor space. Is there any other advantage? Loren |
#12
|
|||
|
|||
Monitor calibration and color managed workflow question
|
#13
|
|||
|
|||
Monitor calibration and color managed workflow question
Stanislav Meduna
The Spyder generates an ICC profile ... (this) means that I am able to see accurate colors with applications that are not color managed - web browser, ... Ed Ruf wrote I thought this was the case as well, but was corrected by Bill Hilton. The colors on non-managed apps will be better, but not as good as in a color managed app. Loren wrote ... Just checking... What part of the original post needs to be "corrected"? The part about "I am able to see accurate colors with applications that are not color managed". These apps don't 'convert' the RGB numbers to get the most accurate colors using the icc profile, while the ICC apps that recognize monitor profiles do. Does a color-managed app fed an sRGB image add any accuracy to this process? Yes ... as Graeme wrote, all apps benefit from the 'calibration' stage where you define the gamma and set a white and black point, but then the profiling software displays color patches on the screen and the puck measures them and creates a matrix file that enables programs that recognize monitor profiles to display colors more accurately. As a theoretical example, most CRT monitors are built such that full or near full values of the RGB guns give a 9300 K white point but typically we use 5000 K or 6500 K and to get these warmer colors the blue and to a lesser extent the green guns are reduced ... to make something up that I once saw on an older monitor, say 98% R, 80% G, 65% B to get 5000 K ... this is for the white point, but now it's harder to get a linear gray, meaning equal RGB values of say 64/64/64 or 150/150/150 are neutral by definition in a 'working space' like sRGB, but are harder to hit the more uneven the RGB gun values are (like in the example I gave). So there's often a slight color cast in the neutrals in non-color managed apps, while this is corrected for in apps that recognize the profile. You can turn recognition of the monitor profile on/off in Photoshop with a keystroke and if I look at a pattern like this one ... members.aol.com/bhilton665/colors.jpg ... and disable/enable the monitor profile what I see on my monitor is that most of the squares look the same but the saturated colors across the top shift noticeably in the reds, yellows and oranges. I came across this when web photos from Arizona and Utah's Red Rock country looked different than even sRGB images in Photoshop as the reds dulled down. Images that weren't first converted to sRGB looked much duller, but you still see a 2nd level effect just from the lack of monitor profile recognition. Bill |
#14
|
|||
|
|||
Monitor calibration and color managed workflow question
Loren writes ...
Granted, if fed an image in any other color space (other than sRGB), the color-managed app will provide more accurate rendering by intelligently converting it to the monitor space. Graeme writes ... sRGB is just another colour space, in the same way as AdobeRGB or ProPhoto RGB. There is nothing special about it, and the same arguments apply for all working spaces. Actually if you view an sRGB file without the profile (like in a web browser) there's not much change, but if you view the same file with a much wider color space in a non-color managed app then the colors can look REALLY bad ... at least I think that's what Loren is getting at. Here's an example of a red bird, converted to ProPhoto from the RAW (this is a very wide space, much wider than AdobeRGB) ... this shows what the file looks like if I convert to sRGB and then make an untagged jpeg ... http://members.aol.com/bhilton665/card_srgb.jpg ... and here's what it looks like if I just take the ProPhoto tagged file and convert to jpeg without dumbing it down to sRGB first ... all the saturated colors get dropped and it looks really really bad ... http://members.aol.com/bhilton665/card_prophoto.jpg Granted ProPhoto is a really extreme working space but even with AdobeRGB you'll see a lot of saturated colors fall out. I think that's what Loren was getting at. Bill |
#15
|
|||
|
|||
Monitor calibration and color managed workflow question
Graeme Cogger wrote:
Creating a monitor profile has 2 parts: 1 - Calibration: the display is adjusted (via settings in the graphics card and maybe the monitor controls) to get things like colour temperature, gamma etc. correct. All applications see the effect of the calibration - this is what gets loaded to the graphics card when the system starts up. 2 - Profiling: the response of the calibrated display is accurately measured to create a profile of how it displays colour. This profile is used by profile-aware applications to adjust the colours sent to the graphics card and monitor. Without these adjustments, the colour displayed will not be accurate. Thanks! - that finally makes sense. So the .icc file generated by the Spyder has actually two parts: - LUT data tht gets loaded to the card via ProfileChooser - profile that is used by the PS (and QImage and that's probably all on my system) Is the LUT part also standardized somehow? I am asking because the ProfileChooser refuses to use a profile that it did not create itself - maybe because it is in some proprietary format embedded in the vendor-specific part of the ICC? Thanks to all that responded. Regards -- Stano |
#16
|
|||
|
|||
Monitor calibration and color managed workflow question
On 19 Dec 2005 15:28:18 -0800, "Bill Hilton"
wrote: Stanislav Meduna The Spyder generates an ICC profile ... (this) means that I am able to see accurate colors with applications that are not color managed - web browser, ... Ed Ruf wrote I thought this was the case as well, but was corrected by Bill Hilton. The colors on non-managed apps will be better, but not as good as in a color managed app. Loren wrote ... Just checking... What part of the original post needs to be "corrected"? The part about "I am able to see accurate colors with applications that are not color managed". These apps don't 'convert' the RGB numbers to get the most accurate colors using the icc profile, while the ICC apps that recognize monitor profiles do. Does a color-managed app fed an sRGB image add any accuracy to this process? Yes ... as Graeme wrote, all apps benefit from the 'calibration' stage where you define the gamma and set a white and black point, but then the profiling software displays color patches on the screen and the puck measures them and creates a matrix file that enables programs that recognize monitor profiles to display colors more accurately. To further check my understanding (or confusion) here... Am I correct that this "matrix file" is what gets loaded to the lookup table registers on the graphics card? Or is it a separate color translation containing subtle differences between what was achieved by customizing the graphics card lookup table and what the spyder saw? Maybe I'm behind the state of the art here, but as I understand it, the graphics card lookup table translates between the three 8-bit values sent by the application for each pixel, and the three 8-bit values that get sent on to the monitor to show that pixel "correctly". If all you have to work with is eight bits, and the graphics card lookup table has already been set up optimally, what can a color managed app add to that for an image that is already in the native color space? My thinking here is largely based on my experience with an older notebook where the backlight has gone seriously "warm", to the point where color errors are obvious. I wasn't able to fix this with Adobe Gamma, for images inside or outside PS, and concluded Adobe Gamma had somehow stopped working. I found WiziWYG and it let me tweak the colors back to some semblance of decency. You can clearly see it load the graphics registers when its loader runs at startup, and the effect seems to be the same both inside and outside of PS (though on a notebook screen maybe the subtleties just aren't visible). Of course a spyder could do a much better job than I did, and optimize many more points along each color's correction curve. But wouldn't it load its conclusions into the graphics registers just like my manual curves get loaded? And since there are only eight bits per color to play with, how could a color managed app improve on that? (Unless the original image needs to be converted to the native color space, of course.) I still don't understand what happened to Adobe Gamma, though. It didn't appear to be able to do anything to help my problem, color managed app or not. I even tried reloading fresh versions from the CD and from the web. Does it function differently from WiziWYG? Loren |
#17
|
|||
|
|||
Monitor calibration and color managed workflow question
|
#18
|
|||
|
|||
Monitor calibration and color managed workflow question
|
#19
|
|||
|
|||
Monitor calibration and color managed workflow question
Loren wrote ...
Am I correct that this "matrix file" is what gets loaded to the lookup table registers on the graphics card? Graeme answered that well ... My thinking here is largely based on my experience with an older notebook where the backlight has gone seriously "warm", to the point where color errors are obvious. I wasn't able to fix this with Adobe Gamma ... I still don't understand what happened to Adobe Gamma, though. It didn't appear to be able to do anything to help my problem, color managed app or not. Adobe Gamma does a very poor job with LCDs and laptops ... I thought this was mentioned in the documentation. Even the original Spyder does poorly with laptops ... if you're trying to do color-critical work on a laptop you need to spend $200 or so and get the Eye-One or the Sypder 2 or the Monaco (Optix?) ... Bill |
#20
|
|||
|
|||
Monitor calibration and color managed workflow question
On Tue, 20 Dec 2005 22:21:25 -0000, Graeme Cogger
wrote: .... No, it's separate. The graphics card loads 3 basic curves - one each for R, G, B. There are 2 main reasons why this is not enough: - The graphics card knows nothing about the colour space of the original file, and therefore cannot compensate accordingly. For example, an RGB value of (200,50,20) in the AdobeRGB space is a different colour to (200,50,20) in sRGB. If you feed (200,50,20) to the graphics card, it won't know what colour it needs to display. I think that part was coming clear earlier in this thread. - The graphics card Look-Up Table (LUT) has independent curves for R, G and B. Say you have a monitor that displays greys perfectly, but makes bright purple, e.g. (200,10,200), appear somewhat blue. The purple problem can be cured if an R value of 200 is translated to 210 and a B value of 200 is translated to 190. However, this now means that a pure grey (200,200,200) will be displayed as (210,200,190) and appear a little orange. Instead of independent RGB curves, a monitor profile uses a 3D table and can correct for these issues. Thank you! The 3D profile table as opposed to a 2D graphics card table is the part I was missing. I'd never noticed that difference in the color management descriptions I'd read. I suppose I will notice it everywhere now... Loren |
Thread Tools | |
Display Modes | |
|
|