1 Mar 2002 rlk   » (Journeyer)

Thanks for the code drop, raph. I've forwarded it along.

Tandem screening is something we've been talking about, and taking occasional stabs at, for quite a while. We haven't managed to get it right, though, and this sounds like it might be just what we're looking for.

My thought at this point is that we should tune ETS, or better yet EBS, to be our high end, "quality at all costs" dither algorithm. Therefore, I would accept a significant speed penalty for its use, and we'll probably turn on all of the quality options. With contemporary commodity processors being in the 1+ GHz range, there shouldn't be any problem for desktop users.

For general high quality, Adaptive Hybrid already works very well, and there's no good reason to get rid of it. It has a lot of history behind it, and there's no substitute for experience. It's also reasonably fast; I think a 200-300 MHz CPU should be able to keep up with the printer speed.

Color management is something I've done some thinking about. The problem with all of the solutions I'm aware of is that they're CMYK-based. For four color, single dot size printers that's fine, but most high end printers are six color and/or variable drop size. If the drop sizes and relative densities aren't correctly tuned -- and that's what I think Raph was seeing with the inconsistency between 1440x720 and 720x720 -- no photometric correction method based on a relatively small sampling of points can correct the errors.

From an implementation standpoint, we can do at least as well as anyone else by utilizing the 16-bit raw CMYK input. This bypasses all internal color management, and simply requires the image source to supply 16 bits per channel. The logical extension from this is to have a printer input space (1 channel per printer output channel). Beyond this, we'd have to look at how to represent the dot sizes. Tuning dot sizes on variable drop printers is actually rather tricky.

6-color transitions are indeed a very important part of modern inkjet printing, and it's something I believe a lot of people have had difficulty with. It wasn't until quite late in the 4.1 development cycle that we figured out what needed to be done. Essentially, what we did was to screen the dark dots within the composite channel using the same algorithm -- and indeed the very same blue noise mask -- that we use to decide whether to print dots at all. This was not a trivial insight; for a long time I thought that using the same mask (without shifting it to decorrelate dot selection from ink selection) would result in something like a quadratic curve in the transition zone. It was when I figured out how to correct for this that it was possible to get a really smooth transition.

I initially thought that the ETS was improving the smoothness through use of less dark ink. We've been having a lot of internal discussion on this; there is some fear that we're not using enough dark ink. But when I looked at it more closely, that wasn't the case at all. I can adjust the transition zones even with adaptive hybrid, and this didn't help at all. The problem is, just as Raph hypothesized, that the blue noise screen isn't as smooth as ETS. In fact, with ETS the transition is a bit more visible due to the overall greater smoothness, but I still need a fairly strong loupe to see what's actually happening.

Anyway, it looks as though 4.2.1 will contain an IJS driver, so we can finally solve the problem of building Gimp-print into Ghostscript. I'm actually quite pleased it's taken this long for 4.2.1 to come out; it's an indication that we did a much better QA job on 4.2 than we did on 4.0. It took us five releases of 4.0 to get things stable; 4.0.4 was the first 4.0 release that didn't have any stoppers. There really haven't been any critical bugs in 4.2 that have necessitated a fast update, so we can go ahead working on development and back port things into 4.2 as desired. Of course, the downside of the relative maturity is that things are happening more slowly.

I don't know yet exactly what we'll do with EBS, but it sounds like it does a lot of the things that we've been thinking about for a while.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!