QTR-Quadtone RIP

Roy (and other interested parties),

You may recall my discussion about whether or not it was wise to convert to the QTR-CreateICC generated profiles using perceptual intent or not before printing, and I speculated that this could be a source of "double profiling" that would compromise the DMAX of the print. I posted this graph comparing 3 different methods of printing (using graylab, using ICC with perceptual, and using ICC with rel- col). It shows the behavior that led me to believe using the profile with perceptual intent might not be such a good idea:

http://www.pbase.com/jkohn/image/65715318

Well I decided to do some further testing since you didn't think the results I was getting were correct/expected. This time I decided to take QImage out of the loop by doing any profile conversions directly in Photoshop. The results were very different this time:

http://www.pbase.com/jkohn/image/65974462

As you can see, using the profile with perceptual intent now yields the most accurate results. I did a little more digging and it sure seems to me that the ICC handling in QImage is broken, at least as it relates to printing to file with grayscale images. I found that you can take the 21x4 random test file, print it to file in QImage with Printer ICC disabled, and the gray steps in the resulting file will have changed from what they should be. Likewise, enabling Printer ICC and printing to file using one of the QTR profiles (either gray-lab or curve-specific) will yield completely different results from doing the conversion in Photoshop.

I haven't determined exactly what's going on here and whether it just affects printing to file, or just happens with grayscale files. But right now, I do not recommend QTR users to use QImage for layout/interpolation if you care about getting accurate tonality in your prints.

As the second chart above shows, the ICC profile with perceptual intent seemed to yield the most accurate results when printing a grayscale step chart. But when I repeated the test using a real world image, I found that the deep shadows were too murky and didn't have the detail in them that I wanted. Conversely, printing directly from gray-lab gave better shadow separation, but also lightens the midtones too much. So I did one final test using gray- lab instead of the profile, but boosting the gamma setting in QTR to +4 in order to darken the midtones some. This proved to be "just right", as the real-world image now showed excellent shadow detail and the midtone values were closer to where they should be:

http://www.pbase.com/image/66139883

So in the case of my HPR curves for the 2400, it looks like I'm going to be printing directly from gray-lab using gamma=+4, unless the image has no shadows to be concerned with (which is rare for me). The resulting prints look amazing, it was definitely worth all the work (I can't tell you how many step charts I've printed in the last few weeks). My HPR curves are finished, I'll try to write up some notes on their usage and post to the group tomorrow. The I guess I'll have to start testing with QImage's ICC handling is also broken for printing color directly to the print...

jkohn_home wrote:

> I haven't determined exactly what's going on here and whether it just
> affects printing to file, or just happens with grayscale files.  But
> right now, I do not recommend QTR users to use QImage for
> layout/interpolation if you care about getting accurate tonality in your
> prints.

So not much has changed in 20 months then. I have not used 
Qimage's CM for QTR's B&W since I discovered the same 
problems. Could be the BPC in Qimage's CM though that gives 
the problems. BTW, I do not have any problems with color CM 
using Qimage, behaves almost exactly like Photoshop.

You will find several messages in the 
DigitalBlackandWhiteThePrint@yahoogroups.com list (first 
months of 2005 mainly) that were the start for the ICC 
linearising and profiling for QTR (+Qimage) and the way it was 
created at that time + some tests how it performed. Both the 
QTR profiling and Qimage's CM have changed since but I still 
use the PS P2P conversion to the QTR printer profile and 
Qimage-CM-off method like you suggest here.

BTW using QTR's profiles in Picture Window Pro is even worse.

Ernst

-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

Hi Jeff,

Nice analysis.  It looks like you have covered a lot of bases.
I must confess I'm not a regular Qimage user -- I use PS on a Mac for all my work.
But a little over a year ago I did coordinate with QImage and this looks surprising
like some of the issues then.  Any chance you are using a relatively old version of
Qimage?   The issue at the time was that Black Point Compensation was working
differently in Qimage than Photoshop.   Internally to Qimage is a color management
called LittleCMS which is actually doing these conversions.

Anyway I wonder if you have an old version or the issue has re-cropped up.

Roy

--- In QuadtoneRIP@yahoogroups.com, "jkohn_home" <jkohn@...> wrote:

>
> 
> Roy (and other interested parties),
> 
> You may recall my discussion about whether or not it was wise to 
> convert to the QTR-CreateICC generated profiles using perceptual  intent
> or not before printing, and I speculated that this could be a  source of
> "double profiling" that would compromise the DMAX of the  print. I
> posted this graph comparing 3 different methods of printing  (using
> graylab, using ICC with perceptual, and using ICC with rel- col). It
> shows the behavior that led me to believe using the profile  with
> perceptual intent might not be such a good idea:
> 
> http://www.pbase.com/jkohn/image/65715318
> <http://www.pbase.com/jkohn/image/65715318>
> 
> Well I decided to do some further testing since you didn't think the 
> results I was getting were correct/expected. This time I decided to 
> take QImage out of the loop by doing any profile conversions directly in
> Photoshop. The results were very different this time:
> 
> http://www.pbase.com/jkohn/image/65974462
> <http://www.pbase.com/jkohn/image/65974462>
> 
> As you can see, using the profile with perceptual intent now yields  the
> most accurate results. I did a little more digging and it sure seems  to
> me that the ICC handling in QImage is broken, at least as it  relates to
> printing to file with grayscale images. I found that you  can take the
> 21x4 random test file, print it to file in QImage with  Printer ICC
> disabled, and the gray steps in the resulting file will  have changed
> from what they should be. Likewise, enabling Printer ICC  and printing
> to file using one of the QTR profiles (either gray-lab  or
> curve-specific) will yield completely different results from doing  the
> conversion in Photoshop.
> 
> I haven't determined exactly what's going on here and whether it just
> affects printing to file, or just happens with grayscale files.  But
> right now, I do not recommend QTR users to use QImage for
> layout/interpolation if you care about getting accurate tonality in your
> prints.
> 
> As the second chart above shows, the ICC profile with perceptual  intent
> seemed to yield the most accurate results when printing a  grayscale
> step chart. But when I repeated the test using a real world  image, I
> found that the deep shadows were too murky and didn't have  the detail
> in them that I wanted. Conversely, printing directly from gray-lab gave
> better shadow separation, but also lightens the midtones too much. So I
> did one final test using gray- lab instead of the profile, but boosting
> the gamma setting in QTR to +4 in order to  darken the midtones some.
> This proved to  be "just right", as the real-world image now showed
> excellent shadow  detail and the midtone values were closer to where
> they should be:
> 
> http://www.pbase.com/image/66139883
> <http://www.pbase.com/image/66139883>
> 
> So in the case of my HPR curves for the 2400, it looks like I'm going 
> to be printing directly from gray-lab using gamma=+4, unless the image
> has no shadows to be concerned with (which is rare for me). The
> resulting  prints look amazing, it was definitely worth all the work (I
> can't  tell you how many step charts I've printed in the last few
> weeks). My  HPR curves are finished, I'll try to write up some notes on
> their  usage and post to the group tomorrow.  The I guess I'll have to
> start testing with QImage's ICC handling is also broken for printing
> color directly to the print...
>

I'm running the latest version of QImage, 2007.208. What I don't get is that
even with Printer ICC disabled (in which case no profile conversion at all
should be taking place), there was still a change to the L* values in the
step chart image. It makes me wonder if when printing to file (instead of to
a printer) there's some intermediate profile conversion taking place that
shouldn't be (maybe to sRGB?).
 
Jeff


  _____  

From: QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] On
Behalf Of Roy Harrington
Sent: Saturday, September 02, 2006 7:48 PM
To: QuadtoneRIP@yahoogroups.com
Subject: [QuadtoneRIP] Re: QImage, ICC Profiles, and some surprising results
(long)



Hi Jeff,

Nice analysis. It looks like you have covered a lot of bases.
I must confess I'm not a regular Qimage user -- I use PS on a Mac for all my
work.
But a little over a year ago I did coordinate with QImage and this looks
surprising
like some of the issues then. Any chance you are using a relatively old
version of
Qimage? The issue at the time was that Black Point Compensation was working
differently in Qimage than Photoshop. Internally to Qimage is a color
management
called LittleCMS which is actually doing these conversions.

Anyway I wonder if you have an old version or the issue has re-cropped up.

Roy

--- In QuadtoneRIP@ <mailto:QuadtoneRIP%40yahoogroups.com> yahoogroups.com,
"jkohn_home" <jkohn@...> wrote:
>
> 
> Roy (and other interested parties),
> 
> You may recall my discussion about whether or not it was wise to 
> convert to the QTR-CreateICC generated profiles using perceptual intent
> or not before printing, and I speculated that this could be a source of
> "double profiling" that would compromise the DMAX of the print. I
> posted this graph comparing 3 different methods of printing (using
> graylab, using ICC with perceptual, and using ICC with rel- col). It
> shows the behavior that led me to believe using the profile with
> perceptual intent might not be such a good idea:
> 
> http://www.pbase. <http://www.pbase.com/jkohn/image/65715318>
com/jkohn/image/65715318
> <http://www.pbase. <http://www.pbase.com/jkohn/image/65715318>
com/jkohn/image/65715318>
> 
> Well I decided to do some further testing since you didn't think the 
> results I was getting were correct/expected. This time I decided to 
> take QImage out of the loop by doing any profile conversions directly in
> Photoshop. The results were very different this time:
> 
> http://www.pbase. <http://www.pbase.com/jkohn/image/65974462>
com/jkohn/image/65974462
> <http://www.pbase. <http://www.pbase.com/jkohn/image/65974462>
com/jkohn/image/65974462>
> 
> As you can see, using the profile with perceptual intent now yields the
> most accurate results. I did a little more digging and it sure seems to
> me that the ICC handling in QImage is broken, at least as it relates to
> printing to file with grayscale images. I found that you can take the
> 21x4 random test file, print it to file in QImage with Printer ICC
> disabled, and the gray steps in the resulting file will have changed
> from what they should be. Likewise, enabling Printer ICC and printing
> to file using one of the QTR profiles (either gray-lab or
> curve-specific) will yield completely different results from doing the
> conversion in Photoshop.
> 
> I haven't determined exactly what's going on here and whether it just
> affects printing to file, or just happens with grayscale files. But
> right now, I do not recommend QTR users to use QImage for
> layout/interpolation if you care about getting accurate tonality in your
> prints.
> 
> As the second chart above shows, the ICC profile with perceptual intent
> seemed to yield the most accurate results when printing a grayscale
> step chart. But when I repeated the test using a real world image, I
> found that the deep shadows were too murky and didn't have the detail
> in them that I wanted. Conversely, printing directly from gray-lab gave
> better shadow separation, but also lightens the midtones too much. So I
> did one final test using gray- lab instead of the profile, but boosting
> the gamma setting in QTR to +4 in order to darken the midtones some.
> This proved to be "just right", as the real-world image now showed
> excellent shadow detail and the midtone values were closer to where
> they should be:
> 
> http://www.pbase. <http://www.pbase.com/image/66139883> com/image/66139883
> <http://www.pbase. <http://www.pbase.com/image/66139883>
com/image/66139883>

> 
> So in the case of my HPR curves for the 2400, it looks like I'm going 
> to be printing directly from gray-lab using gamma=+4, unless the image
> has no shadows to be concerned with (which is rare for me). The
> resulting prints look amazing, it was definitely worth all the work (I
> can't tell you how many step charts I've printed in the last few
> weeks). My HPR curves are finished, I'll try to write up some notes on
> their usage and post to the group tomorrow. The I guess I'll have to
> start testing with QImage's ICC handling is also broken for printing
> color directly to the print...
>

Roy (or anyone else), can anything be done to develop a profile that better
handles shadows (using QTR-CreateICC or another tool)? 

I've just noticed the same issue on a photo of a dark suit. The suit is well
defined on my calibrated monitor but is almost all black when printed using
a properly defined curve and a profile made using QTR-CreateICC. I converted
the file to this profile using Photoshop and perceptual intent.

I can understand why jkohn_home would fall back to using gray-lab / gamma+4,
but it seems to me that correcting the profile somehow, would be the best
solution. (BTW, thanks for posting your test results!)

Thanks,

Terry.

jkohn_home wrote:

> > So I did one final test using gray- lab instead of the 
> > profile, but boosting the gamma setting in QTR to +4 in 
> order to  darken the midtones some.
> > This proved to  be "just right", as the real-world image now showed 
> > excellent shadow  detail and the midtone values were closer 
> to where 
> > they should be:
> > 
> > http://www.pbase.com/image/66139883
> > <http://www.pbase.com/image/66139883>
> > 
> > So in the case of my HPR curves for the 2400, it looks like 
> I'm going 
> > to be printing directly from gray-lab using gamma=+4, 
> unless the image 
> > has no shadows to be concerned with (which is rare for me). The 
> > resulting  prints look amazing, it was definitely worth all 
> the work

Jeff Kohn wrote:
> I'm running the latest version of QImage, 2007.208. What I don't get is that
> even with Printer ICC disabled (in which case no profile conversion at all
> should be taking place), there was still a change to the L* values in the
> step chart image. It makes me wonder if when printing to file (instead of to
> a printer) there's some intermediate profile conversion taking place that
> shouldn't be (maybe to sRGB?).
>  
> Jeff

Jeff,

You are correct. With CM off in Qimage and an "RGB" greyscale 
target without embedded profile loaded there is no change in 
the step values according to Photoshop. It is different 
however with a true greyscale target like you discovered. It 
doesn't have to be a profile related shift, it could well be a 
shift that happens when Qimage translates greyscale to RGB.
I think it is a new problem as I have tested this in the past 
and  then there were no problems with the CM off (enough with 
CM on though). Doesn't look like a BPC  related issue either 
as the whole range shifts, even up to 4 or 5% at some points 
along the range. Most likely a shift to sRGB + BPC as far as I 
can simulate it with other Qimage settings.

This has to discussed again with Mike Chaney. The problem is
that Qimage is upgrading often and bugs that are only revealed
in odd printing methods are not always discovered right away.

3 possibilities:
The greyscale is getting a profile treatment when it is 
converted to RGB on loading (Qimage internally is RGB only)
The "Honor EXIF color space tag when no profile is embedded" 
is still working on greyscales when CM is off, it is alright 
with RGB files though when it is switched off :-). I have 
discussed this feature with Mike in July 2005 on the Qimage 
list. There are more dangers in that feature.
The greyscale/RGB file gets an sRGB profile treatment when it 
is saved as Print to File. The Web version of Print to File 
may interfere and that one converts to sRGB..

Ernst
-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

On Monday, September 4, 2006, at 12:58  AM, Ernst Dinkla wrote:

> Jeff Kohn wrote:
>> I'm running the latest version of QImage, 2007.208. What I don't get 
>> is that
>> even with Printer ICC disabled (in which case no profile conversion 
>> at all
>> should be taking place), there was still a change to the L* values in 
>> the
>> step chart image. It makes me wonder if when printing to file 
>> (instead of to
>> a printer) there's some intermediate profile conversion taking place 
>> that
>> shouldn't be (maybe to sRGB?).
>>
>> Jeff
>
> Jeff,
>
> You are correct. With CM off in Qimage and an "RGB" greyscale
> target without embedded profile loaded there is no change in
> the step values according to Photoshop. It is different
> however with a true greyscale target like you discovered. It
> doesn't have to be a profile related shift, it could well be a
> shift that happens when Qimage translates greyscale to RGB.
> I think it is a new problem as I have tested this in the past
> and  then there were no problems with the CM off (enough with
> CM on though). Doesn't look like a BPC  related issue either
> as the whole range shifts, even up to 4 or 5% at some points
> along the range. Most likely a shift to sRGB + BPC as far as I
> can simulate it with other Qimage settings.
>
> This has to discussed again with Mike Chaney. The problem is
> that Qimage is upgrading often and bugs that are only revealed
> in odd printing methods are not always discovered right away.
>
> 3 possibilities:
> The greyscale is getting a profile treatment when it is
> converted to RGB on loading (Qimage internally is RGB only)
> The "Honor EXIF color space tag when no profile is embedded"
> is still working on greyscales when CM is off, it is alright
> with RGB files though when it is switched off :-). I have
> discussed this feature with Mike in July 2005 on the Qimage
> list. There are more dangers in that feature.
> The greyscale/RGB file gets an sRGB profile treatment when it
> is saved as Print to File. The Web version of Print to File
> may interfere and that one converts to sRGB..
>
>            Ernst Dinkla
>

I think Ernst may have pinpointed the issue.

Grayscale to RGB conversions that happen implicitly behind the
scenes aren't well documented.  If they go though CM all the intent
and bpc options are hidden, which is a bit scary.

Even in Photoshop I'm not completely sure of all the implicit 
conversions,
but I think they all go through CM -- e.g. I know the eyedropper does 
and
this throws people off quite regularly.

It looks like a little sleuthing is called for.

Roy

-
Roy Harrington
roy@...
Black & White Photo Gallery
http://www.harrington.com

Roy Harrington wrote:

>>
> 
> I think Ernst may have pinpointed the issue.


Roy,

I'm not so sure about that right now.  I have done this before 
and I think I made the same mistake again. Qimage actually 
does exactly the same as Photoshop does when CM is off in both 
applications. When CM is off in PS the Greyscale one will 
convert to the same RGB numbers the Qimage conversion makes 
when CM is off. So Qimage and Photoshop behave the same when 
CM is off. The plain TIFF converter of my website that has no 
CM at all produces the same numbers.

When the Qimage Print to File RGB file is brought back into 
Photoshop  and converted to greyscale (with CM on) to compare 
it to the original that was loaded to Qimage then there's a 
difference but that is because the CM in Qimage was off and 
the CM in Photoshop was on. With CM off in Photoshop the 
Qimage produced RGB file will convert back to the same 
greyscale percentages on the steps.

I guess QTR has the same conversion for RGB>Greyscale as 
Qimage and Photoshop have with CM off. In that case my 
workflow with greyscale converted to the QTR grey printer 
profile, then loaded in Qimage with CM off and the print to 
file RGB sent to QTR which converts it back to greyscale is 
still valid and there is no fault in Qimage.

Ernst

-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

--- In QuadtoneRIP@yahoogroups.com, Ernst Dinkla <E.Dinkla@...> wrote:
>
> Roy Harrington wrote:
>
> >>
> >
> > I think Ernst may have pinpointed the issue.
>
>
> Roy,
>
> I'm not so sure about that right now. I have done this before
> and I think I made the same mistake again. Qimage actually
> does exactly the same as Photoshop does when CM is off in both
> applications. When CM is off in PS the Greyscale one will
> convert to the same RGB numbers the Qimage conversion makes
> when CM is off. So Qimage and Photoshop behave the same when
> CM is off. The plain TIFF converter of my website that has no
> CM at all produces the same numbers.


Here's how I tested. I took the 21-step gray chart from QTR's Eye-One
folder and printed it to file with CM turned off. Now open both the
original file and the QImage-generated file in Photoshop, choosing
"don't color manage" when prompted. Then I looked at the LAB values in
the Info palette to compare the two images. The values from the QImage
file had changed and were no longer correct.

But now that I think about it, the QImage version is actually RGB data,
not grayscale. On a lark, I decided to "assign" the "qtr-rgb-lab"
profile to the image. Once I did that, the L* values for the gray steps
were correct. I'm not entirely sure I understand this result but it does
seem to indicate that printing grayscale images to file in QImage with
Prtr ICC disabled works. Printing the two images in QTR and measuring
indicated that the results were indeed consistent.

That said it still looks like there are problems in the case of actually
trying to use Prtr ICC in QImage so for now I'll be leaving it disabled.
I've settled on keeping my images in gray-lab anyway, as opposed to
converting them to curve-specific ICC profiles before printing so this
shouldn't cause too many problems.

On Monday, September 4, 2006, at 02:03  PM, Ernst Dinkla wrote:

> Roy Harrington wrote:
>
>>>
>>
>> I think Ernst may have pinpointed the issue.
>
>
> Roy,
>
> I'm not so sure about that right now.  I have done this before
> and I think I made the same mistake again. Qimage actually
> does exactly the same as Photoshop does when CM is off in both
> applications. When CM is off in PS the Greyscale one will
> convert to the same RGB numbers the Qimage conversion makes
> when CM is off. So Qimage and Photoshop behave the same when
> CM is off. The plain TIFF converter of my website that has no
> CM at all produces the same numbers.
>
> When the Qimage Print to File RGB file is brought back into
> Photoshop  and converted to greyscale (with CM on) to compare
> it to the original that was loaded to Qimage then there's a
> difference but that is because the CM in Qimage was off and
> the CM in Photoshop was on. With CM off in Photoshop the
> Qimage produced RGB file will convert back to the same
> greyscale percentages on the steps.
>
> I guess QTR has the same conversion for RGB>Greyscale as
> Qimage and Photoshop have with CM off. In that case my
> workflow with greyscale converted to the QTR grey printer
> profile, then loaded in Qimage with CM off and the print to
> file RGB sent to QTR which converts it back to greyscale is
> still valid and there is no fault in Qimage.
>
> Ernst
>

Photoshop doesn't really have a CM off mode when you do
conversions.   What you have set in Color Settings -- the working
spaces determines what happens.

I'm not sure what Qimage does in these cases.

Roy


> -- 
>
>                     --
>            Ernst Dinkla
>
>
> www.pigment-print.com
> (         unvollendet         )
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
-
Roy Harrington
roy@...
Black & White Photo Gallery
http://www.harrington.com

Roy Harrington wrote:
> On Monday, September 4, 2006, at 02:03  PM, Ernst Dinkla wrote:
> 
>> Roy Harrington wrote:
>>
>>> I think Ernst may have pinpointed the issue.
>>
>> Roy,
>>
>> I'm not so sure about that right now.  I have done this before
>> and I think I made the same mistake again. Qimage actually
>> does exactly the same as Photoshop does when CM is off in both
>> applications. When CM is off in PS the Greyscale one will
>> convert to the same RGB numbers the Qimage conversion makes
>> when CM is off. So Qimage and Photoshop behave the same when
>> CM is off. The plain TIFF converter of my website that has no
>> CM at all produces the same numbers.
>>
>> When the Qimage Print to File RGB file is brought back into
>> Photoshop  and converted to greyscale (with CM on) to compare
>> it to the original that was loaded to Qimage then there's a
>> difference but that is because the CM in Qimage was off and
>> the CM in Photoshop was on. With CM off in Photoshop the
>> Qimage produced RGB file will convert back to the same
>> greyscale percentages on the steps.
>>
>> I guess QTR has the same conversion for RGB>Greyscale as
>> Qimage and Photoshop have with CM off. In that case my
>> workflow with greyscale converted to the QTR grey printer
>> profile, then loaded in Qimage with CM off and the print to
>> file RGB sent to QTR which converts it back to greyscale is
>> still valid and there is no fault in Qimage.
>>
>> Ernst
>>
> 
> Photoshop doesn't really have a CM off mode when you do
> conversions.   What you have set in Color Settings -- the working
> spaces determines what happens.
> 
> I'm not sure what Qimage does in these cases.
> 
> Roy
> 

Roy,

Let me start from another point then. Using Photoshop to 
simulate what goes on in Qimage is tricky. I have to admit 
that. Now I just do what my B&W workflow has been so far:

For this test only: I assign, with Photoshop CM on, the Gray 
Lab profile to the 21 step Greyscale target, convert the
assigned Greyscale target to the QTR Gray Matte paper profile, 
save that file.

Load that saved greyscale file in Qimage with CM off and after 
that load the Qimage processed RGB file in Photoshop with CM 
off, convert to Greyscale, and it gets the same %K numbers 
again as the original converted and saved greyscale target has 
in PS (minus or plus some 1% shifts as a result of rounding 
offs on RGB numbers). Could be that the RGB to greyscale 
conversion with CM off in PS is going along my custom monitor 
profile that pops in at the workspace line as a replacement 
for AdobeRGB when I switch CM off.

Even less PS influence: If I pull the same saved greyscale 
through the RGB conversion in TIFFconvert (libTIFF based) I 
get the same RGB numbers in Photoshop as the Qimage processed 
file gives. I expect QTR to behave the same as Qimage with CM 
off or behave like the libTIFF application that knows no CM 
like QTR knows no CM. I see some references to libTIFF in 
CUPS/GIMP/LCMS docs so it may well be the same conversion in 
QTR/TIFFconvert/Qimage. Whether the greyscale to RGB 
conversion defaults to a sRGB or another space relation in all 
applications without CM doesn't matter to me anymore if the 
conversion the other way around is the same again.

The test is like the way I have printed B&W with 
Photoshop>Qimage>QTR since QTR profiles became available. A 
scanned B&W file gets Gamma 2.2 assigned in Vuescan, that file 
is converted to Gray Lab in Photoshop, edited then on a 
calibrated monitor so I like the tones (soft proofing too), 
converted to Gray Matte paper profile (or the custom ones I 
made) and then brought to Qimage with CM off, processed to RGB 
and that dropped in QTR. That worked best for me and I see no 
flaw in this or it has to be the conversion from RGB to 
Greyscale in QTR that isn't transparent to me.

For the time being I stick to this method as I trust Qimage's 
CM conversions on B&W files less but have not tested them lately.


Ernst


-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

jkohn_home wrote:
> 
> --- In QuadtoneRIP@yahoogroups.com, Ernst Dinkla <E.Dinkla@...> wrote:
>> Roy Harrington wrote:
>>
>>> I think Ernst may have pinpointed the issue.
>>
>> Roy,
>>
>> I'm not so sure about that right now. I have done this before
>> and I think I made the same mistake again. Qimage actually
>> does exactly the same as Photoshop does when CM is off in both
>> applications. When CM is off in PS the Greyscale one will
>> convert to the same RGB numbers the Qimage conversion makes
>> when CM is off. So Qimage and Photoshop behave the same when
>> CM is off. The plain TIFF converter of my website that has no
>> CM at all produces the same numbers.
> 
> 
> Here's how I tested. I took the 21-step gray chart from QTR's Eye-One
> folder and printed it to file with CM turned off. Now open both the
> original file and the QImage-generated file in Photoshop, choosing
> "don't color manage" when prompted. Then I looked at the LAB values in
> the Info palette to compare the two images. The values from the QImage
> file had changed and were no longer correct.
> 
> But now that I think about it, the QImage version is actually RGB data,
> not grayscale. On a lark, I decided to "assign" the "qtr-rgb-lab"
> profile to the image. Once I did that, the L* values for the gray steps
> were correct. I'm not entirely sure I understand this result but it does
> seem to indicate that printing grayscale images to file in QImage with
> Prtr ICC disabled works. Printing the two images in QTR and measuring
> indicated that the results were indeed consistent.
> 
> That said it still looks like there are problems in the case of actually
> trying to use Prtr ICC in QImage so for now I'll be leaving it disabled.
> I've settled on keeping my images in gray-lab anyway, as opposed to
> converting them to curve-specific ICC profiles before printing so this
> shouldn't cause too many problems.

Don't think you used the right solution to get the test 
correct as far as I can understand it.

I also think that you throw away the best part of QTR's ICC 
profiling this way. There's very little difference between 
keeping the images in Gamma 2.2 or Gray Lab and what it brings 
is may be only visible in a CM environment when editing. But 
there's a lot more control by using (custom or generic) QTR 
printer profiles for editing in a CM application (softproof) 
and after conversion to the profile in printing with QTR or 
with Epson's ABW.

Ernst
-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

BTW,

Picture Window Pro is giving the same conversions as Qimage 
and TIFFconvert, all with CM off.
With CM off the Greyscale>RGB>Greyscale conversions are based 
on a mapping table.


Ernst

-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

Ernst,

The trouble with this whole discussion is that there are many settings
in all these programs that are left unspecified.

Take for instance this excerpt:

> that load the Qimage processed RGB file in Photoshop with CM
> off, convert to Greyscale, and it gets the same %K numbers
> again as the original converted and saved greyscale target has

Presumably the RGB file from Qimage is "untagged RGB".   If you read it
into PS its treated as if it had the RGB working space in PS Color 
Settings.
If you convert to grayscale it converts to the Gray working space.  So 
it's
impossible to draw any conclusions.  I.e. lots of CM is happening, you 
can't
get away from it.

In PS just because something says "untagged" doesn't mean that there's 
no CM
going on -- it just means that the profile being used isn't stored with 
the file.
It will be treated as the corresponding working space.

 From what I've deciphered Qimage is a bit more complicated.  It says 
input file
embedded profiles are always honored, but you can turn off Ptr ICC 
conversion
so there's nothing to convert it too.  I'm guessing this may be the one 
exception
to the "CM is always running" rule -- because somehow you have to be 
able
to go from a profiled gray input to RGB output.  I think it just sets 
R=G=B=gray input.

The only way to understand all this is break everything into individual 
steps and
understanding what each does.

Roy

On Tuesday, September 5, 2006, at 04:48  AM, Ernst Dinkla wrote:

> Roy Harrington wrote:
>> On Monday, September 4, 2006, at 02:03  PM, Ernst Dinkla wrote:
>>
>>> Roy Harrington wrote:
>>>
>>>> I think Ernst may have pinpointed the issue.
>>>
>>> Roy,
>>>
>>> I'm not so sure about that right now.  I have done this before
>>> and I think I made the same mistake again. Qimage actually
>>> does exactly the same as Photoshop does when CM is off in both
>>> applications. When CM is off in PS the Greyscale one will
>>> convert to the same RGB numbers the Qimage conversion makes
>>> when CM is off. So Qimage and Photoshop behave the same when
>>> CM is off. The plain TIFF converter of my website that has no
>>> CM at all produces the same numbers.
>>>
>>> When the Qimage Print to File RGB file is brought back into
>>> Photoshop  and converted to greyscale (with CM on) to compare
>>> it to the original that was loaded to Qimage then there's a
>>> difference but that is because the CM in Qimage was off and
>>> the CM in Photoshop was on. With CM off in Photoshop the
>>> Qimage produced RGB file will convert back to the same
>>> greyscale percentages on the steps.
>>>
>>> I guess QTR has the same conversion for RGB>Greyscale as
>>> Qimage and Photoshop have with CM off. In that case my
>>> workflow with greyscale converted to the QTR grey printer
>>> profile, then loaded in Qimage with CM off and the print to
>>> file RGB sent to QTR which converts it back to greyscale is
>>> still valid and there is no fault in Qimage.
>>>
>>> Ernst
>>>
>>
>> Photoshop doesn't really have a CM off mode when you do
>> conversions.   What you have set in Color Settings -- the working
>> spaces determines what happens.
>>
>> I'm not sure what Qimage does in these cases.
>>
>> Roy
>>
>
> Roy,
>
> Let me start from another point then. Using Photoshop to
> simulate what goes on in Qimage is tricky. I have to admit
> that. Now I just do what my B&W workflow has been so far:
>
> For this test only: I assign, with Photoshop CM on, the Gray
> Lab profile to the 21 step Greyscale target, convert the
> assigned Greyscale target to the QTR Gray Matte paper profile,
> save that file.
>
> Load that saved greyscale file in Qimage with CM off and after
> that load the Qimage processed RGB file in Photoshop with CM
> off, convert to Greyscale, and it gets the same %K numbers
> again as the original converted and saved greyscale target has
> in PS (minus or plus some 1% shifts as a result of rounding
> offs on RGB numbers). Could be that the RGB to greyscale
> conversion with CM off in PS is going along my custom monitor
> profile that pops in at the workspace line as a replacement
> for AdobeRGB when I switch CM off.
>
> Even less PS influence: If I pull the same saved greyscale
> through the RGB conversion in TIFFconvert (libTIFF based) I
> get the same RGB numbers in Photoshop as the Qimage processed
> file gives. I expect QTR to behave the same as Qimage with CM
> off or behave like the libTIFF application that knows no CM
> like QTR knows no CM. I see some references to libTIFF in
> CUPS/GIMP/LCMS docs so it may well be the same conversion in
> QTR/TIFFconvert/Qimage. Whether the greyscale to RGB
> conversion defaults to a sRGB or another space relation in all
> applications without CM doesn't matter to me anymore if the
> conversion the other way around is the same again.
>
> The test is like the way I have printed B&W with
> Photoshop>Qimage>QTR since QTR profiles became available. A
> scanned B&W file gets Gamma 2.2 assigned in Vuescan, that file
> is converted to Gray Lab in Photoshop, edited then on a
> calibrated monitor so I like the tones (soft proofing too),
> converted to Gray Matte paper profile (or the custom ones I
> made) and then brought to Qimage with CM off, processed to RGB
> and that dropped in QTR. That worked best for me and I see no
> flaw in this or it has to be the conversion from RGB to
> Greyscale in QTR that isn't transparent to me.
>
> For the time being I stick to this method as I trust Qimage's
> CM conversions on B&W files less but have not tested them lately.
>
>
> Ernst
>
>
> -- 
>
>                     --
>            Ernst Dinkla
>
-
Roy Harrington
roy@...
Black & White Photo Gallery
http://www.harrington.com

Roy Harrington wrote:

> 
> The only way to understand all this is break everything into individual 
> steps and
> understanding what each does.

Roy,

One way to get some grip on this is by getting the knowledge 
how QTR does the RGB to Grayscale conversion.
Given the print results I get it must be compatible to Qimage 
conversions and of the last I see no difference in PWP and 
TIFFconvert. I think it goes all back to the same mapping 
table when CM isn't used.

Ernst
-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

On Wednesday, September 6, 2006, at 03:25  PM, Ernst Dinkla wrote:

> Roy Harrington wrote:
>
>>
>> The only way to understand all this is break everything into 
>> individual
>> steps and
>> understanding what each does.
>
> Roy,
>
> One way to get some grip on this is by getting the knowledge
> how QTR does the RGB to Grayscale conversion.

Well, that's easy.   For a gray RGB file i.e. R=G=B, the grayscale 
values are the same as R, G, or B.
When it's actually a color image fixed weightings are used:

     Gray = .31*R + .61*G + .08*B

> Given the print results I get it must be compatible to Qimage

Qimage never does RGB to Grayscale, but Grayscale to RGB in the absence 
of profiles & CM (Ptr ICC Off)
I think it does R=G=B = Gray,  so I guess that's compatible.   In 
general these probably would be
the non-CM conversions for any non-ICC product.

All CM conversions will preserve L values as much as possible.  The 
difficulties are where K=100 is not L=0,
then BPC etc can give various results.

Roy

> conversions and of the last I see no difference in PWP and
> TIFFconvert. I think it goes all back to the same mapping
> table when CM isn't used.
>
> Ernst
> -- 
>
>                     --
>            Ernst Dinkla
>
-
Roy Harrington
roy@...
Black & White Photo Gallery
http://www.harrington.com

Roy Harrington wrote:
> On Wednesday, September 6, 2006, at 03:25  PM, Ernst Dinkla wrote:
> 
>> Roy Harrington wrote:
>>
>>> The only way to understand all this is break everything into 
>>> individual
>>> steps and
>>> understanding what each does.
>> Roy,
>>
>> One way to get some grip on this is by getting the knowledge
>> how QTR does the RGB to Grayscale conversion.
> 
> Well, that's easy.   For a gray RGB file i.e. R=G=B, the grayscale 
> values are the same as R, G, or B.
> When it's actually a color image fixed weightings are used:
> 
>      Gray = .31*R + .61*G + .08*B
> 
>> Given the print results I get it must be compatible to Qimage
> 
> Qimage never does RGB to Grayscale, but Grayscale to RGB in the absence 
> of profiles & CM (Ptr ICC Off)
> I think it does R=G=B = Gray,  so I guess that's compatible.   In 
> general these probably would be
> the non-CM conversions for any non-ICC product.
> 
> All CM conversions will preserve L values as much as possible.  The 
> difficulties are where K=100 is not L=0,
> then BPC etc can give various results.
> 
> Roy

Roy,

So the main lesson learned is: avoid Photoshop to check Print 
to File results, even with CM off. The other one: there's no 
flaw in the Qimage transfer when CM in Qimage is off.

Ernst

-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )

> So the main lesson learned is: avoid Photoshop to check Print 
> to File results, even with CM off. The other one: there's no 
> flaw in the Qimage transfer when CM in Qimage is off.
> 

It's funny I consider myself pretty knowledgeable in the area of CM, at
least for a color workflow using all CM-aware apps. But when you starting
mixing CM and non-CM applications and image files, things definitely start
to get a little more complex.

After more testing I agree that the best bet seems to be performing any CM
operations in Photoshop and then disabling "Printer ICC" in Qimage.

Jeff

> I also think that you throw away the best part of QTR's ICC 
> profiling this way. There's very little difference between 
> keeping the images in Gamma 2.2 or Gray Lab and what it 
> brings is may be only visible in a CM environment when 
> editing. But there's a lot more control by using (custom or 
> generic) QTR printer profiles for editing in a CM application 
> (softproof) and after conversion to the profile in printing 
> with QTR or with Epson's ABW.
> 
> Ernst

In the case of matte/rag papers, I've found I get better results by keeping
the image in gray-lab and printing with Gamma slider set to +4. Converting
to the ICC profile blocks up the shadows too much.

Results might be different for different papers, I haven't tested this
approach with semigloss/luster papers yet.

Jeff

--- In QuadtoneRIP@yahoogroups.com, Ernst Dinkla <E.Dinkla@...> wrote:
>
> Roy Harrington wrote:
> > On Wednesday, September 6, 2006, at 03:25  PM, Ernst Dinkla wrote:
> > 
> >> Roy Harrington wrote:
> >>
> >>> The only way to understand all this is break everything into 
> >>> individual
> >>> steps and
> >>> understanding what each does.
> >> Roy,
> >>
> >> One way to get some grip on this is by getting the knowledge
> >> how QTR does the RGB to Grayscale conversion.
> > 
> > Well, that's easy.   For a gray RGB file i.e. R=G=B, the grayscale 
> > values are the same as R, G, or B.
> > When it's actually a color image fixed weightings are used:
> > 
> >      Gray = .31*R + .61*G + .08*B
> > 
> >> Given the print results I get it must be compatible to Qimage
> > 
> > Qimage never does RGB to Grayscale, but Grayscale to RGB in the absence 
> > of profiles & CM (Ptr ICC Off)
> > I think it does R=G=B = Gray,  so I guess that's compatible.   In 
> > general these probably would be
> > the non-CM conversions for any non-ICC product.
> > 
> > All CM conversions will preserve L values as much as possible.  The 
> > difficulties are where K=100 is not L=0,
> > then BPC etc can give various results.
> > 
> > Roy
> 
> Roy,
> 
> So the main lesson learned is: avoid Photoshop to check Print 
> to File results, even with CM off. The other one: there's no 
> flaw in the Qimage transfer when CM in Qimage is off.
> 
> Ernst
> 

I wouldn't say avoid Photoshop.  Just realize what it does and use appropriately.

With Photoshop the key things are:

1) When you open a file do NOT do a conversion if the file has an embedded profile.

2) In Color Settings you should NOT have "Convert to Working Space" ON.
(I'd recommend these things all the time anyway)

3) When you use the Info palette to see what's there, look at K for grayscale files
and RGB for RGB files.  There's a tendency to look at wrong ones depending on
whether you want 0-100 or 0-255 values.  Looking at L-values always involves
CM conversion since they are not what's stored.   L-values are a good way to see
what is being preserved on CM conversions.

Because of (3), if you are using a workflow which bounces you back and forth with
Gray <--> RGB conversions,  I would stick with Working Spaces that have the same
Luminosity curves.   Common pairs are:
Gray Gamma 2.2  and  AdobeRGB
QTR GrayLab        and QTR RGBLab
Gray Gamma 1.8  and ColorMatch

If you always use these pairs then (3) is not an issue since conversions will yield
the same values.

Roy

> -- 
> 
>                     --
>            Ernst Dinkla
> 
> 
> www.pigment-print.com
> (         unvollendet         )
>

Roy Harrington wrote:
> --- In QuadtoneRIP@yahoogroups.com, Ernst Dinkla <E.Dinkla@...> wrote:
>> Roy Harrington wrote:
>>> On Wednesday, September 6, 2006, at 03:25  PM, Ernst Dinkla wrote:
>>>
>>>> Roy Harrington wrote:
>>>>
>>>>> The only way to understand all this is break everything into 
>>>>> individual
>>>>> steps and
>>>>> understanding what each does.
>>>> Roy,
>>>>
>>>> One way to get some grip on this is by getting the knowledge
>>>> how QTR does the RGB to Grayscale conversion.
>>> Well, that's easy.   For a gray RGB file i.e. R=G=B, the grayscale 
>>> values are the same as R, G, or B.
>>> When it's actually a color image fixed weightings are used:
>>>
>>>      Gray = .31*R + .61*G + .08*B
>>>
>>>> Given the print results I get it must be compatible to Qimage
>>> Qimage never does RGB to Grayscale, but Grayscale to RGB in the absence 
>>> of profiles & CM (Ptr ICC Off)
>>> I think it does R=G=B = Gray,  so I guess that's compatible.   In 
>>> general these probably would be
>>> the non-CM conversions for any non-ICC product.
>>>
>>> All CM conversions will preserve L values as much as possible.  The 
>>> difficulties are where K=100 is not L=0,
>>> then BPC etc can give various results.
>>>
>>> Roy
>> Roy,
>>
>> So the main lesson learned is: avoid Photoshop to check Print 
>> to File results, even with CM off. The other one: there's no 
>> flaw in the Qimage transfer when CM in Qimage is off.
>>
>> Ernst
>>
> 
> I wouldn't say avoid Photoshop.  Just realize what it does and use appropriately.
> 
> With Photoshop the key things are:
> 
> 1) When you open a file do NOT do a conversion if the file has an embedded profile.
> 
> 2) In Color Settings you should NOT have "Convert to Working Space" ON.
> (I'd recommend these things all the time anyway)
> 
> 3) When you use the Info palette to see what's there, look at K for grayscale files
> and RGB for RGB files.  There's a tendency to look at wrong ones depending on
> whether you want 0-100 or 0-255 values.  Looking at L-values always involves
> CM conversion since they are not what's stored.   L-values are a good way to see
> what is being preserved on CM conversions.
> 
> Because of (3), if you are using a workflow which bounces you back and forth with
> Gray <--> RGB conversions,  I would stick with Working Spaces that have the same
> Luminosity curves.   Common pairs are:
> Gray Gamma 2.2  and  AdobeRGB
> QTR GrayLab        and QTR RGBLab
> Gray Gamma 1.8  and ColorMatch
> 
> If you always use these pairs then (3) is not an issue since conversions will yield
> the same values.
> 
> Roy

Roy,

After my initial mistake with the CM of Photoshop interfering, 
even when switched off, there wasn't a problem anymore later 
on. I kept the conversions to a minimum and checked the same 
conversions in other applications too and everywhere on the 
right units per file type.
The file that is exported from Qimage doesn't have an embedded 
profile if the right settings are used in Qimage. My last 
message was more a warning to be sceptic about the next one 
who reports that Qimage mangles the numbers with CM off. First 
thing to ask is whether it was seen in Photoshop. I made the 
mistake myself 2x now.  But I'm a bit paranoia on Qimage's 
behaviour because I discovered abnormalities in the past with 
Qimage CM on and the use of the QTR RGB profiles (BPC 
interpretation probably). The Gray ones didn't work at all at 
that time. You are a bit reserved on what happens in Qimage 
too if I read between the lines. It would be wonderful if 
Qimage had a greyscale bypass, asked for it, but that will not 
happen.

AdobeRGB and Gamma 2.2 are the ones I get from Vuescan. 
Vuescan defaults greyscale embedded profiles always to Gamma 
2.2 when AdobeRGB is chosen as the embedded profile for color 
file export, no other choice possible. Logical relation. When 
I load the Gamma 2.2 in Photoshop I convert it to Gray Lab as 
that is the profile I like to use. Not much difference in 
practice but let's say it has the theoretical approach that I 
like. Been thinking of that concept at the time you developed 
it. More human than dotgain or gamma :-)

The files I get from others are AdobeRGB or Gamma 2.2, as 
requested. As long as there are profiles embedded one may 
expect a logical CM past. May not be so obvious though. 
Sometimes I get files without embedded profiles and that's 
more of a p**a as it usually means there's more wrong.

I'm aware of the matches based on Gamma but the use of both 
QTR versions RGBLab and GrayLab has no practical sense to me, 
I prefer to keep the greyscale images grey all the time and 
AdobeRGB is more or less the common workhorse right now so 
that's the other standard. Conversions to one another hardly 
happen and CM should take care of that. To exaggerate; number 
checking may have been the topic this week, it isn't the rest 
of the time.

Have to use QTR for two canvasses tomorrow. Nice to know I did 
it right so far.

Ernst







-- 

                    --
           Ernst Dinkla


www.pigment-print.com
(         unvollendet         )