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 lacking.
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 curve applied.
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 wonky.
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!