[argyllcms] Re: Ink Limit Override
- From: Jason Campbell <campbell.jj76@xxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 11 Aug 2013 21:23:28 -0400
Graeme,
Thanks for the feedback. I am replying to Nikolay in a similar thread, so
please review and see if anything strikes a note with you there... However to
this reply you offered, is there any way to override or work around this
behavior of the profiling engine?
What I mean specifically is that despite the crazy nature of CMY gray in the
3/4-tone+ region, at the end of the day, your 300% patch is uncontrollable. My
concern with Nik's input was that for me, 300% is 300%. I can't cut it short
like you can in an inkjet (where you effectively ink-limit with a sub 100%
output). In pure halftone, I have to hit a solid. So the modeled performance
contained in the profile I am building is not working when I query for my
expected 100% patch's Lab value and fall well short of 100/100/100/0 (300%).
Since I understand what both of you are saying, is there a way I can get
anywhere with a perceptual intent built by feeding in a synthetic (fake)
profile out of argyll? I am going out on a limb here not exactly sure this
makes much sense, but at the end of the day, I need...
If I query a Lab near paper, then I get near 0/0/0/0...
If I query a Lab near solid, then I get near 100/100/100/0...
If I query a Lab somewhere in between, I get a best estimate of the CMY build
to yield that Lab...
On Aug 9, 2013, at 2:43 AM, Graeme Gill wrote:
> Jason Campbell wrote:
>
>> calculated Ink Limit (-v switch). However when I start getting to the 80%+
>> tone value region, the profile starts sucking out on meŠ It pulls back on C
>> and M and starts to push Y. In looking at where argyll wants to pin my
>> total ink (when left alone; no -l switch) it puts me around 260%, and that
>> is what I see in the curves coming from xicclu -- that it starts pulling
>> back and at 100% C, M, and Y add up to just about that -- despite my attempt
>> to push it.
>
> Hi,
> typically xicclu will indicate what's going on. The B2A table
> is created by doing reverse lookups on the A2B table. If either there
> are no entries in the A2B using more than 260% ink, or if the gamut
> is not increased by using more than 260% ink, then it will never use it.
> I would suspect the latter if your chart has 300% test patches.
>
> Note also that the current code picks the darkest neutral as the
> black point for the purposes of gamut mapping, so if your 300% patch is
> not neutral even if it has a lower L*, then it probably won't be used
> when a gamut mapped B2A table is created.
>
> Without the profile or .ti3 data to play with, it's not possible
> to say anything more specific.
>
> Graeme Gill.
>
>
>
>
>
>
Other related posts:
