Demystifying the Mitsubishi CP-D70DW/D707DW/K60DW
In recent weeks, I've had folks with access to Mitsubishi's CP-D70DW and
CP-K60DW-S photo printers pop up and offer to help figure out what it
would take to get Gutenprint to properly support them.
In short order, I managed to fix the backend/spooler for the CP-D70x
series, but the CP-K60 is still elusive -- I'm going to need USB sniffs
of the Windows drivers doing their thing to figure out just what I need
to tweak. Hopefully this contact will be able to do that for me.
But in both cases, the USB sniffs are only part of the problem. It
turns out my original reverse-enginnering of the spool file format was
Oh, the structure of the files is reasonably well understood now;
there's two 512-byte headers present, followed by three (or four, if
matte lamination is enabled) planes of 16-bit Y/M/C data.
Once the backend was working properly with the D70, the reports were
that gutenprint's output was way too dark, which indidated that the
color data needed to be gamma-corrected or otherwise have some sort of
Naturally, reality turned out to be a lot messier. I whipped up a simple
program to analyze the raw spool files in an initial attempt to get a
baseline for the correction curves.. and that's where things got quite
My test jobs were all generated by Windows; indeed it's the standard
Windows XP printer test page. There are a total of six colors present
in the image; black, white, and the four colored panes of the windows
logo. Straightforward, right?
The D70x test jobs had about 38,000 unique color values in each plane.
The K60 had nearly 58,000. Out of 65,536 possible values. In other
words, they're doing some sort of contiunuous tone smoothing, and
there's no nice, neat mapping from input RGB values to what the printer
spits out -- Not even for "black" and "white". WTF? How am I supposed
to proceed from here? Start disassembling the Windows driver?
So at this point, it's not looking likely I'm going to be able to figure
this out without spending a lot of soul-sucking time
reverse-enginnering x86 assembly. I have better things to do, unless
someone wants to pay me more money than this is worth.
One fun tidbit is that Mitsubishi's current photo kiosks run Linux, and
as such they've already written native Linux drivers for these things.
In the mean time, if you want a kiosk-scale photo printer that works
great with Linux, DNP/Citizen and Shinko/Sinfonia all make models that
have first-class support, and the older Kodak 6800/6850/605 and
Sony UP-DR150/DR200 models also work decently well.
Meanwhile, Mitsubishi, feel free to toss some documentation (and a
printer or three) my way. It'll only help you sell more printers!
Syndicated 2014-08-24 12:03:28 from Solomon Peachy