[argyllcms] Re: Segmentation fault

  • From: Dimitrije <migraf015@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sat, 4 Feb 2012 13:55:28 +0100

I try to make profile with "-qm" and "-qh" and there is a difference. 
with -qm is larger err
Profile check complete, peak err = 8.124194, avg err = 1.386176, RMS = 1.697672

and with -qh is smaller err also better quality
Profile check complete, peak err = 4.136766, avg err = 0.568436, RMS = 0.712158 

Also when I was use -bu I got the best results, but error is the same, and Profile check depends only from -q option.
But the real quality is much better after I was use -bu, and the file was larger.

The best results what I've got is with this command
"colprof -v -D"R430_Migraf_04SwopUHigh" -bu -Zp -Tp -cmt -dpp -iD65 -SSWOPM18.icm -OR430_Migraf_04SwopUHigh.icm R430_Migraf_R3ps"

I just try to see is there any difference if I use -qu, but I giveup from that.

I wandering, does it need to last so long and Which number I should use wirh Performance comand so I can give a faster results?
I send the rest of file so you can try it.

Dimitrije Zivkovic

On Feb 4, 2012, at 6:11 AM, Graeme Gill wrote:

Dimitrije wrote:
The command line:
colprof -v -D"R430_Migraf_04SwopUltra" -qu -bu -Zp -Tp -cmt -dpp -iD65 -SSWOPM18.icm -OR430_Migraf_04SwopUltra.icm R430_Migraf_R3ps

and also I often get the warning info : Reverse Cell Cache exausted, processing in chunks

No surprises there - you are using the ridiculous "-qu", so you run out
of memory. On any well behaved device I can't see any difference
between -qm and -qh. (And BTW -b is not needed if it is the same as -q).
On a badly behaved device -qu may bring improvement, but it won't
make it well behaved.

My usual advice applies:

 First use -qm, then if you want, try -qh. If you can't
 see any improvement, stick to -qm. If you can, stick to -qh.
 Don't use -qu just because you want to "turn it up to 11",
 only use it if you can acually see some benefit.

I read Performance info, and set cache to 1.5 I have 8GB of memory and I don't understand fully
what should I have to do with cache, so I can avoid this problem.

Note that since it's a 32 bit exectutable, it can't use more than 4GB, and typically
is limited to a whole lot less than that by ineficiencies in the OS.

I was unable to reproduce this problem without the files you are using, so
you really have to send me SWOPM18.icm and R430_Migraf_R3ps.ti3 if I am to investigate.

Graeme Gill.

Other related posts: