--- In DigitalBlackandWhiteThePrint@yahoogroups.com, Steve Kale <stevekale@= b...> wrote: > snip: > =What we've done lately for soft proofing is just simulating the "look" o= f a > print in RGB that > =you can see on a calibrated monitor. It has no knowledge, notion or > =whatever of how the ink got onto the paper. In a sense that's the beaut= y > =of it -- you can simulate the look of any method of printing. > > Ok I guess I am not fully understanding this. Your ICC profile maps the > image from Gray Gamma 2.2 into the gray space of the particular QTR setup= > and then visually displays the results of this mapping on the screen (whe= n > soft proofing). When doing the proofing (and forgive me if this is in th= e > stuff I have not had the chance to look at yet) which space are you in? > Still Gray Gamma 2.2? Or does the doc have to be converted to RGB? For SoftProofing you don't actually convert your file at all, but what is s= ent to the display does go through profile conversion. So the file should be in Gray Gamma 2.2 the entire time. Ordinarily each gray pixel is converted to RGB where R=G=B=gray, and sent to the display where some profile is applied so you actually get a gray output i.e. gray input =>> gray outpu= t. When proofing an ICC profile is inserted in the middle that will alter the RGB values so you see the correct colors. > > In order to create this ICC profile you have determined how a known set o= f > inputs get rendered by the particular QTR setup. (The full gray spectrum= is > presumably derived from an interpolation of these measured points.) The > soft proofing feature of PS uses this mapping and an understanding of the= > profiled monitor¹s display characteristics to visually represent the fina= l > output. I think it's worth an example here. Say, without a profile your printer pr= ints too warm. You create a printer profile that basically says "add more blue"= . I.e. it take file RGB values and ups the blue component. Now take that profile and use it for proofing. You already have a calibrat= ed monitor so gray shows as gray. When you proof with that printer profile, the profile is inserted in the middle and reversed. So "add blue" becomes "subtract blue" and what you see on the screen is a warm image -- the same that came out of the printer. > > =ICC printing is a whole different thing. An ICC profile can't do an > arbitrary > =mapping to N inks because the output has to feed into an RGB Epson drive= r. > > In my layman¹s view of QTR and I am stating this so that you can correc= t > this if I am way off base is that it does two things. Firstly it takes= > control of the individual print heads and defines how they are used to dr= ive > a gray scale spectrum (rather than using the Epson formula for determinin= g a > gray scale). BTW, can you help me understand linearization a bit better?= > Specifically I think I understand what¹s going on with the ink limits and= > you have indicated that there is a mathematical function that then smooth= es > these choices. What is it that linearization adds over and above this > mathematical smoothing? What I mean by smooth is just that all the values are reasonably continuous= , no big jumps and also that there are no down turns. Linearization starts with the smooth gradient and puts the gray values in the correct spot. So 50%K in the file makes 50% gray on the output. It works on the 21 step values. Its just a tonal correction curve -- in PS if your image is too da= rk you go into Levels or Curves and make a correction curve. Same thing. > > Secondly it takes each pixel value coming in and determines where on the = ink > curve it sits, ie how pixel x should be rendered. Presumably this is a v= ery > straightforward mapping. The problem has been that there is no consisten= cy > between how a screen renders the individual gray pixel values and how QTR= > renders them. Isn¹t this the conventional colour matching problem? (Alb= eit > in a simpler space.) The more I think about this I find myself thinking = in > circles. I guess if I can soft proof why fuss with the backend. But then= I > can¹t see how this differs from the conventional colour problem which > requires a profile to soft proof and the use of the same profile for > conversion at print. Why don¹t we tag the file going to print with this > mapping function, either letting PS or QTR do the mapping, a la the two > different methods for colour printing? You do have a bunch of circles here. I think the break in the circle is th= at the ICC profile that can tell you how to display sepia on a screen has no information whatsoever about how to print sepia on a printer with arbitrary inks. > > The reason why I am asking about linearization is because this is the poi= nt > where we first measure a step wedge. Adopting this new soft proofing we = do > so twice. Once for linearization and then secondly for a soft proof > profile. In the colour analogy (and I think of B&W as simply a very very= > narrow colour space) I would do so once only and this would then be used = for > both soft proofing and to define how colour or shade of gray x is mapped = for > the printer so that WYSIWYG. Before linearization you measure the wedge in order to create a linearizati= on curve -- this is like making a ICC profile that you will print with. The second measuring takes place after linearization has been done, you now want to measure and proof how the B&W printing really works. > > I don¹t see the Epson or any other driver that differently. Somehow it h= as > a formula for driving the print heads to produce ³colour² x. But pixel > value x may correspond to a different shade of gray by the printer than w= hat > is displayed on screen and so we use an ICC profile to shift these so tha= t x > on screen is the same as x on paper. This mapping can either be done by = the > driver or by PS before getting to the driver. It still boils down to the issue that ICC profiles and Epson drivers look a= t the world as colors represented in RGB. With RGB more B means more blue, etc, etc. How can that come to grips with a sepia colored ink in some slot? > > So, I guess I am wondering if an ICC profile constructed as you have done= > can be used to simplify the front end curve design process by using it to= > first map things to the display space for soft proofing and then mapping > things into the QTR space....perhaps an unlinearized one. > > Sorry for the ramble but just trying to understand this better..... > > Steve It's not intuitive, I'm still trying to understand a lot of it. For me its= an iterative process of seeing what works, figuring out how its possible, and deducing how it works. Roy
Message
Re: [Digital BW] New icc based Soft-proof profiles for QTR
2004-01-15 by Roy Harrington
Attachments
- No local attachments were found for this message.