HP LaserJet Pro CP1025 / CP1025nw :  foo2zjs - foo2hp - foo2xqx - foo2lava - foo2qpdl - foo2oak
Support for linux printer drivers
The fastest message board... ever.
 
gs 9.04 and color
Posted by: wolf ()
Date: October 11, 2011 11:05PM

I upgraded one of my systems to Fedora 15 running ghostscript 9.04. I installed the foo2zjs package from the sources (version string on the source file "$Id: foo2zjs.c,v 1.108 2011/06/09 14:06:24 rick Exp $").

The results were horrible. It seems ghostscript 9.04 did a lot of damage to its colour correction code. After some playing with the gs executable, I noticed the following.

- The type 1 halftone screen that foo2zjs-wrapper and foo2zjs-pstops uses seems to be used as-is for all colours. The 8.71 GS takes the defined halftone screen and rotates it for each colour. The off-the-shelf GS 9.04 does not, keeping the same values for each colour. Instead of getting a good continuous colour gradient, you get quantized colours that you can not profile properly. I changed the type 1 to a type 5 with each colour defined as a type 1 screen with explicit angles. This restored proper functionality.
- What the foo2zjs-wrapper does to pass the colour profile to GS seems to be ignored by the executable. I tried to use the -sOutputICCProfile to at least let me use a profile on the printer. This seemed to work ok, but the profile used had to be a CMYK one, not an RGB one.
- The -sRenderIntent parameter always generated a type error in GS 9.04, so appears to be broken.
- I seemed to occasionally get a corrupted black channel on my HP Laserjet CP1025nw printer. I'm not sure what triggered this.

Joe



Edited 1 time(s). Last edit at 10/12/2011 06:44AM by rickrich.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: rickrich ()
Date: October 12, 2011 06:19PM

$ ll /tmp/gs*
-rw-rw-r-- 1 rick rick 551367 Oct 12 17:14 /tmp/gs871.default
-rw-rw-r-- 1 rick rick 479747 Oct 12 17:13 /tmp/gs871.none
-rw-rw-r-- 1 rick rick 653635 Oct 12 17:14 /tmp/gs900.default
-rw-rw-r-- 1 rick rick 653635 Oct 12 17:14 /tmp/gs900.none
-rw-rw-r-- 1 rick rick 658039 Oct 12 17:14 /tmp/gs901.default
-rw-rw-r-- 1 rick rick 639163 Oct 12 17:14 /tmp/gs901.none
-rw-rw-r-- 1 rick rick 658039 Oct 12 17:15 /tmp/gs902.default
-rw-rw-r-- 1 rick rick 639163 Oct 12 17:15 /tmp/gs902.none
-rw-rw-r-- 1 rick rick 658039 Oct 12 17:15 /tmp/gs903.default
-rw-rw-r-- 1 rick rick 639163 Oct 12 17:15 /tmp/gs903.none
-rw-rw-r-- 1 rick rick 544411 Oct 12 17:16 /tmp/gs904.default
-rw-rw-r-- 1 rick rick 532651 Oct 12 17:15 /tmp/gs904.none

Yep. Use gs8.71+.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: wolf ()
Date: November 04, 2011 10:36PM

I've continued playing with GS 9.04. The -sOutputICCProfile option does work, once you make a CMYK profile.

The biggest frustration I have is that GS produces bitcmyk output that, by the time it gets to my CP1025nw, has the black channel mangled on the first page. Any pages after that don't work.

I have tweaked the foo2zjs-wrapper and foo2zjs-pstops scripts as stated in my previous post to test the GS 9.04 options. I'm using the stock foo2zjs utility to convert the resulting bitmap.

I'd expect that anything that GS can put in a bitcmyk file should be dealt with properly by foo2zjs, and indirectly by my printer, no matter what I did to make the file. This doesn't seem to be the case.

I'll try to find somewhere to upload example files to show what I'm seeing.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: wolf ()
Date: November 05, 2011 10:48PM

I think I found my problem. It can be summarized in the following statement from "foo2zjs-wrapper":

"Various versions of ZjS print engines react differently when asked to print into their unprintable regions."

There seems to be a lot of random numbers for margins that make things work OK. I also tried some PS code recommended by "align.ps" in the ghostscript distribution that seems to make GS avoid the edges.

I got things working, but I'm not exactly sure why. Between GS and these printers, it's a miracle anything works.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: wolf ()
Date: November 10, 2011 10:41PM

I'm not convinced that all of my garbled output was due to margin issues. I installed the basic HP drivers onto an XP system I had, and used Wireshark to capture the stream and save it to a file. I can replicate the resulting ZJS header info with the foo2zjs parameters "-u 196x96 -l 196x96" on a letter size paper. Even with these, I still can get garbled output on the printer.

Looking deeper, I pulled the JBIG streams out of the saved ZJS capture with the "zjsdecode -r" command. I then decoded these with the "jbgtopbm -d" command from the jbigkit package.

Any streams that failed had the "ATMOVE" directive in the JBIG streams. Those that worked did not. The smaller the plane number that the ATMOVE directive shows up in, the more spectacular the failure. The working Linux streams were clean, as were the couple of XP tests I did.

My rather small sample size makes this result circumstantial at best.

I know my manual ghostscript and foo2zjs experiments that lead to this result put me outside of any standard support questions, but any advice on how to disable the generation of the suspect directives would be appreciated. I'd like to see if I'm heading down the wrong path.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: rickrich ()
Date: November 11, 2011 03:15AM

Turn off JBG_DELAY_AT ???

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: wolf ()
Date: November 11, 2011 09:07PM

No, that just changed when it was generated, not if it was. Setting MX to 0 seemed to do the trick. Per the ITU-T Rec. T.82:

"The seventeenth and eighteenth bytes shall specify MX and MY, the maximum horizontal and vertical offsets allowed for the AT pixel."

If the AT pixel is not allowed to move, there's no fear the encoder will try to tell the decoder where it is with the ATMOVE directive.

I'm getting more consistent results with that.

I can now go back to my GS experiments. The HP drivers produce a much smoother picture than GS can. I'll have to play with halftone screens and the -A and -B parameters to foo2zjs to try to figure that out.

This is an interesting diversion, but it's killing my toner budget. I think another black toner is nearly gone :-)

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: rickrich ()
Date: November 12, 2011 11:42AM

From the Changelog:
2011-11-12      Rick Richardson <rick.richardson@comcast.net>
        * foo2zjs: there is a bug in HP printers p1102 (-z2) and
            cp1025 (-z3).  Workaround is to set MX=0.
        * foo2zjs-wrapper: fix initial offset for -z2 and -z3 printers.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: wolf ()
Date: November 17, 2011 10:38PM

I think I have a reasonable solution to help save my toner budget.

I wrote the following BASH script to produce RGB TIFF files from ZJS files. The RGB values are based on my measurements of the CMYK primaries of my printer.

This leaves all of the intermediate files laying around to assist in debugging what's going on.

This assumes that foo2zjs, jbigkit, and netpbm packages are installed.

#!/bin/sh

# The goal of this program is to test the creation of zjs streams without the
# need for a large toner budget.

# This program creates a tif file proof of the original ZJS stream.  It is
# assumed that the original files were created with a resolution of 1200x600.

# This decodes the ZJS stream to JBG files.  The JBG files are decoded to
# pbm files.  Each plane is given a bit position (C=0x8, M=0x4, Y=0x2, K=0x1).
# The netpbm-progs are used to do the following on each plane:
# 1) Convert each one-bit value to a four bit value
# 2) Mask out all but the proper bit (listed above).
# 3) Merge all of the resulting planes togther with an bitwise-OR operation.

# Once the planes are merged, the resulting data is used as an index to a
# color map file.  The color map was created by printing pure patches of
# color in each of the subtractive primaries.  This page was scanned with a
# color calibration target.  The image was color-corrected, and quantized down
# to the five main colors: white, cyan, magenta, yellow, black.

# Each non-white color was normalized, using the white sample as unit value
# for the RGB channels.  These normalized values were multiplied together
# as needed to make the factors for each possible color combination and for
# each channel.  These resulting values were then re-scaled back to the max
# values of the white sample. The result is included below in the inline
# color map.

filename=$1; shift
base=${filename##*/}
base=${base%.*}

declare -a planebits=(0x0 0x8 0x4 0x2 0x1)

zjsdecode -r $base $filename
for i in *.jbg
do
  jbgtopbm $i ${i%.*}.pbm
done

for i in *-1.pbm
do
  prefix=${i%-1.pbm}
  
  for ((j=1; $j <= 4; j += 1))
  do
    if [[ -f ${prefix}.pgm ]]
    then 
      pnminvert ${prefix}-${j}.pbm | pamdepth 15 | pamfunc -andmask=${planebits[$j]} | pamarith -or - ${prefix}.pgm > ${prefix}-tmp.pgm
      rm -f ${prefix}.pgm
      mv ${prefix}-tmp.pgm ${prefix}.pgm
    else
      pnminvert ${prefix}-${j}.pbm | pamdepth 15 | pamfunc -andmask=${planebits[$j]} > ${prefix}.pgm
    fi
  done
  pamlookup -lookupfile=- ${prefix}.pgm << EOF > ${prefix}.pam
P3
16 1
255
228	231	241
49	59	57
228	225	64
49	57	15
219	34	120
47	8	28
219	33	31
47	8	7
7	124	204
1	31	48
7	120	54
1	30	12
6	18	101
1	4	24
6	17	26
1	4	6
EOF

  pamtotiff -xresolution=1200 -yresolution=600 -resolutionunit=inch ${prefix}.pam > ${prefix}.tif

done

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: wolf ()
Date: November 26, 2011 11:56AM

I found an excellent guide to halftone parameters at:

http://www.heidelberg.com/h/www/binaries/bin/files/dotcom/en/prinect/expert_guide_screening_tech.pdf

It has a good discussion on halftones, and plenty of examples for screening angles. I tested the examples until I found one that worked for me. I have good results with the following parameters:

150 lpi
Angles:
C=105
M=165
Y=30
K=45

I'm not a big fan of the foo2zjs -A and -B parameters. It has a tendency to leave holes in the CMY planes from the K one. The bits promoted from CMY to K mess up the nice dot pattern on the K plane. A little misregistration then leads to diagonal streaking at the K angle.

One thing I noticed was that if you play with the halftone parameters, you almost have to generate a new ICC profile to tell GS how the halftone will respond.

The halftone parameters above without the -A and -B foo2zjs flags produced a nice CMYK profile using the Argyll tools, that I was able to apply with the GS 9.04 "-sOutputICCProfile" parameter.

The Argyll tools produce a PS file that seems to reset the graphics state and messes up the halftone parameters. I had good results setting the applied halftone as default with "/Default exch /Halftone defineresource" inserted between the hafltone definition and the "sethalftone". I got that trick from GS "stocht.ps" lib file.

I still haven't figured out the GS "-sRenderIntent" stuff. That seems to be broken. When using GS 9.04 I have no choice of render intent.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: rickrich ()
Date: November 26, 2011 04:05PM

git source: ~/ghostpdl/gs/toolbin/halftone/gen_ordered/README

Been meaning to figure this out. Appeared in 9.0.

Options: ReplyQuote
Re: gs 9.04 and color
Posted by: wolf ()
Date: February 09, 2012 11:40PM

I looked at the gen_ordered stuff. It's interesting at identifying the rational screening angles at various resolutions. It does produce type 3 halftone dictionaries, but they seem to be at least 3 times wider than I would think they should be. I'm not sure it's ready for prime time.

I've been using the following halftone definition with WTS. It does produce generally good results with gs 9.04. Solid fields of color have a tendency to have a slight grainy look.

/SpotDot { 180 mul cos exch 180 mul cos add 2 div } def

<< /HalftoneType 5
/Cyan <<
/HalftoneType 1
/AccurateScreens true
/Frequency 150
/Angle 105
/SpotFunction /SpotDot load
>>
/Magenta <<
/HalftoneType 1
/AccurateScreens true
/Frequency 150
/Angle 165
/SpotFunction /SpotDot load
>>
/Yellow <<
/HalftoneType 1
/AccurateScreens true
/Frequency 150
/Angle 30
/SpotFunction /SpotDot load
>>
/Black <<
/HalftoneType 1
/AccurateScreens true
/Frequency 150
/Angle 45
/SpotFunction /SpotDot load
>>
/Default <<
/HalftoneType 1
/AccurateScreens true
/Frequency 150
/Angle 37
/SpotFunction /SpotDot load
>>
>> /Default exch /Halftone defineresource sethalftone

I pair this with a CMYK profile that I generate with the argyll utilities, using the procedures identifed int the "Scenarios.html" document. This is applied with the "-sOutputICCProfile" gs parameter.

I noticed that the "-sRenderIntent" always fails with a type error. If I use "-dRenderIntent" with numeric intent values, I get no errors. This still doesn't actually change the resulting output, with or without "-dOverrideRI" set.

One thing I was thinking about was the use of the "-sSourceObjectICC=filename" syntax. The docs say it lets you specify different profiles for different types of objects (text, images, etc.), all tied together. The file specified would actually be a farly complex bundling of many color profiles and render intents (if they ever get that working) for different objects.

That file could be what is chosen in the "ICM Color Profile" field in the Advanced printer properties dialog properties. That would keep a lot of color profile uglyness out of foo2zjs-wrapper.

Of course all of this is useless until the underlying color code stablizes.

Options: ReplyQuote


Sorry, only registered users may post in this forum.
This forum powered by Phorum.