Digital BW, The Print

>On 12/15/02 4:16 PM, "Tyler Boley <tyler@...>"
><tyler@...> wrote:
>
>>  John Labovitz, a long time quad printer and much brighter person than
>>  I, has demonstrated to me that good hackers could easily build a
>>  custom driver from this thing and have a great deal of ink control to
>  > accomplish any number of desired results.

John is also much brighter than I am, but his dad probably trumps us 
all (the three of us met at a Piezo workshop up at Cone Editions).

>
>While by no means do I have what anyone would call a "driver," I have been
>playing with gimp-print's ability to fully control each ink separately.
>
>First, I should note that gimp-print 4.2 (the current release) has a partial
>control which is somewhat confusingly called "Raw CMYK."  As Tyler noted,
>some color munging is happening even with this "raw" mode, which is probably
>the fault of OS X's inherent and insistent color management.  It's also by
>necessity filling in "appropriate" values for the light-cyan and
>light-magenta positions on 6-color printers.  All this translation causes a
>few problems doing quadtones.

In my preliminary tests, using CMYK curves to partition the inks in 
PS7, I had no problem "re-creating" Piezo 21-step ramps with either 
the 4-ink 1160 or the 6-ink 1200, using the double C and M system 
rather than the dilute MIS variant. PiezoTone WN in the 1160, MIS FS 
in the 1200. The only advantage I could see for dilute inks with this 
approach might be slightly smoother highlight transitions with the 
lighter magenta.

>  But even that's better than trying to fool
>the Epson driver by sending it RGB data, as most workflows attempt to do.

Yes, that was part of what attracted me to Gimp Print originally.

>
>Gimp-print 4.3 (the "development" release) has full control over each ink
>position ("true raw" mode).  In theory, one can specify exactly how much ink
>is laid down in a particular ink position, completely independently of any
>other ink.  Or you can overlay inks precisely -- like putting a 25% gray ink
>under the 100% black ink to get even more density than 100% alone.  There's
>nothing in between that's mucking with the data.

Any changes with the latest version?

>
>This is pretty exciting for quad/hextone work!  The trouble is, there's a
>long way between Photoshop and this raw mode of gimp-print.
>
>I've written some proof-of-concept code that will take 6-channel Photoshop
>files and use the data in each channel to control the 6 inks of the MIS-FSN
>hextone inks I'm using.  It's very much of a hack, though, requiring use of
>the command-line, raw Photoshop files, undocumented gimp-print test tools,
>and black magic.  But in theory, one could use the traditional
>manual-separation techniques (talk to Tyler about this) to restrict certain
>tones to certain ink positions.

I guess that's what my approach does.

>
>However, what I'm working hard on how is grayscale separation, much like the
>Piezo driver or Imageprint does.  The idea is to take a grayscale file
>(single channel, 8- or 16-bit) and automagically convert it to a
>multi-channel file, one per ink position.

We would pretty much have that if there was direct CcMmYK ink control, no?

>
>I'm making this work by using lookup tables, so a gray of a certain value
>translates to a certain set of values for each of the ink positions.  The
>translation and printing is fairly easy.
>
>What's complicated is figuring out what's *in* those translation tables.
>I'm trying to do this in a generic way, rather than assuming that the inks
>are 100%/75%/50%/45%/25/15%, as MIS claims.  Instead, I'm printing 21-step
>gray ramps for each ink position, scanning the resulting print, and mapping
>the supposed densities to the actual densities (leaving out the densities
>that aren't useful, like the ones that bleed from too much ink).  From those
>maps, I can build translation tables for a combination of a certain
>paper/ink/etc.
>
>In effect, this is like making a profile, but doesn't involve anything
>ICC-related.

Could commercial profile-building software do this? Jon Cone has 
noted that the ICQ profiles the Piezo driver uses are not the same as 
ICC color profiles, as a way of explaining why they couldn't generate 
them in VT.  Are they just LUTs?

Bruce
-- 
Bruce C. Kinch
Associate Professor of Photography
The Art Institute of Boston at Lesley University