gimp-print-devel

[Gimp-print-devel] Decrease nozzles lead to the appearance of light stripes.

[Andrew X <68...@gm...>]

Hello!
I understand that I use gutenprint not in a very usual way, but hope for
your help!

I use it with epson xp15000 (6ch x 180nozzles) in bidirection mode.
When i modify xml and set 90 nozzles -
Light stripes start to appear on the image.

It looks as if, when the head moves in one direction, it dispenses less ink
than when moving in the other direction.

With unidirectional printing, this effect disappears.

To some extent, this occurs with all available rasterization algorithms.
But if you set it to 180 nozzles, everything becomes fine.


Perhaps you know what might be the issue or in which direction I should
look to find a solution to this problem?

[Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

[Walker B. <fo...@wa...>]

Dear Gutenprint community,

I’m at it again and doing some weird monochromatic toned printing with Gutenprint on an Epson P9000.

I’ve noticed something strange. If I build a CMYK profile and print a neutral target (gray ramp) that is converted to that profile with it through CMYK ink set in Gutenprint everything is correct.

If I print the same hard-encoded CMYK target four times through the printer by printing normal density of a single color per print (cyan at 1, MYK at 0, Magenta at 1 CYK at 0, etc) the print is entirely different with not enough black ink and too much color ink (in comparison).

There is some multiplication of numbers between the CMYK channels that is happening in the system at some point. Does anyone know what this multiplication is? If it’s a standard number/thing I can apply it to my backwards math.

warmest,
-Walker

Re: [Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

[Solomon P. <pi...@sh...>]

On Mon, Jul 01, 2024 at 11:17:40AM -0400, Walker Blackwell wrote:
> There is some multiplication of numbers between the CMYK channels that 
> is happening in the system at some point. Does anyone know what this 
> multiplication is? If it’s a standard number/thing I can apply it to 
> my backwards math.

Coincidentally, I think I ran into what you're looking for last week. 
Have a look at do_gcr() in src/main/channels.c:

This is its main loop:

  for (i = 0; i < cg->width; i++)  // ie repeat for each pixel
    {
      unsigned k = output[0];
      if (k > 0)
	{
	  int kk = gcr_lookup[k];
	  int ck;
	  if (kk > k)
	    kk = k;
	  ck = k - kk;
	  output[0] = kk;
	  output[1] += ck * cg->cyan_balance;
	  output[2] += ck * cg->magenta_balance;
	  output[3] += ck * cg->yellow_balance;
	  nzx.nzl |= *(unsigned long long *) output;
	}
      output += cg->gcr_channels;
    }



 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

Re: [Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

[Walker B. <fo...@wa...>]

I can follow 60% of this . . .

If I were to force it to print the basic CMYK percentages (basically nix all the GCR combo stuff and print 40% black if that is what the pixel has for its K value no matter what)

I see that I can just say output[0] = k;

But I don’t follow the logic of ck * cg.

Maybe ideally I’m simply saying for the color outputs that it’s 1 * cg->color_balance. ?

Would this output a more dumbed down thing?

best
-Walker




> On Jul 1, 2024, at 1:24 PM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Mon, Jul 01, 2024 at 11:17:40AM -0400, Walker Blackwell wrote:
>> There is some multiplication of numbers between the CMYK channels that 
>> is happening in the system at some point. Does anyone know what this 
>> multiplication is? If it’s a standard number/thing I can apply it to 
>> my backwards math.
> 
> Coincidentally, I think I ran into what you're looking for last week. 
> Have a look at do_gcr() in src/main/channels.c:
> 
> This is its main loop:
> 
>  for (i = 0; i < cg->width; i++)  // ie repeat for each pixel
>    {
>      unsigned k = output[0];
>      if (k > 0)
> 	{
> 	  int kk = gcr_lookup[k];
> 	  int ck;
> 	  if (kk > k)
> 	    kk = k;
> 	  ck = k - kk;
> 	  output[0] = kk;
> 	  output[1] += ck * cg->cyan_balance;
> 	  output[2] += ck * cg->magenta_balance;
> 	  output[3] += ck * cg->yellow_balance;
> 	  nzx.nzl |= *(unsigned long long *) output;
> 	}
>      output += cg->gcr_channels;
>    }
> 
> 
> 
> - Solomon
> -- 
> Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
>                                      @pizza:shaftnet dot org   (matrix)
> Dowling Park, FL                      speachy (libera.chat)
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

[Solomon P. <pi...@sh...>]

On Mon, Jul 01, 2024 at 03:00:49PM -0400, Walker Blackwell wrote:
> I can follow 60% of this . . .

When it comes to this stuff, I feel like the one-eyed king leading the 
blind.  :(
 
> If I were to force it to print the basic CMYK percentages (basically 
> nix all the GCR combo stuff and print 40% black if that is what the 
> pixel has for its K value no matter what)
> 
> I see that I can just say output[0] = k;
> 
> But I don’t follow the logic of ck * cg.

I _think_ what happens here is that it works out the common K between 
the channels, then uses a (non-linear) lookup table (and the color 
balance knobs) to figure the corresponding amount to reduce each channel 
by.

> Maybe ideally I’m simply saying for the color outputs that it’s 1 * 
> cg->color_balance. ?

That sounds logical, but I've never sufficiently immersed myself in 
gutenprint's core color channel stuff to truly understand it, and I'm 
embarassed to say I've probably forogotten 89.3% of what I managed to 
absorb the last time around.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

Re: [Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

[Walker B. <fo...@wa...>]

Thanks, 

I will twiddle knobs when I have the time and see if I can back myself into clarity.

warmest
-Walker



> On Jul 9, 2024, at 8:41 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Mon, Jul 01, 2024 at 03:00:49PM -0400, Walker Blackwell wrote:
>> I can follow 60% of this . . .
> 
> When it comes to this stuff, I feel like the one-eyed king leading the 
> blind.  :(
> 
>> If I were to force it to print the basic CMYK percentages (basically 
>> nix all the GCR combo stuff and print 40% black if that is what the 
>> pixel has for its K value no matter what)
>> 
>> I see that I can just say output[0] = k;
>> 
>> But I don’t follow the logic of ck * cg.
> 
> I _think_ what happens here is that it works out the common K between 
> the channels, then uses a (non-linear) lookup table (and the color 
> balance knobs) to figure the corresponding amount to reduce each channel 
> by.
> 
>> Maybe ideally I’m simply saying for the color outputs that it’s 1 * 
>> cg->color_balance. ?
> 
> That sounds logical, but I've never sufficiently immersed myself in 
> gutenprint's core color channel stuff to truly understand it, and I'm 
> embarassed to say I've probably forogotten 89.3% of what I managed to 
> absorb the last time around.
> 
> - Solomon
> -- 
> Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
>                                      @pizza:shaftnet dot org   (matrix)
> Dowling Park, FL                      speachy (libera.chat)