Yahoo Groups archive

QTR-Quadtone RIP

Index last updated: 2026-04-28 23:12 UTC

Message

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-09 by Le Mois de la Photo à Uqbar

Richard

 

I’m not going to labour this.  I afraid that I began this post with a small question but spent far too much time trying to explain the context within which I was asking the question.  

 

There is obviously a disconnect between the QTR environment, at least those who are responding to this thread, and the standard colour management work flow. This colour managed workflow is not my invention it is the Universal production standard (UPDIG) for colour ink printing.  The goal of colour management is not to match CIE lab, which as a derivative model of the original Standard Observer is a graphic representation of the human perception of light.  As you wrote, nothing material could. The coordinates of the (L*a*b*) define colour unambiguously. The goal of colour management is to translate colour from one space to another, like a dictionary translates words from one language to another. 

 

I guess what I am trying to accomplish, in fact what I do accomplish, is to apply the colour management workflow to B&W printing. This is only possible because of the QTR ICC profile. 

 

If you are working in digital imagery and you are making prints there are only two options “same as source” or “colour managed”. Outside of colour management all files are untagged even if you think you are in a greyscale space. In a “same as source” workflow the file data is not converted, so you are sending untagged digital data (file data that will eventually become electronic control signals that communicate directly to the print heads) and through trial and error matching data to ink densities.  If you are in a colour managed workflow you are using a chain of look up tables (that serve as dictionaries) through a series of colour space conversions that translate the colour associated to the source file data to its respective place in the destination file data. Discrepancies in colour spaces are either dealt with systemically (perceptual rendering or Adobe BPC) or manually through targeting curves for out of gamut values or colours.  

 

I’ve already sent a “sign off” or conclusion of sorts to this post, apparently the message has not arrived yet, if it does not please accept this message as a final conclusion to this thread. 

 

I’m sorry to have stirred the waters and perhaps muddied them for some. 

 

Eugene

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : August-09-16 10:33 AM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC

 

  

I've been busy the last week and have just been watching this from afar and somewhat puzzled.

 

Eugene, after these 40 some-odd posts I am still not sure what you are trying to get at here, but I think there is misunderstanding of some of the fundamental principles of custom QTR Curves (or media settings).  The whole point is to see what the deepest Dmax you can have with a printer/ink/paper combination and then map your 100%K in the image to that print density and then have perfectly even spaces between each of L\* measurements for however many steps you want to measure. There are all sorts of arguments that can be made for how to best alter that linear density distribution to better match what you see on the display or match your working space or some combination of the two, but the first step is always getting the printer to behave in a predictable and measurable way. 

 

Here is the point that I really wanted to make though: I think you are confusing trying to get a print to match the CIELAB color space and the printer’s linear L*a*b* L* measurements for a set of custom QTR curves (media settings). I might not have this exactly right, but CIELAB is more of a theoretical space that is an approximation of human visual scale and we just use it to measure print values against. There isn’t anything that can actually match it. Furthermore, actually trying to match it can actually lead to other problems.

 

Printing on Glossy papers, where you can reach a L*a*b* L* of 2-3 results in something that almost parallels the CIELAB space with little loss on the high and low end, but does result in something that *appears* slightly darker in the midtones and slightly lighter in the shadows than you would expect to see on the display (based on printing with no CM). One thing I have found helpful is to*apply* the QTR RGBLAB profile to the image (not converting) and then edit the image so that it looks correct through the midtones and shadows. That is really only helpful for glossy prints because it is fairly close to CIELAB and needs minor tweaking. BUT, I generally don’t like to have a Dmax that high because it can cause problems in other ways, like showing inkjet prints and gelatin silver prints in the same show, or just not being able to see the details in the deepest shadows (even if they are in the image file, like between 95%-98%K).

 

Matte papers are more problematic because of the much lower Dmax when compared to glossy prints. If you were to try to parallel CIELAB as long as possible before reaching the Dmax and leveling off, you would get a print that appears MUCH too dark through get midtones. I’ve done a lot of testing to see what gives the best appearing matte prints without losing detail in the shadows while still not being as open as what you would get with a Linear L* and a Dmax of 15-17, and I’ve come up with something that works for me personally, and I modify it for each paper I work with. 

 

Which gets me to the final point. What is with this overall concern for matching CIELAB, GG2.2? The print is never going to match it perfectly, and the screen is in no way going to give you exactly what you will see in the print. Why not just get the printer to behave predictably (like you can with custom QTR curves) and then PRINT. You will learn exactly what each tone in the image will look like with that printer/ink/paper and will be able to edit the image accordingly. There used to be a thing people did in the darkroom that tends to get lost with some of this digital stuff. They would get to know and master the materials and then make intuitively adjustments based on experience.

 

 

Richard Boutwell

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.