Re: [Gimp-print-devel] Canon Pro-100

[Protea W. J. <aik...@gm...>]

On Tue, Dec 22, 2020 at 12:37 PM Ken Smolek <ke...@sm...> wrote:

> 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.
>

Hello Ken,
I am happy to hear you succeeded, I know some of those feelings, though I
suspect on a smaller scale!

> 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.
>
OK, if you host it on say Google Drive for a day or so I can download it
from you using a shared link perhaps? Or just send to me at
aik...@gm... if attachment size is not a barrier.

> 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.
>
The MP450 is actually for a printer model I own, and wanted to experiment
with. The standard and iP4200 curves do not work well on it. But owing to
time limitations the printer is not calibrated so the curves are not fixed
at the moment.

> 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.
>
OK, I am all ears. I have (had) my own priorities, which are mostly dealt
with, apart from the rather large CD issue. So I am happy to look into
restructuring code for more flexibility (XML files would enable users to
make changes without recompilation, a policy Robert has advocated and
implemented in the Epson driver).

> 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.
>
The Pro-100 has a disk tray for DC/DVD/Bluray printing (perhaps it depends
on region? I thought all regions have these now). But there is a serious of
different CD trays, and the Pro series uses I think the M type which we
have not gotten any practical results with since we could not print on any
of this series.
My main goal initially was to get the calculations and options right, but
if you want to help with getting the code separated out into other files
that would certainly be a positive thing.
The software weaving code I am not really sure about, whether printers
actually use it or not. Maybe early models of Canon printers used it, I do
not know. So I have never touched the weaving code.
Again, if the code would benefit from separation that is fine with me.

> 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?
>

Maybe Robert or something more fluent in the recommended data flow can
comment on this.

Best regards,
Gernot Hassenpflug

> 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 <ke...@sm...> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>


-- 
Protea Wines Japan
Tel: 070-5550-9076
https://www.proteawines.jp