Older blog entries for Pizza (starting at number 156)

Further adventures with printers: The Citizen CW-01

A few days ago, someone with a Citizen CW-01 popped up on the Gutenprint mailing list. Due to its lineage, I'd assumed it (and its bretheren, the OP900) was related to the newer CW and CY families, and would work with the DS40 backend once the USB PID was known.

It turns out that the printer operates at 334dpi natively, so some additional work was needed. I'm not sure how I'd missed that. So, after some decoding of the WinXP print jobs, I discover the spool format is quite simple, and looks nothing like the newer CX/CY series.

So I ask the user to obtain some sniffs of the printer comms, and he delivered two dumps that look quite similar to the CX/CY, differing only in a couple of parameters.

So, it was pretty easy to whip up a new backend. It's out for testing now, and with luck, in a few days I'll be able to declare the CW-01 as officially supported by Gutenprint, so it'll work under Linux.

It'll be a bit more work to figure out how much of the CX/CY's status/info command set works with the CW-01, and I suspect the 600dpi support needs some more work, but for now, it's out of my hands.

In other news, another Mitsubishi CP-D70DW user popped up, sent me some detailed sniffs, and let me remote into his system for some interactive debugging; many, many bugfixes to the backend later, and it seems to be handle everything I know how to throw at it. With luck it'll also fix the CP-K60DW functionality as well.

Unfortunately, the CP-D70/D707/K60 employ a seriously screwy nonlinear tone curve/smoothing approach that I haven't been able to model, so Gutenprint's output is pretty lousy. Such is the fate of reverse-engineering efforts..

Syndicated 2014-10-07 03:13:17 from Solomon Peachy

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!

Syndicated 2014-08-24 12:03:28 from Solomon Peachy

More on the Kodak 6850

The venerable Kodak 6800 and 6850 printers are true workhorses; it's not uncommon to see them flogged on eBay with upwards of 200,000 prints on them -- not because they are worn out, but because they tend to outlast the systems they're plugged into.

I originally added support for these models to Gutenprint the better part of two years ago, and through some helpful volunteers, I was able to reverse-engineer enough of the printer communications to write an open-source CUPS backend to enable them to print under Linux.

That seemed to be good enough, and I generally forgot about these models.. until a few months ago, when the folks over at LiveLink arranged to have an Kodak 6850 sent my way. (These guys are awesome, BTW!)

Having full access to one of these things made it far easier to poke and prod and generally reverse-engineer the printer communications.
Consequently, I've mostly decoded the printer media status (now with print counts!) and media query messages, and greatly improved error detection and recovery.

It's probably safe to say it now works better under Linux than it ever did with the Official Windows/OSX drivers, though without access to a 5x7 conversion kit and media I'm sure there's something I've missed.

In other news, I'm still hunting down some bugs involving the Sony UP-DR200, Canon CP900, and Mitsubishi CP-D70/CP-K60 models, but with only indirect access progress is slow.

It would be so much easier if the manufacturers of these things could toss some documentation my way. It could only help them sell more printers and media, after all..

Back to the bit mines..

Syndicated 2014-07-11 18:56:40 from Solomon Peachy

Canon CP820 and CP910, Redux

It seems my early enthusiasm was a little misplaced, as "some degree of driver-side color management/mapping" became considerably more involved than I'd first expected.

It turns out that rather than the subtractive Cyan/Magenta/Yellow primary data sent to the earlier CP-series printers, or even the additive Red/Green/Blue primary data used by many others, The CP820 and CP910 expect their data in a perceptual, Luminance-based format, not unlike what one finds in television and video formats.

My best guess is that the printers use the JPEG YCbCr444 format and coefficients (as opposed to the ITU-R BT.601, BT.709, or BT.2020, or various YUV colorspaces). Conversion between these colorspaces is fairly straightforward. Here's the code for the JPEG transformations:

  /* All values are in the range of 0-255 */

Y  = R *  0.29900 + G *  0.58700 + B *  0.11400
Cb = R * -0.16874 + G * -0.33126 + B *  0.50000 + 128
Cr = R *  0.50000 + G * -0.41869 + B * -0.08131 + 128

R  = Y +                       + (Cr - 128) *  1.40200
G  = Y + (Cb - 128) * -0.34414 + (Cr - 128) * -0.71414
B  = Y + (Cb - 128) *  1.77200

Unfortunately, due to Gutenprint's internals and the fact that the printer expects the YCbCr data in a plane-interleaved format, this will be a little more invasive to implement. Consequently, it will likely not land in Gutenprint until after the 5.2.10 release.

In other photo printer news:

  • Multi-cut support for selected printers is in the works
  • Support for the Sony UP-CR10L (and DNP DS-SL10) is in the works
  • Improved Kodak 6800/6850 status reporting
  • I'm awaiting sniffs from Mitsubishi CP-K60DW-S and CP-D9550DW-S printers, which should lead to improved support
  • The Mitsubishi CP-D70W is confirmed to work, but apparently needs major color curve tweaking

As always, the best way to improve a printer's support is to send one my way, preferably accompanied by programmer documentation. :)

Syndicated 2014-05-08 13:57:00 from Solomon Peachy

Canon SELPHY CP910 and CP820

For more than a decade, Canon's SELPHY printers have been largely evolutionary. While their bolt-on features have steadily improved (in-printer touchup, better screens, UIs, etc) the core printer engine itself has remained nearly unchanged from the outset. This is most visible when you consider they've used the same media packs the whole time.

The outlier here was the SELPHY ES series; they used different, all-in-one media packs to improve printer handling, but putting aside the physical differences, under the hood it was the same basic print engine, supporting the same print dimensions. Also unique to the ES series were a few minor variations in the printer spool data format, but with the exception of the CP790, the CP series has remained completely compatible for the entire life of the family.

Until the CP820 and CP910, that is. These two use an entirely new print data format (different headers, and RGB instead of CMY data) and despite using the same CP-series media, also sport a slightly different print engine that runs at a slightly higher resolution than the older models.

Another major change is that the CP820 and CP910 break from tradition and no longer need a special driver/backend to interactively send data over; now the whole thing is just dumped over in one big blob. This was an unexpected (and welcome!) change.

Unfortunately it looks like the printers still need some degree of driver-side color management/mapping; figuring that out is going to be tricky. Still, with luck, these printers will be supported in Gutenprint 5.2.10.

Syndicated 2014-05-07 12:47:56 from Solomon Peachy

Yet more Dyesub printer hacking

Over the past month, there's been a push to get the Gutenprint codebase in shape for the long-overdue 5.2.10 release. This will be the first release incorporating the various CUPS backends I've written plus an expanded supported printer list.

This has resulted in a flury of bugfixes and improvements to the backends, including:

  • Support for multi-page print jobs
  • Sony UP-DR200 support
  • Canon SELPHY CP790 support
  • Vastly improved error detection and recovery for all Canon SELPHY models.
  • Printjob pipelining support for the DNP DS40/DS80
  • Support for the Citizen CX/CX-W/CY printers

The Citizen printer support deserves its own set of comments. It turns out that the DNP DS40/DS80/DSRX1 models are just rebadged Citizen CX/CX-W/CY models (down to the same USB IDs!) and they all use an indentical command language.

There are more Citizen models (CW-01, CW-02, OP900, OP900II) that have been rebadged by others too, and every single one of these supposedly supports the same command language as the CX/CX-W family. Most notably, Mitsubishi's CP3800 appears to be a rebadged CX-W.

I like it when things JustWork(tm)! Unfortunately, since I don't know the USB IDs for that second list of printers, I can't add them to the backend match list.

My interest in adding more printers to Gutenprint for the sake of it has waned somewhat, for several reasons -- First, my personal and professional printing needs are now well-met. Second, I have less free time to devote to such things. And finally, the norm for these dye-sublimation photo printers seems to be to require an intelligent backend, and I can't begin to write one without access to the particular printer.

The Mitsubishi CP3800, CP9550, and CP3020 series haven't been tested.
The CP-D70/D707/K60 models are known to need a backend (and it's written!) but my original tester disappeared. (I've also started reverse-engineering the CP9600 spool file format, but that's on hold until after tax season..)

The Kodak 9810 and 8500 (itself a rebadged CP3020) also remain untested.

So, if anyone out there has access to one of these printers and is interested in helping improve their Linux support, speak up!

Similarly, if there's some other dye-sublimation photo printer you'd like to see working under Linux, we can probably help each other out.
The recent Citizen/DNP and Shinko/Sinfonia additions/suppport were the result of such collaborations.

Syndicated 2014-02-07 15:00:10 from Solomon Peachy

A little Photo Organizer love

The software that powers my photo archive (aptly named Photo Organizer) hasn't seen much attention in the past few years or so. That's mostly because it does what I need with little fuss, and the other users either don't exist any more or are satisfied with what it is.

The other reason it hasn't seen much attention is that there's so much tecnhical debt in that codebase that all of the substantial feaures I have on my eventual to-do list require some major plumbing work.

So, the result is that in the past three or so years, development's slowed to a trickle of bugfixes. The notable exceptions are addition of a few more esoteric image formats, and updating the default themes to take advantage of now-common CSS3 constructs. Not exactly earth-shattering!

Last night, I finally sat down and added a major new feature, a (read-only) JSON-RPC interface that exposes the same sorts of information as the RSS feed generator.

My primary goal is to enable gnome-photos to directly interface with Photo Organizer, but this JSON-RPC interface will enable many more things. Unfortunately the data exported through the RPC API is far from complete, but I only see that improving as I figure out what to do with this thing.

Syndicated 2014-02-07 14:07:59 from Solomon Peachy

DNP DS40 and DS80

I've spent several evenings over the past week improving Gutenprint's support for the DNP DS40 and DS80 dye-sublimation printers. Aside from their respective 6" and 8" print widths, they are otherwise identical feature-wise. Here's what's been added so far:

  • An intelligent CUPS backend that lets us pipeline print jobs in a status-aware manner, plus query printer information
  • Support 5x7 and 3.5x5" print sizes on the DS40
  • Matte lamination support
  • Better margin specifications
  • Support for the 300x600 "high-quality" print mode

Next up will be to add sane multi-cut print modes (for example, obtaining 3* 8x4" prints cut from a single 8x12 sheet). This is considerably more challenging as Gutenprint doesn't really support this sort of thing.

I should ask around at the office if anyone wants some prints made; if I'm going to generate a pile of test prints I might as well generate ones worth keeping. :)

Syndicated 2013-12-19 03:14:18 from Solomon Peachy

Mitsubishi CP-K60DW-S

Recently Mitsubishi announced their CP-K60DW-S photo printer. Outwardly it is identical to their existing CP-D70DW, except for the use of red labels instead of grey. Beyond that, it appears to be functionally equivalent (even uses the same media) to the CP-D70 series, although not as fast.

This morning I dug into the spool file format the CP-K60DW uses. It's almost identical, though different enough to be annoying. Most of the changes had to do with print sizes; they're all slightly different, and there's support for 6x6 prints (but not the 6x9 the CP-D70x supports)

Some judicious decoding later, and Gutenprint now theoretically supports the CP-K60DW-S. Of course, lacking access to one of these printers I have no way of testing this, and can only hope its command stream is identical.

In the process I discovered and fixed a couple of bugs relating to command padding on the the CP-D70 series. Anyone out there with access to any of these printers (Mitsubishi CP-D70DW, CP-D707DW, CP-K60DW-S) that's willing to help me out?

Syndicated 2013-11-24 16:08:06 from Solomon Peachy

Kodak 605 works!

The Kodak 605 Photo Printer is their replacement for their earlier 68x0 series. And, true to form, it's incompatible with everything that came before.

Last night, I commited a backend for the Kodak 605 photo printer. Tonight, the last of the known bugs were fixed, and it appears to work!

Yay, that just leaves most of the Mitsubishi models (CP3020D/DA, CP-D70/707, CP-D9550/9600) that need testing/validating, plus whatever else comes along in the mean time.

Syndicated 2013-11-24 03:17:18 from Solomon Peachy

147 older 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!