I use the QTR profile making tool for my Epson 3880 and have produced ABW profiles that result in a linear result as per the spectral measurements of a 21 step B/W wedge. going to a 51 step B/W patch set did not produce any measurable difference in my testing. I use ArgyllCMS to generate and read the patches and the QTR tool for making the profiles.
Hello,
thanks for your comment, it gives me the opportunity to explain some additional little things.
The workflow you have described is exactly the one I have started with at first, before deciding to jump on my self-developed solution.
I like to note that in this way you get results similar to my "linear" L* rule discussed above, which I still consider a very reasonable choice and a very good overall tradeoff.
That said, the main problem creating and reading the strips with Argyll is that, if you want a particular custom set of patches (adding some redundant patches or getting L* equally spaced wedges for example) you still have to manually edit the generated tiff files and to modify some other text configuration files accordingly.
In addition the 16bit tiff files generated by Argyll and edited (or created) with other popular editing software (like Photoshop) are not truly full 16 bit ones.
I want not to flame/bother too much on this argument, but if you look at them with an hex editor you discover some little deviations from the theoretical perfect 0-65535 full range. It is not something noticeable in real world scenario of course, but is something I liked to avoid and address anyway.
For these reasons I have done a script in Octave to mathematically generate/requantize perfect 16bit values in my strip files.
In this way I have the flexibility to choose any custom set and, even if not so comfortable, I ended preferring to read the strips with ColorPicker, because I can perform multiple readings with forward-backward sequence to average measurements errors, I can repeat/combine the final palettes if something goes wrong during measurement, and export a single cxf file for data processing without additional manual edits.
If you consider that, as per what I have experienced, Argyll cannot create correction profiles based only on gray patches, forcing me in any case to externally perform the math and the profile creation, you can easily understand why I have abandoned this route.
Regarding QTR, let me remark here that I think it is a really glorious piece of software, full of powerful features, highly effective and almost mandatory if you want to go for the Piezography route, for example.
Kudos to Roy Harrington for his wonderful work.
Unlikely, after few tests and a short mail exchange with Roy, there were some little things I don't liked in using QTR for printing instead of using the Epson drivers.
Even if you can tag it as pure marketing vaporware QTR does not seemed to me to support the full max resolution of the R3000.
I have experienced some little quirks with the trays, and the process to get a full profiled setup is not so immediate, including the curves setup and the ink limits values and so on.
In addition I prefer to have a single workflow for printing color and BW, using my preferred application and the Epson drivers, with possibly the most interchangeable limited set of correction profiles for both (color and BW), possibly generated in the less empiric and most automated measurements based way.
This lead me to abandon QTR as printer driver (but this is only my personal choice) and eventually only using their linearization icc making tool alone.
Please, correct me here if I'm wrong, but after some test as per what I have experienced, the QTR icc rgb making tool alone is based on the same L* linear approach I have implemented in my scripts (above described).
But there were some other things I wanted to address: the gray tone compensation.
Again, correct if I'm wrong, but I don't think the QTR tool is able to do this.
Even if it creates a RGB icc profile (for compatibility problems with latest CS6 and grayscale profiles), it is a Lightness only correction profile, because it was mainly intended to work for grayscale images.
If you print in ABW there are no further possibilities to neutralize the gray tone, you can only dial the tone settings in some way and apply an empiric trial and error procedure to your tastes.
But if you print in ICC RGB color this is something really possible, and my system create a neutral gray tone full correction in an automatic and perfect way. This kind of gray tone correction is something I can manage independently from the Lightness (L* linear) correction by integrating the two or leaving alone the two as preferred.
It is useful to add that in the same way I can create a "toning" profile with every mathematically generated tone curve you can imagine.
The nice thing is that my correction curves, being DeviceLink ICC profiles, are perfectly able to compensate even external chemical-based printing services that usually accepts only jpg files with embedded sRGB color space.
If they allow you to print in "native" mode (without automatic corrections) in 1 or 2 steps you can create a correction curve for Lightness and/or color cast perfectly matched to the external service.
An additional (under development) feature is the ability to handle the "over-inking" issue automatically, by shifting the correction profile accordingly. This is something the QTR tool alone could simply not handle (it gives you an error if the L* ramp measurement curve is not monotonic). To address this you have to use the QTR driver and set up correctly all the ink limits in a not banal and immediate procedure.
Not to mention that using my scripts in Octave all the math is done in floating point, with virtually zero errors across color space conversions (Adobe RGB, sRGB and CIELab) and very sophisticated interpolation algorithms.
Just for the sake of curiosity try to open a full grayscale ramp patches in Adobe RGB using Photshop CS6, and to perform a Lab conversion and a Adobe RGB back conversion again. Look at the histogram between the first and the last and look at what happens to the patches 13,13,13 and 14,14,14 and 15,15,15 during this theoretically neutral trip
For all these reasons I slowly proceeded with my humble work, which early results I have showed here in my first post.
I know that there is a lot to do, mainly in simplification of the process (which is something really important and currently not fully achieved). I will maybe even try to develop a "s" shaped L* target as suggested.
Sorry for the long bothering post.
Any further comment/suggestion is still welcome and appreciated.
Many thanks again.
Ciao