[argyllcms] Re: Calibration already calibrated. Feature or help request.

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 20 Dec 2010 17:23:02 +1100

Dmitriy Chaplygin wrote:


1. Preliminary calibration:
targen.exe-v-d4-l100-f0-m0-s64-w-W        720un4gpLin
printtarg_6x6.exe-v2-a0.5-T 360-ii1-p45x297-L    720un4gpLin
chartread.exe-v-T0.5                720un4gpLin
printcal.exe-v-i-a-p                720un4gpLin

On an output - 720un4gpLin.cal (see attach)

The curves look pretty smooth. The dot gain is high though, meaning
that there will be a lot of correction needed.

3. I will remind that this stage transits on already calibrated device - I

On an output - 720un4gpLinReCal.cal (see attach)

But judging by the schedule the first stage did not give ideal
correct(exact) calibration! It most likely is connected by that I used RAW
mode in gutenprint. Thus gutenpint does not do(make) any restrictions of
density of channels and at all does not adjust chromaticity(chrominance).
Accordingly, the gradient unpacked(printed out) in this mode looks very
dark, that is absolutely not calibrated. I think therefore printcal from the
first did not consult completely.

Because the dot gain is so high, perhaps the test chart doesn't have
enough detail near zero. You could try more test points, or try
using the "-p power" parameter to distribute more test points
near zero (ie. try something like -p 2.0).

Here the headache begins :)
The matter is that at at the first stage curves it have been received it is
clear, however at the second stage as curve calibrations have been received.

Here now there is a question how to compensate a curve of the first stage
(720un4gpLin.cal) for the account of a curve of the second stage
(720un4gpLinReCal.cal)?
Such feature I would like to pay attention to necessity of presence
respected Graeme! :) It can be valid you could include(turn on) such
function in printcal, it really is very necessary.

On the letter I apply excel a label where I tried to compensate the first
curve for the account of the second.
Here again too I want to ask a question - whether correctly I made.
The algorithm was such (on an example of one channel):
a) In.cal a file there is a first column ideally with values of the ideal
linear response.
b) we Calculate the relation of the second curves to this column, that is it
is divisible each value of a curve of the second stage on value in reference
a column. We receive coefficient of the relation of the second curve to
reference.
c) Then we multiply values of the first curve by the received coefficient,
that is it is brought the first curve into accord with the relation of the
second to reference. It is As a result received a curve which turned out as
a result of compensating of the first for the account of the second.

Your judgement is necessary - whether correct(exact) is a method?

That's one way. You can also tweak the curves by editing the .cal
file to set correction target points, and then doing a re-calibration.

You can figure this out by setting a correction point (say -tc 51)
and then looking in the .cal file for the corresponding entry "TRANS_PNT".

You can add an arbitrary number of correction points.

4. Now again I print a target for as I hope, final check.

Yes, they look a bit better. I'd be interested to know whether
a better test chart helps though.

Gplin naturally it considers and compensates. Can be in printcal to make
something similar?

See the -p parameter.

Hope this helps,

Graeme Gill.

Other related posts: