Older blog entries for Pizza (starting at number 161)

Progress on the Shinko S1245, S6145, and S6245

A few weeks ago, a kind gentleman at Sinfonia sent me a pile of documentation on their S1245, S6145, and S6245 printers.

The S6145 and S6245 use a similar command language to the S2145, but the S1245 is quite different. So I decided to start with the latter, and created a new backend for it. It's now complete, but needs testing.

Support for the S6245 will probably follow, likely added into the existing S2145 backend as most of their code will be shared.

Unfortunately, the S6145 is another matter. While its command language is quite similar to the S2145, it has some peculiar data format requirements.

While the spool data is packed 8-bit RGB, the printer driver (aka our backend) is expected to convert it to 16-bit planar YMC+L data. That is easy enough to accomplish, except the data also needs to be massaged via an unknown algorithm combined with an opaque data blob that the printer supplies.

If this sounds familiar, it's because that sounds eerily similar to what the Mitsubishi K60/D70/D707/D80 printers require, complete with a file providing the raw lamination data and pile of tabular data that feeds into the transformation algorithm. This is strong evidence that the S6145, the CIAAT Brava 21, Kodak 305, and those Mitsubishi models all use the same basic print engine.

The Sinfonia rep wasn't able to provide any further details on the algorithm, though he did provide a set of binary x86 and x86_64 libraries that perform the necessary transformations. So it's a sort of bad news, good news situation.

Anyway. At this point, the S1245 backend is ready for testing, and since I can't justify buying yet another high-end photo printer, that means I'll need a volunteer to test this stuff out.

In the mean time, I'll probably work on support for the S6245, which will also eventually need testing. Then I'll move on to the S6145, get the core backend in place, then teach myself some x86_64 assembly and get to reverse-engineering the necessary algoritms and maybe eventually get somewhere.

So, does anyone have a spare S1245, S6245, and/or S6145 printer to toss my way? It's for a good cause!

Syndicated 2015-02-18 04:17:51 from Solomon Peachy

The current state of the Mitsubishi CP-D70DW, CP-D707DW, CP-K60DW-S, and CP-D80DW printers under Linux

The problem:

Over the last month or so, I've received on average two questions a week about these printers, mostly along the same lines of "I can't print with them, help!"

The short answer

They don't work with Linux, and this isn't likely to change anytime soon.

The longer answer

With the Mitsubishi CP-D70 and D707, If you use the Gutenprint 5.2.11-cvs code later than August 14, and the backend code from at least October 4, you will be able to successfully generate prints. The CP-K60 still won't print at all due to incomplete knowledge about printer backend protocol, and I have not seen what changes the CP-D80 incorporates.

Unfortunately, while the CP-D70 and D707 are able to successfully print, the output is all screwed up. The Windows drivers perform non-linear color scaling that requires gamma correction; this is annoying but would be straightforward to figure out, except the drivers are also doing some sort dithering.

How bad is this dithering? A test job with six nominal colors results in a printjob that contains over 18,000 (16-bit) color values. Even a simple "print a page with a single, pure color" job results in dozens (if not hundreds) of colors as the driver adjusts the intensity according to some unknown algorithm.

The pithy answer

Mitsubishi actually wrote Linux drivers for all of these (and other!) printers, but only provides them as part of their Kiosk solutions, not for normal end-users. So, don't reward manufacturers that snub Linux users, and support those who do.

The alternative answer

There are many competitive alternatives (both price-wise and performance-wise) which have solid support under Linux. In particular, here's what I'd recommend if you want a kiosk-class, workhorse photo printer:

  • DNP DS40, RX1, or DS80
  • Citizen CX, CX-W, or CY
  • Shinko S2145 / Sinfonia S2
  • Kodak 6800, 6850, or 605
  • Sony UP-DR150 or UP-DR200

Several other models from these manufacturers should (in theory) work okay, but the above represents a known-good list. Note the utter lack of any Mitsubishi models; as of this writing, none of their printers play well with Linux.

The pleading answer

In case anyone over at Mitsubishi is reading this, how about tossing me some documentation and a printer or three to play with? Proper Linux support will only help you sell more printers!

Syndicated 2014-11-22 13:35:03 from Solomon Peachy

30 Oct 2014 (updated 22 Nov 2014 at 14:13 UTC) »

Further printer work

Okay, so I guess I was wrong about additional printer hacking. Despite the 12-hour days at the office over the past few weeks (we got our first silicon back, and software is the ring that binds everything together in the darkness), I'm still spending time writing code when I get home.

First, I added support for the Sony UP-CR10L and its rebadged bretheren, the DNP SL10. I've had these on my to-do list for a while; I'd already decoded everything and updated the existing UP-DR150/200 backend to handle the new bits, but never got around to adding proper support into Gutenprint. That's now done, and once I get the USB PIDs, it should JustWork(tm).

Beyond that, I've knocked out a few things on the bug list. One I just fixed affected pipelined printingon the DNP/Citizen printers, and it was most easily triggered by multi-page print jobs. With Gutenprint 5.2.10's backend, the printer would just abort the job after the first page, but if you were using a development snapshot after 2014-06-04, it would automatically retry the job, resulting in an endless printing of page 1 over and over again.

The bug was due to the backend mistakenly treating the "Printing, with one available buffer for a 300dpi or small 600dpi job" status as an error.

...Oops.

At least folks won't have to wait for the next Gutenprint release to pick up the latest backend code.

I have a rather large photo backlog from the past month to sort through. That will be my weekend project..

Syndicated 2014-10-30 02:38:37 (Updated 2014-11-22 14:13:15) from Solomon Peachy

Shinko/Sinfonia printers

I just committed initial support for the Shinko/Sinfonia CHC-S1245, CHS-S6145, and CHC-S6245 into Gutenprint. They use printjob structures similar to the S2145, and appear to share the same basic driver core, so the odds are high that the existing S2145 backend will work with only minor changes.

So, if there's anyone out there with one of those models (or better yet, some low-level documentation on their communication protocol) drop me a note, and from there we should be able to get things working pretty quickly.

There's still the CHC-S8145 and the DP-1045 to sort out, but those are for another time.

I think that's it for printer hacking for a while, barring bugfixes and the ongoing Mitsubishi CP-D70/D707/K60 saga. Testers needed...

Syndicated 2014-10-20 03:49:50 from Solomon Peachy

More dyesub printer work

The Citizen CW-01 is now confirmed working, and the necessary code has been committed into Gutenprint. With luck, the next release will take less than two years! This should also work with the Olmec OP-900, but I'll need a USB ID in order to add that to the backend.

Meanwhile, I just committed initial support for the Kodak 305 and Kodak 8810 printers to Gutenprint. It's unknown if they need an intelligent backend, but I suppose time will tell. As always, testers welcome.

Here's my current to-do list:

  • Kodak 8800, 7000/7010/7015, and D4000
  • Mitsubishi CP-D80DW and CP-9600DW
  • Shinko S1245, S6145/S6145-5A, S5245, S8145, and DP-1045
  • Sony UP-CR10L and UP-CR20L (aka DNP SL-10 and SL-20)

These models need USB IDs:

  • Citizen CW-02, OP900, OP900-II
  • Mitsubishi CP-3800DW

These models need testing:

  • Mitsubishi CP-3020D/DA/DE/DAE, CP-9550D/DW, and CP-9810D/DW
  • Kodak 8500, 9180, 8810, and 305

I've received inquires about various HiTi models, but without access to the printers (or at least complete USB sniffs of print generation with specific settings logged) I won't be able to make any progress. Their windows spool format is some sort of (compressed!) intermediate language rather than something that's natively dumped to the printer.

Finally, the Mitsubishi CP-D70/D707/K60 remain problematic; despite a lot of work on the backend we're no closer to figuring out the necessary color scaling/dithering the windows drivers employ so the color output from Gutenprint is pretty lousy.

This isn't how I'd intended to spend my Friday night. With luck the fever will finally break tonight so I can get out and about tomorrow..

Syndicated 2014-10-18 03:33:18 from Solomon Peachy

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

152 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!