Re: [Gimp-print-devel] Black generation, continued

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> You really want to use an appropriate set of if's around what's
> below.  There's no sense in performing the extra multiply and divide
> when you know you're going to throw away the result, and it also leads
> to the risk of range problems.

Hmm... divides may be a problem, but multiplies on modern processors are
pretty fast. Mispredicted branches can be slow, however.

By the way, I'm pretty sure GCC is clever enough to replace a divide by
a shift if that's faster. Also, I think it is better to leave
optimizations to the last: that allows you to use different loops for
different dithers. The code will be larger, but the loops smaller: hence
faster execution.

> It isn't enough.  Not only do we need matrices to dither the output
> dots, we also need to dither different dot sizes and colors.  That
> matrix *must* be just as good as the others, and it *must* be
> uncorrelated.

If it must be really uncorrelated, I guess the only thing to do is to
generate a number of them. But I feel that the only correlation problem
we might run into is the initial few points of the matrix against the
same initial points. If these are displaced for every use, the rest will
be practically uncorrelated.

The matrix to be re-used 8 times was not a success. I'n now generating
another 199 sized matrix with different initial points. As there is a
fair amount of randomness in the matrix generation (and random actually
gets initialized with a time() call...) it should be uncorrelated.

Both matrices can be used 4 times, by shifting 100 pixels X and/or Y,
and both should be of equal quality.

>  I have a fix in hand that improves output on my EX, and
> in some places it improves output on the 870.  Unfortunately, in other
> places it also makes the 870 output worse, because I don't have a good
> enough dither there.
> 
>    I guess I first have to find out what broke the use of the first matrix.
>    So far for organized working on my side.
> 
> Don't worry about it.

In any case, the 'problem' was my stupidity. In any case, I like to use
the autocorrelation properties of the matrix for very low density. It
makes sure that a very light grey gets printed with C and M dots far
apart. As density increases dots are filled in more or less at random
and correlation between different sections of the matrix gets extremely
low.

I hope the second independent matrix works out for the light vs dark ink
decisions. Let me know how you fare: I'm really happy with the extra
black I put in, so seeing it appear in cvs would be great - but I don't
feel like doing that myself yet: it is a quick hack, I haven't tested
with other printers, etc.

I do think the old code had too much possibilities to reduce printing of
black. I achieved good results with the code I posted, which basically
does:

- Find what black is represented in the color that we want to print.
- See where that falls between black_lower and black_upper
- Calculate accordingly what percentage of the black value to print as
black
- Subtract that black from the individual colors.

I think I oversimplified that bit of code by taking out those ifs to
check inputs and instead checking results. How does it work on the EX
anyway? I see now that the driver really reacts to the black limits that
are set and that a greay wedge is nicely monotonous.


Thomas