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.

I'll elaborate on this.  Apologies for the length.

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.  But even that's better than trying to fool
the Epson driver by sending it RGB data, as most workflows attempt to do.

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.

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.

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.

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.

It's actually starting to work okay.  Just this morning, I got a true
hextone print, although one that's hella posterized.  I think my major
problem now is that my scanner's not a good densitometer, so the values I'm
putting into the tables are pretty bogus.

But I'll keep folks posted as to what develops.

-- 
John Labovitz
johnl@...
www.johnlabovitz.com

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, John 
Labovitz <johnl@j...> wrote:
> 
> I'll elaborate on this.  Apologies for the length.
> 
> 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.  But even that's better than 
trying to fool
> the Epson driver by sending it RGB data, as most workflows 
attempt to do.
> 
> 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.
> 
...
> 
> But I'll keep folks posted as to what develops.
> 
> -- 
> John Labovitz
> johnl@j...
> www.johnlabovitz.com


Hi John,

I've been looking into doing some of the same things.  I have
been trying gimp-print 4.2 with quadtone and Raw CMYK but
I think the munging with color is a problem.

I've tried to get 4.3 up and running but have only found
source code (no binaries).    Are binaries available or better
yet instructions for the OS X compilation?  

Thanks,
Roy

roy@...
www.harrington.com

>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

Tyler, John, this is so exciting!

I wonder - could the steps you're discussing (converting greyscale
into sep files for CMYK printing) apply to the VM inkset as well as
the more "standard" hex sets? 

It would be a _godsend_ to be able to do away with curve files and
work on true greyscale images with more ability to tweak the drivers.
I've been really excited about the gimprint possibilities ever since I
noticed the degree of control they offer, but sadly my tech-savviness
is insufficient to really understand what all the knobs and levers do. 

If it would be at all helpful to have someone run tests on a 1280/VM
combo, I'd be delighted to volunteer :)

-Charley

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Charles Bandes <
byronbulb@y...>" <byronbulb@y...> wrote:
> Tyler, John, this is so exciting!

Somebody noticed.

> I wonder - could the steps you're discussing (converting greyscale
> into sep files for CMYK printing) apply to the VM inkset as well as
> the more "standard" hex sets?

No reason why not.
 
> It would be a _godsend_ to be able to do away with curve files and
> work on true greyscale images with more ability to tweak the drivers.

With the current state of the driver, you'd still have to convert to a 
color file and apply curves. So you're not really any farther ahead. 
Given the 100% GCR occuring in raw CMYK mode, I'd say curves for that 
inkset will be difficult. I'm not sure there would be any particular 
advantage over the Epson driver other than working and building curves 
in CMYK is more intuitive than RGB, but your file will be 1/3 larger.
The kind of work John is trying would allow assigning color inks to 
tonal values from a grayscale file, but it's way beyond me and not 
available with the standard version of the driver dummies like me would 
be using.
Tyler

> With the current state of the driver, you'd still have to convert to a 
> color file and apply curves. So you're not really any farther ahead. 
> Given the 100% GCR occuring in raw CMYK mode, I'd say curves for that 
> inkset will be difficult. I'm not sure there would be any particular 
> advantage over the Epson driver other than working and building curves 
> in CMYK is more intuitive than RGB, but your file will be 1/3 larger.
> The kind of work John is trying would allow assigning color inks to 
> tonal values from a grayscale file, but it's way beyond me and not 
> available with the standard version of the driver dummies like me would 
> be using.
> Tyler

Well, for me, being waaaaaaaaaaaaaay more of a dummy than you, it is
just really exciting to know that folks like you, John, Paul, whoever
else, have access to tools that will allow you to optimize the
workflow past what the epson driver allows. And what's better is that
the drivers are genuinely cross-platform, so maybe in time this could
be the system we're all using. 

Here's what I picture (and, bear in mind of course, that I'm good at
coming up with wishlists but darn near incompetent when it comes to
implementing this stuff.) -

An "automate" plugin/script for Photoshop which would:

Take a "final" greyscale file as source, give choices for various
inksets and tones, create appropriate separation files and output a
"ready to print" file that can go straight to the gimp drivers. 

Seems to me that this would probably work a lot like the PS "duotone"
function, which applies curves and creates separations. (Actually, I'm
wondering why we don't use that function for applying curves?) I would
expect that there would be three hard parts - 1. coming up with the
curves and seps for all different inksets 2. actual driver development
stuff to make sure the CMYK issues you were mentioning (equal parts
CMY printing with K instead) get solved 3. Figuring out how to make
sure the right channels print with the right tones (perhaps that's the
same as part 2)

I am a terrible, terrible programmer - but I have a lot of experience
in software management and I'm great at writing functional specs and
that sort of thing. If it would be helpful for the people actually
working on this stuff, I'd be very happy to work on design docs or
anything of that nature. (And of course if it won't be helpful I'll be
happy to never mention this again :) )

>--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Charles Bandes <
>byronbulb@y...>" <byronbulb@y...> wrote:
>>  Tyler, John, this is so exciting!
>
>Somebody noticed.
>
>>  I wonder - could the steps you're discussing (converting greyscale
>>  into sep files for CMYK printing) apply to the VM inkset as well as
>  > the more "standard" hex sets?

>
>>  It would be a _godsend_ to be able to do away with curve files and
>>  work on true greyscale images with more ability to tweak the drivers.
>
>With the current state of the driver, you'd still have to convert to a
>color file and apply curves. So you're not really any farther ahead.
>Given the 100% GCR occuring in raw CMYK mode, I'd say curves for that
>inkset will be difficult.

I'm using PiezoTones with Gimp, and have problems with controlling 
the K in Raw CMYK. Regular "Color" seems more amenable there, but you 
may have to boost the Y and M densities.

>  I'm not sure there would be any particular
>advantage over the Epson driver other than working and building curves
>in CMYK is more intuitive than RGB, but your file will be 1/3 larger.
>The kind of work John is trying would allow assigning color inks to
>tonal values from a grayscale file, but it's way beyond me and not
>available with the standard version of the driver dummies like me would
>be using.

That is basically what the Piezo driver does, with 4 shades. With Y 
for the highlights, M down to 50%, the only remaining "dots" are in 
the lower values. With modern, six/seven ink printers, being 
constrained to 4 ink shades seems limiting.

Real hextone inks would seem to make sense as the technology evolves. 
The MIS FS "E" is really the only option there.

Bruce



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

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Charles Bandes
<byronbulb@y...>" <byronbulb@y...> wrote:

> Here's what I picture (and, bear in mind of course, that I'm good at
> coming up with wishlists but darn near incompetent when it comes to
> implementing this stuff.) -
> 
> An "automate" plugin/script for Photoshop which would:
> 
> Take a "final" greyscale file as source, give choices for various
> inksets and tones, create appropriate separation files and output a
> "ready to print" file that can go straight to the gimp drivers. 
Actually that's what I do anyway. When the grayscale file is finalized
I have an action that does all the conversions and curves, then I just
print.
But I know what you mean and John would be the one to tell you how
possible that may be.
 
> Seems to me that this would probably work a lot like the PS "duotone"
> function, which applies curves and creates separations. (Actually, I'm
> wondering why we don't use that function for applying curves?)
In order for Photoshop to output to a printer, your custom tones and
channels have to be converted to RGB or CMYK, all your work is down
the drain. I find Photoshop's CMYK functions ideal since any sort of
ink can be utilized, and output.
Aparently there are other ways to hand off, assign inks to, and
recognize multipe channels with Gimp, but they are way under the hood,
or require extra steps between. Again John could comment, this is way
over my head.
For my knowledge level, if they can just give us true multiple channel
independant image data to print head flow, we'd be miles ahead.
Beyond that, I'm looking for software that lets me build complex
custom LUTs, and lets me apply them to images. If it did it's thing as
an image is on it's way from Photoshop to printer driver so much the
better.
I think that's the next step to get us beyond making and using these
nasty curves.
Tyler

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, Bruce Kinch
<pvx@r...> wrote:

snip
> That is basically what the Piezo driver does, with 4 shades. With Y 
> for the highlights, M down to 50%, the only remaining "dots" are in 
> the lower values. With modern, six/seven ink printers, being 
> constrained to 4 ink shades seems limiting.
Adding more inks can create more problems than it solves. I've made
workflows for Piezo, MIS, and Lyson quad sets, MIS VM's, and MIS hextones.
Of all of them the hextones were the most difficult. Much more
intricate and steeper curves are required, I saw no image quality
improvement.
However I had no access to a 6 channel driver, I think john is working
on this very thing with hexes and I don't envy him, 2 more transitions
to get right.
I still think dots are a workflow problem. I'm still very happy with a
good old "dotty" 4 ink 3000. In many ways it's the ideal quadtone printer.

> Real hextone inks would seem to make sense as the technology evolves. 
> The MIS FS "E" is really the only option there.
Of their inks, the set I have the least confidence in. After we
finished a workflow, Steve Meyer printed with them for a bit with a
7000. He could tell you more about actual print quality and longevity
than I. I know he gave up on them fairly soon.
I think Lyson has a hex set, but after several months trying to like
the hue of their quad sets, I moved away from them when the Piezo inks
came out.
But they have more users out there than this list would indicate.
Tyler

(Sorry for the delay in responding.)

On 12/18/02 8:33 AM, "Bruce Kinch" <pvx@...> wrote:

> Could commercial profile-building software do this?

Sorta.

Way, way, back in the old days (~1998), I used Horses MatchLock (now
ProfileMaker, I think) to profile MIS quadtones, and the process actually
worked fairly well.  However, since MatchLock didn't know that the inks
should be separated rather than combined, I still got fairly muddy prints as
compared with Piezography.

The other problem was that Horses eventually "fixed" some color-profiling
bugs, and broke the quadtone profiling.  (They never officially supported
it, and were more curious that I was even doing it, than interested in
working with it.)

I've talked to some color-profiling gurus, and they say that while it may be
technically possible to do grayscale profiling using ICC profiles, there
just isn't much interest in the professional world.  And the existing
measuring methods (IT8 targets, for instance) don't have enough information
to do a good job.

> 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?

The files are fairly small -- maybe 10k each in my install.  But even with a
6-color printer at 16-bit, that leaves a lot of sample points if they can
interpolate.  For a full 6-color, 16-bit LUT that has every value in it, the
files should be around 1.5mb each.

-- 
John Labovitz
johnl@...
www.johnlabovitz.com

On 12/23/02 6:38 PM, "Charles Bandes <byronbulb@...>"
<byronbulb@...> wrote:

> I wonder - could the steps you're discussing (converting greyscale
> into sep files for CMYK printing) apply to the VM inkset as well as
> the more "standard" hex sets?

I think so.

Can you describe a VM workflow?  I'm curious how the (two?) inks are mixed
in.  I presume they're added in a density relative to the overall gray tone
-- that is, if you're printing a 20% gray, you get an equivalent 20% of the
toning inks.

I could see a bare-bones way of profiling VM inksets, whereby you mix the
toning inks ahead of time, and print stepwedges with those tones already
added to the neutral gray inks.  The stuff I'm working on measures densities
only, not colors, so it shouldn't care what tone you use.

There are probably better ways that are more flexible, but I can't get my
head around them at the moment.

> I've been really excited about the gimprint possibilities ever since I
> noticed the degree of control they offer, but sadly my tech-savviness
> is insufficient to really understand what all the knobs and levers do.

...and unfortunately many of the knobs and levers, at least for quad/hextone
work, are gummed up by invisible machines under the hood.  This is why I'm
trying to hook in more directly to the gimp-print driver, albeit at a
sacrifice (right now) to the user-interface of Photoshop.  In other words,
you can't just say "Print." :)

> If it would be at all helpful to have someone run tests on a 1280/VM
> combo, I'd be delighted to volunteer :)

Cool!

-- 
John Labovitz
johnl@...
www.johnlabovitz.com

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, John Labovitz <
johnl@j...> wrote:
snip
> Way, way, back in the old days (~1998), I used Horses MatchLock (now
> ProfileMaker, I think) to profile MIS quadtones, and the process
actually
> worked fairly well.  However, since MatchLock didn't know that the
...
> The other problem was that Horses eventually "fixed" some
color-profiling
...
Actually Profiler Pro still works for quads, and the the
GretagMacbeth 
software worked well for a test CMYK profile. RGB profiles I've made 
work well for characterization, Profiler Pro CMYK profiles were less 
successful because K generation, total ink, and UCR/GCR issues 
important to normal CMYK profiles are relevant to quads in somewhat 
unrelated ways.
Any of these profiles are only useful for preview, or providing 
valuable characterization information used for developing curves.
THey cannot be used to print through because color management 
presupposes a desired end result of best possible color output given 
the nature of the device.
We have different rules, light tones to light inks, etc.. Nonetheless 
profiles can be invaluable when developing workflows. For example,
all 
of the 1280 VM curves I made for Martin were done with the help of a 
profile.

> I've talked to some color-profiling gurus, and they say that while
it may be
> technically possible to do grayscale profiling using ICC profiles,
there
> just isn't much interest in the professional world.  And the
existing
> measuring methods (IT8 targets, for instance) don't have enough
information
> to do a good job.
Actually Icctools will do it, but I haven't tried it. However they
are 
grayscale profiles, and again not savvy to the desired end result.
It's 
possible to imagine it's usefulness though.
You are quite right about "enough info", however some profiling 
software allows you to design your own measurement chart, so you
could 
get sample your specific areas of interest.

> interpolate.  For a full 6-color, 16-bit LUT that has every value
in it, the
> files should be around 1.5mb each.
Still very interested in software a Mac dummie could use for making
my 
own LUTs.
Tyler

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, John Labovitz <
johnl@j...> wrote:
> On 12/23/02 6:38 PM, "Charles Bandes <byronbulb@y...>"
> <byronbulb@y...> wrote:
> 
> > I wonder - could the steps you're discussing (converting greyscale
> > into sep files for CMYK printing) apply to the VM inkset as well as
> > the more "standard" hex sets?
> 
> I think so.

You bet.
 
> Can you describe a VM workflow?

Someone else can take that.
Tyler

> Can you describe a VM workflow?  I'm curious how the (two?) inks are
mixed
> in.  I presume they're added in a density relative to the overall
gray tone
> -- that is, if you're printing a 20% gray, you get an equivalent 20%
of the
> toning inks.

Keep in mind that I don't know what I'm talking about.

But here's how I _think_ the VM inks work.

6 inks - I am taking wild guesses at the %% here, please assume they
are incorrect. You get Black (100%) Neutral Grey (75%) Blue-grey (35%)
Pale Blue-grey (12%), Warm-grey (35%), pale warm-grey (12%) 

It seems to me that what happens is basically that the printer has two
complete quadtone sets - a warm and cool set, and that it mixes equal
parts of cool and warm to make neutral for the neutral set. All of the
mixing takes place via the curve sets. So, for instance, the warm
curve sets give a false-color that is very green, because they don't
wnat to use _any_ of the magenta ink, which has the cool tones in it.
Similarly the cool curves are very red, to avoid the cyan inks, and
the neutral curves are rather purple since they have both.

Um, does that more or less answer your question? I realize that the
explanation is technically inept, but hopefully a reasonable try from
a layman's pov?

> -- 
> John Labovitz
> johnl@j...
> www.johnlabovitz.com

On 12/24/02 10:47 AM, "Charles Bandes <byronbulb@...>"
<byronbulb@...> wrote:

> Here's what I picture (and, bear in mind of course, that I'm good at
> coming up with wishlists but darn near incompetent when it comes to
> implementing this stuff.) -

Vision is usually more important than the details anyway, as long as it's
eventually implemented. ;)

> An "automate" plugin/script for Photoshop which would:

Unfortunately, writing a Photoshop plugin requires both becoming an official
developer, which costs $200, *and* getting approved from Adobe, as well as
(I'm sure) signing a non-disclosure agreement.  They claim they're looking
into how to open the SDK to nonprofit (eg, open-source) groups.

Scripting Photoshop, however, is documented, and might do the trick.

> Take a "final" greyscale file as source, give choices for various
> inksets and tones, create appropriate separation files and output a
> "ready to print" file that can go straight to the gimp drivers.

Yes.  Even better, it doesn't have to even output a file -- there's a
library included with gimp-print that can be accessed directly by a program,
which can do all the printer setup and tell gimp-print to print whatever
data it needs to.

My stuff isn't using this yet -- it's instead feeding image data to a
"testpattern" program that comes with gimp-print that outputs raw color data
to the printer.

> Seems to me that this would probably work a lot like the PS "duotone"
> function, which applies curves and creates separations. (Actually, I'm
> wondering why we don't use that function for applying curves?)

You can use this, if you're only using 4 inks.  I think I did some early
separations using Duotones, then converted to CMYK and output through Adobe
PressReady.

> I would
> expect that there would be three hard parts - 1. coming up with the
> curves and seps for all different inksets

I've already used Piezography. ;)

Instead, what I'm writing is basically a multitone grayscale profiling
package.  Briefly, it prints stepwedges for each ink, analyzes those
stepwedges (after you scan them), and generates "curves" (really sample
points with interpolation).  The code recognizes which inks are lighter or
darker (at maximum "black" for each one), and tries to be smart about which
ink is used for which value (ie, not getting down into the lighter areas of
a given ink, so as to avoid seeing dither dots).

Right now I'm doing "hard" separations, where only one ink is being used for
any given tone.  I know that a common way of doing this by hand is to fade
one ink down and another one up to transition them.  I just haven't gotten
far enough to see how that will affect things.

> 2. actual driver development
> stuff to make sure the CMYK issues you were mentioning (equal parts
> CMY printing with K instead) get solved

Feeding raw data into gimp-print (which can't be done directly using
Photoshop) definitely avoids these issues -- I've already tested, and Tyler
has verified.

> 3. Figuring out how to make
> sure the right channels print with the right tones (perhaps that's the
> same as part 2)

This comes for free. ;)  Imagine a grayscale Photoshop file that you convert
to a Multichannel image.  Now duplicate the channel four times (or six, for
hextone).  Add curves to separate the gray tones into the multiple channels.
Now send to gimp-print (through some filter program).  Each channel will
correspond to a given ink.  The skeleton for controlling each ink is already
there; it just takes glue (to mix metaphors) to hook all this together and
make it useful.

> If it would be helpful for the people actually
> working on this stuff, I'd be very happy to work on design docs or
> anything of that nature.

Great!  We should talk more off-list.

-- 
John Labovitz
johnl@...
www.johnlabovitz.com

On 12/25/02 10:22 AM, "Charles Bandes <byronbulb@...>"
<byronbulb@...> wrote:

> 6 inks - I am taking wild guesses at the %% here, please assume they
> are incorrect. You get Black (100%) Neutral Grey (75%) Blue-grey (35%)
> Pale Blue-grey (12%), Warm-grey (35%), pale warm-grey (12%)
> 
> It seems to me that what happens is basically that the printer has two
> complete quadtone sets - a warm and cool set, and that it mixes equal
> parts of cool and warm to make neutral for the neutral set

Huh.  That's totally different than I was assuming, which is okay.

So do you VM-using folks choose one of warm/cool/neutral?  Or does it work
well enough to be able to mix a slightly-cool versus a really-cool?

-- 
John Labovitz
johnl@...
www.johnlabovitz.com

Well, um, keep in mind that I could be totally totally wrong.

Yes - there are curve sets for warm, medium-warm, neutral,
medium-cool, cool

How that happens is beyond me.

But basically the way it works at a user level is like so:

I do all the work on the file first, usually in 24-bit RGB mode so I
can use adjustment layers. I then choose a curves layer and select the
appropriate curve for the tone I want for the particular image
(choosing from the five above options) 

> Huh.  That's totally different than I was assuming, which is okay.
> 
> So do you VM-using folks choose one of warm/cool/neutral?  Or does
it work

> well enough to be able to mix a slightly-cool versus a really-cool?
> 
> -- 
> John Labovitz
> johnl@j...
> www.johnlabovitz.com

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, John 
Labovitz <johnl@j...> wrote:
> On 12/25/02 10:22 AM, "Charles Bandes <byronbulb@y...>"
> <byronbulb@y...> wrote:
> 
> > 6 inks - I am taking wild guesses at the %% here, please 
assume they
> > are incorrect. You get Black (100%) Neutral Grey (75%) 
Blue-grey (35%)
> > Pale Blue-grey (12%), Warm-grey (35%), pale warm-grey 
(12%)
> > 
> > It seems to me that what happens is basically that the printer 
has two
> > complete quadtone sets - a warm and cool set, and that it 
mixes equal
> > parts of cool and warm to make neutral for the neutral set
> 
> Huh.  That's totally different than I was assuming, which is 
okay.
> 
> So do you VM-using folks choose one of warm/cool/neutral?  
Or does it work
> well enough to be able to mix a slightly-cool versus a 
really-cool?
> 
> -- 
> John Labovitz
> johnl@j...
> www.johnlabovitz.com

I've been using the VM inks for a while so maybe I can shed
some light on the basic idea and how they are used.

I think its easiest to understand the 4 ink printers first.  The
original VM inks are a black, a warm dark gray , a warm
light gray, and a blue toner  -- these are in the K,C,M,Y ink
positions respectively.  The basic concept is to use the
3 grays (includes black) in a partitioned set to get the whole
spectrum of grays.    The steps of gray are quite warm,  and
this would be the "warm curves".    Then to make cooler
steps small amounts of the blue toner are added in to
neutralize the warm tone.  In concept its simple but there are
a couple of complications that make the curves difficult to
design.  First is that adding blue toner also adds density so
more toner also requires reduced gray to conpensate.
Second, the real difficulty is that control of the black ink is totally
by GCR (gray color replacement).  The driver has a builtin
algorithm to replace high density C,M,Y combinations with
black ink.  Its basically a trial and error effort to see how each
printer's driver does this.

There is now another VM ink set called VM-Sepia.  Its a 
similar idea but the gray inks are neutral (or slightly cold)
grays and the toner color is sepia.  This reverses which
curves give which result.  No-toner is a cold tone print
whereas lots-of-toner gives a warm sepia print.  

I think for the most part people just pick one curve for a
print rather than trying to blend a combination.   The GCR
for each curve is likely not compatible.

---------

The 6 ink printers are based on the same concept as the
4 ink printers.   The epson drivers all have a builtin idea
of 2 pairs of inks i.e. C and light c, and M and light m.   They
are automatically assumed to have a fixed density difference
and the driver will automatically transition from the light
one to the dark one.   For the 4 ink printers Y is used for
the toner, but this would result in 5 grays and 1 toner.  So for
the 6 ink printers it was decided to use  M and m for the
toner and KCcY for 4 grays.   This makes the curves look very
different but its just a color difference -- still the same concept.
The 6 ink printer curves are created in the same way but
with so many builtin transitions (Cc, Mm, and GCR) there
can be some very steep looking curves.
 
----------

The main beauty of using gimp-print (when the full 6 color
control works) will be avoiding the builtin transitions and
controlling them best for multi-gray inks instead of the
control that was designed for colors.

Roy Harrington
www.harrington.com

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Charles Bandes <
...
> An "automate" plugin/script for Photoshop which would:
> 
> Take a "final" greyscale file as source, give choices for various
> inksets and tones, create appropriate separation files and output a
> "ready to print" file that can go straight to the gimp drivers.

By the way, this is color management. As Dan Culbertson handily 
instructed years ago, custom CMYK profiles can be generated and sep 
curves edited into 
them. You can print through them, I've done it.
It's exactly what you're talking about, works on the fly, technology 
already implemented into Photoshop and any other CM savvy app.

Epson driver RGB methods, CMYK methods, creative use of color 
management for quads, except for a few inks, papers and tools, there is 
nothing new under 
the quad sun since Dan and most of his work was done years ago. Most of 
us are using methods he either "also" did, did better, or did first, 
and generously 
made available to all.
I guess when you reach a certain point it's not suprising that 
advancement slows, what is suprising is that most of the community 
haven't even caught up to 
him. The accumulated knowledge seems to evaporate, or be appropriated 
and made obscure by those who wish to sell it back to us.
"Dan Dan The Quadtone Man"
You should all know who he is.
A little end of year nostalgia I guess.
Tyler