Re: Canon Pro-100

Hi Gernot,

Thanks for your quick response. I have to admit, at times I doubted that 
it would ever work. The first successful low-resolution test page was a 
tremendous relief, if only the tip of the iceberg.

If you want to take a look at what I've done, an easy way would be to 
simply tar up the gutenprint directory (about 17MB as tar .xz, including 
the git history) and find a way to send it to you.

As far as curves, I did some test prints, and ended up using 
standard_hue_adjustment, standard_sat_adjustment and 
ip4200_lum_adjustment in canon-printers.h. I copied them and renamed 
them to Pro100_*_adjustment so that I can make changes. They're included 
in the Pro100 printer definition. I don't think I actually tried the 
MP450 adjustments, but I probably should.

There are some things I would like to do to the ink handling, but I need 
to think about it a little more and discuss it with all of you. The ink 
structure used in the escp2 driver is significantly more flexible than 
the canon driver, but I'm not sure I'd want to try to incorporate it. 
There are a few tweaks that could simplify some of the driver code, I 
think. And I put a specific Pro100 structure array in print-canon.c, 
which has to be dealt with.

I don't even have a CD player, so I'm probably not your CD guy. In fact, 
no offense intended, but I'd like to isolate the CD code as much as 
possible in other files or at least other functions so that I don't have 
to read past it every time. From what I've seen, that wouldn't be a big 
job. Same for the code which handles weaving.

It sounds like it makes sense to think hard about IPP, so I'm going to 
take a look at it over the next few days and see if I can understand it. 
My main concern, having looked at the attributes returned by the 
Pro-100, is that I'm not sure how to get maximum capability out of it. 
What would the output format be: urf or pwg-raster - I presume we 
wouldn't want to try to convert to jpeg before output?

If anyone wants to see an example of the output from the printer, I 
could scan a couple of prints.

Ken


On 12/21/20 6:03 PM, Protea Wines Japan wrote:
> On Tue, Dec 22, 2020 at 9:43 AM Ken Smolek <[email protected] 
> <mailto:[email protected]>> wrote:
>
> Hello Ken,
> Many thanks for your message, I am very impressed and delighted that 
> you have managed to get one of the Pro series working.
> I am the current maintainer for the Canon backend, and would love to 
> work together to incorporate the code.
>
>     Then I came across a pristine Canon Pro-100 for almost nothing and
>     bought it, which has turned out to be a monumental rabbit hole.
>     But I'm
>     retired and have nothing better to do, especially in a pandemic, so I
>     tackled it.
>
>     With no Gutenprint/CUPS driver, and little or no documentation (that
>     mostly from Gutenprint and Ghostscript, nothing from Canon), it's
>     been a
>     very tedious process of reverse engineering of the command
>     strings. And
>     the Canon printer driver [print-canon.c:canon_setup_channels()]
>     takes an
>     approach to subchannels which doesn't work for the Pro-100, which, as
>     near as I can tell, demands that channels be output in the order
>     CMYcmkHL. In addition, the raster output string [formerly ESC(nn nn F
>     data] has been expanded to take a 4-byte length, and is now ESC(N
>     nn nn
>     nn nn F data.
>
>     To make a very long, 2-month story short, I have a working Canon
>     Pro-100
>     under Gutenprint which uses all 8 inks and prints photos which are
>     not
>     perfect, but are of pretty high quality. Images converted to
>     grayscale
>     in Gimp print very well, but I have been unable to get straight
>     monochrome printing (using an inkset consisting of black, gray, and
>     light gray - kHL) to work.
>
>     I've tried very hard not to break existing code, but obviously
>     there are
>     no guarantees of that. Where I added significant code to handle the
>     Pro-100, I generally did it by creating new functions, which are
>     called
>     only if the printer is PIXMA Pro100. In some cases, I simply added
>     the
>     Pro-100 to an already-existing set of printers in a long if
>     statement.
>     Code was added as necessary for inks, modes, media, etc. The mask
>     protocol in print-canon.h is still a little mysterious to me, but I'm
>     reluctant to mess with it more than necessary.
>
>     [BTW, I started from a downloaded 5.3.3 tar file. I set up a local
>     git
>     repository with my changes in a Pro100 branch, so all
>     modifications from
>     the canonical version are visible.]
>
>     Print quality improved dramatically when I included the standard
>     Canon
>     hue, sat and luminosity curves to the Pro-100 printer definition -
>     that
>     was when I realized I might have a really usable driver. But it's
>     still
>     not perfect - I've done some tweaking in the Adjust Output screen,
>     but
>     I'd love to be able to improve the curves and LUTs. Is there a
>     description anywhere of how the hue/sat/lum arrays are generated?
>
>
> Where did you get the "standard Canon" curves from?
> I don't know how the existing ones are generated actually, there are 3 
> to choose from.
> Those for the iP4200 are apparently tuned to that printer, and may be 
> correct for some other printer models too.
> Unless one actually has a printer to test, it is not really possible 
> to design matrices.
> The Canon driver started out as a fork of the (now much more advanced) 
> Epson driver.
>
> Robert, is there any background on the matrices in the Epson driver 
> that may help?
>
>     So, where do I go from here? This is very close to a driver I can use
>     for my own prints, but it's not production software. And I have no
>     way
>     of regression testing to see what I may have broken. If you
>     prefer, it
>     can just stay here as a local modification for my personal use. Or we
>     could attempt to integrate it in some way, possibly by creating a
>     print-canon-pro.c which is completely separate from the existing
>     print-canon.c. This would have been a reasonable way to go initially,
>     but hindsight is 20-20, and I didn't
>     really understand what I was getting myself into.
>
>
> I would like to incorporate the code if possible. I have some 
> understanding of the Canon driver code, since I have been touching it 
> for some years, but I do not have a very clear understanding of ink 
> handling and low-level routines even now unfortunately.
> Most of my work has been trying to add commands, and various options 
> for the commands.
> A major work in progress is to get CD printing to work systematically, 
> so if you have time on your hands, I would love some help with that.
>
>     Another possibility is to implement an IPP driver for the printer and
>     try to eliminate the Pro100 ppd entirely. That's an attractive
>     possibility to me, but I'm still vague on the actual process, and
>     I'll
>     have to take another look at the IPP sample code to see just how
>     complicated it will be. Your opinions are welcome.
>
>
> Robert, do you have any opinions on this?
> Best regards,
> Gernot Hassenpflug
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

_______________________________________________
Gimp-print-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel