Prev: Photoshop CS2 error: No more virtual tiles can be allocated
Next: how to create mythbuster type of letters
From: Jim on 19 Jun 2005 11:22 <yesnno(a)att.net> wrote in message news:42B5667F.A39D79DF(a)att.net... > > > Is choosing a video card important for color management and using ICC > profiles? For example, using the same profile, will the displays look > the same on the same monitor for different (but comparable quality) > video cards? Not necessarily or even usually. The profile is specific to that particular monitor and that particular card. The CRT monitors wear out hence even if the factory profile is "close enough" when you first install the monitor, it isn't "close enough" after some time has passed. Jim
From: Bill Hilton on 19 Jun 2005 13:40 >The OS and the video card must play some role in using a monitor's >ICC profiles. What are they? The OS has to support ICC profiles and the ICC workflow or it can't happen ... earlier versions of Windows didn't offer ICC support for example, which was a real plus for Apple in the digital market. I *think* Windows 95 offered ICM 1.0 support and maybe with 98 they came out with ICM 2.0 support, which was not too far behind what Apple is doing. In typical Windows fashion they declared this 'good enough' and haven't improved it much if any since. I remember that an OS like NT didn't support this because you couldn't write to the video card (or something like that), for example. In Photoshop you can choose to use either the Adobe(ACE) conversion engine or the Windows ICM option, which you can access in the Color Settings (advanced - Conversion options) window. As for the video card, you would have to use a very old or very cheap one with few programmable registers to miss out on the ICC stuff. Any decent newer card should be fine. >Is choosing a video card important for color management and using >ICC profiles? I don't think so (I'm no expert on video cards though), so long as it's fairly recent. >using the same profile, will the displays look the same on the same monitor >for different (but comparable quality) video cards? You wouldn't use the same profile for different video cards but if you generate one specific for that card then I'd expect the monitor to look the same. A good source of info on color management is "Real World Color Management" by Fraser, Murphy and Bunting. Bill
From: Paul N on 19 Jun 2005 13:50 "Jim" <j.n(a)nospam.com> wrote in message news:W4gte.26$Lj2.5(a)newssvr12.news.prodigy.com... > > <yesnno(a)att.net> wrote in message news:42B5667F.A39D79DF(a)att.net... >> >> >> Is choosing a video card important for color management and using ICC >> profiles? For example, using the same profile, will the displays look >> the same on the same monitor for different (but comparable quality) >> video cards? > Not necessarily or even usually. The profile is specific to that > particular > monitor and that particular card. The CRT monitors wear out hence even if > the factory profile is "close enough" when you first install the monitor, > it > isn't "close enough" after some time has passed. > Jim > I was asking myself the same questions as yesnno and I'm still puzzled about the answers. The video card clearly plays a role, since the role of the the LUT downloader (Adobe Gamma loader, ColorVision startup) is precisely to set up the video card to perform *some* corrections. But: I suspect that you can swap video cards (not monitors!) without seeing any difference: these LUT downloaders seem to work with all but very old cards. So there must be a standard API in Windows that these programs can speak to, regardless of the video card model. As far as I know, Windows itself plays no active role in color mgmt, it just allows you to specify a default profile. This profile is then used by the LUT downloader, and apparently by color managing apps too (see next paragraph). From my experiments with ICM files created using the Spyder cal tool it appears that the monitor ICM file is used by: - the LUT downloader. Proof: use a tool such as Colorvision ProfileChooser, change profile and see the *whole screen* change color. - Photoshop & other color managing apps. Proof: Just bring up the same sRGB file in both a managing and nonmanaging app and you see that the color managed app shows different colors (although not by much). I's not clear to me where to draw the line between calibration and characterization, it looks somewhat arbitrary. It's also not clear if Adobe Gamma loader and other LUT loaders 'misuse' the ICM file to store their proprietary tables, in other words: is this LUT info fundamentally part of the profile or is it just used by LUT loaders because it's a convenient place? Is the ICM file more than a profile? It would be interesting to know what the minimum spec is that all video cards are supposed to implement (regarding color mgmt). It looks like it's just 3 tables (one for r/g/b) with 256 entries that convert an incoming intensity value to a 'corrected' value that is sent to the monitor. But: 3 one-dimensional tables are not enough to allow mapping any RGB triple to another triple. To solve this correctly you need a big 3-dimensional table (256^3 or millions of entries). Yet an ICC file is small. Interpolation? Many questions and no clear image of how all these pieces of the puzzle fit together......... ___________________________________________________________
From: Bill Hilton on 19 Jun 2005 14:11 >Paul N writes ... > >I's not clear to me where to draw the line between calibration >and characterization, it looks somewhat arbitrary. No, it's not arbitrary. When you run the Spyder software you first adjust the brightness and contrast controls to get the right black point and luminance, then you adjust the separate RGB guns to get the right custom white point. At this stage the monitor is "calibrated", meaning it is in a known good state and will remain there so long as these controls aren't changed (or until the monitor drifts, which could be as soon as two weeks). In this context "characterization" means the software displays colors of known values on the screen and the puck measures them to see if there are differences between what the color *should* look like (per the numbers) vs what the colors actually look like as recorded by the puck. Once all these colors are measured the software takes all the differences into account and creates the ICC monitor profile, which tries to translate the color RGB values on the fly so what you see on screen (taking into account the unique properties of your monitor) look as close as possible to what is represented by the RGB triplets. >Any web pointer or other reference greatly appreciated! This is a good intro to what's going on with the 'translations' (but not to the LUT level) ... http://www.creativepro.com/story/feature/13605.html ... the same guy is co-author of "Real World Color Management", which is highly recommended. For background on the ICC flow the main site is www.color.org which is the official site of the ICC (International Color Consortium), but it's hard to read. >Many questions and no clear image of how all these pieces of the puzzle >fit together. I wouldn't worry too much about what's going on at the register level of the video card ... what's important is understanding that color managed apps 'translate' colors between different devices. After a while you find that there are a lot of inaccurate ICC profiles out there (especially printer profiles) and what's important is generating or finding good, accurate profiles and knowing when you have a bad one. Bill
From: Paul N on 19 Jun 2005 15:31
"Bill Hilton" <bhilton665(a)aol.com> wrote in message news:1119204665.299838.166190(a)g43g2000cwa.googlegroups.com... [...] > I wouldn't worry too much about what's going on at the register level > of the video card ... what's important is understanding that color > managed apps 'translate' colors between different devices. After a > while you find that there are a lot of inaccurate ICC profiles out > there (especially printer profiles) and what's important is generating > or finding good, accurate profiles and knowing when you have a bad one. Actually the 'register level' is not my concern. What *does* concern me is that -apparently- part of the color correction for display is done in hardware and part in software. Which means that non color managed apps show 'partly corrected' images. A good thing in itself. But what part?? 90%? 50%? Unpredictable? Note: let's suppose the images are sRGB; using large color spaces with non color managed apps is hopeless. You may argue that one shouldn't use non color managed apps in a color managed workflow. But for many amateur photographers like me, there are lots of useful apps out there that are not color managed. So we have to live with 'partially corrected' color; knowing what 'partially' means would IMHO be a big help. I admit, in an ideal world where all apps would be color managed, I woudn't care how it's done. But unfortunately this ideal seems a long way off... |