I'm sorry i haven't replied sooner. Things have been hectic, and I wanted to make sure I responded carefully and fully.
One of the problems with QTR is that it's so poorly documented, it's hard to know precisely how functions are going to behave. GRAY_CURVE seems like less of a black box to me -- it's more flexible and less likely to return obscure errors, so this is the function that I use.
That is why I have been testing every little aspect of QTR and have been in the process of writing a book about it. It's over 20,000 words so far, with a little bit yet to go. Over the past year and a half I've made hundreds of profiles testing different inks, papers, and profiling methods, and am breaking down each part of the process down with explanations and illustrations on what each of the settings do, and how to make the each step in profile creation process almost semi-automatic. It's meant to take the trial and error out of most of the process, and make it fast and repeatable. This tool is just part of something that I will be including with the book, and decided to make this tool available for free now because ... well, just because I am a nice guy.
The built in QTR correction curve: I've written about this before on the QTR yahoo group. If you look at the terminal window after running the install script on the Mac you will see where it generates a linearization curve with "input,output" points for each profile that contains linearization measurement data. That linearize_curve=" ... " can be can be pasted into the Gray_Curve= line and the Linearize= line can then be deleted, the profile reinstalled with the correction curve, and then linearized again. Of course, this is not possible to do on a PC, which is one of the reasons I created this tool, but if the measurements are out of order or if there are any bumps the built in qtr correction correction curve might not function properly when pasted into the Gray_Curve= line. The correction Curve Tool I created works on the same premise as the linearization curve QTR makes from the linearize= line (really, they are both linearization curves, they are just generated differently).
Apples and oranges -- the QTR linearize process is not the same as applying a gray curve.
More like granny smiths and red deliciouses. The linearization done on the initial quad values is not the same as “redrawing” the initial profile using a gray curve input, but you can use a similar kind of correction curve as the one QTR generates to make a near-linear profile without using the linearize input. You can then go on to print and measure a 2nd 21 step target and linearize with those readings.
Sorry if I have misunderstood your tool, I thought the values you calculate are to be deployed using GRAY_CURVE.
That is correct, and is only meant for use in the gray curve line. Putting them anywhere else will cause unwanted results.
I guess there is no reason you couldn't use the same values for LINEARIZE, but I wouldn't expect these methods to have the same result.
If you put the measured values from the target in the linearize= line and not the ones from the correction curve, then yes that would work, and how it is usually done. Putting the values from the correction curve into the Linearize= line would not give you what you expected.
The following two scenarios would have similar results: Create an initial profile without Gray_Curve= or Linearize= settings, and then print and measure the 21-step target. Then use those measured values in the Linearize= line and you would then create a profile that should print linear (if you don’t get a linearization error). You could also take the same measurement file/densitometer readings you put into the Linearize= line and enter them it into the spread sheet tool, copy the correction curve, and paste it into the Gray_Curve line (with NOTHING in the linearize line). The two resulting quad files should look and print similarly. That is what the last three or four illustrations in my original post show.
I do know that I have been able to build excellent ramps using only 2,1, or even no decimals. As a software engineer, I have never encountered programming that required 10 or 13 decimals. For me, all these numbers are untidy and just make everything hard to read.
I am not a software engineer, so I can't speak to what kind of precision a program needs for the thing to have good results, but rounding it off to 4 decimal places should be just fine. This is not meant to be disrespectful to you or your field. I certainly wish I had more experience in that area, rather than struggling to teach myself/relearn some fun computer maths as an adult...
Most of the work now is using 6-7 gray inks and found that if the cross over points are not found by interpolation between the two nearest values (which can cause long decimal strings) and the linearization measurements are not averaged from 4-6 readings then the resulting profiles will have bumps/reversals in smooth gradients. You can get away with estimating the cross over points and rounding off with the linearization measurements with 1-3 black inks, but adding more inks complicates things and it requires more precise settings. What I am doing is all done from measurement files and all the calculations are done automatically by a different template. I just paste the results into a text file. Since I am not really writing or typing anything during this process it doesn’t matter to me how long the decimals are; the computer is doing all the work.
All that aside, I love how we are now having a debate about decimal places. . . (Wink smile emoticon)