[prev in list] [next in list] [prev in thread] [next in thread]
List: gimp-print-devel
Subject: Re: [Gimp-print-devel] New mode "Color Correction". Whether it is
From: "Dmitriy N. Chaplygin" <chapa75 () gmail ! com>
Date: 2011-02-17 9:12:49
Message-ID: AANLkTinTJ5s16NDgF4QRD1Mw298X6Gmo9LT4ki5WHgho () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2011/2/17 Robert Krawitz <rlk@alum.mit.edu>
> On Wed, 16 Feb 2011 15:04:59 +0300, Dmitriy N. Chaplygin wrote:
> >
> > *Day kind Robert and All!
> >
> > Whether there is a possibility to add a new mode "Color Correction"
> > which would be as RAW + Curves + TIL + (+ Gloss Separation in case
> > of R800-1800) ONLY, that is without the registration "Base Density",
> > "Channels Density".
> >
> > The matter is that IMHO at the press it is necessary and enough
> > presence of descriptions of curves, be they in paper.xml or in
> > printrc. Moreover, absence Density of parameters will be completely
> > compensated by presence of the description of the curves which upper
> > bound will be restriction channel Density. Thus, we can tell about
> > possibility completely instrumental calibration of process of the
> > print, and this process for account ArgyllCMS (Printcal) enough
> > simple, but thus the correct.
>
> That sounds like Raw color correction to me?
>
Thanks for the answer, Robert!
As far as I understand, in Raw color correction mode (RCCM) are not
perceived Curves and other parameters of correction of the hardware data.
For this reason I also wrote that it would be extremely useful to have RCCM,
but with usage of curves as it is unique true, and at the same time the
simple decision for linearization correction together with
perChanelInkLimits.
However, I made experiments with usage linearization curves inside "printrc"
(GimpPrintPlugin core). Perhaps, if them will implement in paper.xml they to
be considered in RCCM?
> As to necessity of presence in new ColorCorrection mode necessities
> > Gloss Separation - that it is caused by practical application
> > multichannel (DeviceN) profiles. On the base led by me of
> > experiments in multichannel profiles, one problem came to light only
> > is that if we print in RAW gutenprint in this mode perceives simply
> > 8 raw channels. That is Gloss the channel should be controlled (to
> > generate it) still before we submitted on an input gutenprint, and
> > it is serious enough problem. As a result it turns out that if, for
> > example, we want to flood in R800-1800 an own InkSet, for example,
> > CMYKGBO+Gloss before to submit all 8 raw channels on an input
> > gutenprint we are obliged to generate somehow GlossChannel. On the
> > other side, I understand that it would be expedient for making at
> > kernel level gutenprint.
> >
> > Concerning TIL - in particular necessities of new mode RAW + TIL -
> > this question rose for a long time, and necessity of presence of
> > such mode is quite obvious.
>
>
--
Yours faithfully,
Dmitriy Chaplygin.
C уважением,
Дмитрий Чаплыгин.
+7 (495) 979-8412
Skype: Chapa75
ICQ: 3167277
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">2011/2/17 Robert Krawitz <span dir="ltr"><<a \
href="mailto:rlk@alum.mit.edu" \
target="_blank">rlk@alum.mit.edu</a>></span><br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 16 Feb 2011 15:04:59 +0300, Dmitriy N. Chaplygin wrote:<br>
><br>
> *Day kind Robert and All!<br>
<div>><br>
> Whether there is a possibility to add a new mode "Color \
Correction"<br> > which would be as RAW + Curves + TIL + (+ Gloss Separation \
in case<br> > of R800-1800) ONLY, that is without the registration "Base \
Density",<br> > "Channels Density".<br>
><br>
> The matter is that IMHO at the press it is necessary and enough<br>
> presence of descriptions of curves, be they in paper.xml or in<br>
> printrc. Moreover, absence Density of parameters will be completely<br>
> compensated by presence of the description of the curves which upper<br>
> bound will be restriction channel Density. Thus, we can tell about<br>
> possibility completely instrumental calibration of process of the<br>
> print, and this process for account ArgyllCMS (Printcal) enough<br>
> simple, but thus the correct.<br>
<br>
</div>That sounds like Raw color correction to me?<br></blockquote><div><br>Thanks \
for the answer, Robert!<br>As far as I understand, in Raw color correction mode \
(RCCM) are not perceived Curves and other parameters of correction of the hardware \
data. For this reason I also wrote that it would be extremely useful to have RCCM, \
but with usage of curves as it is unique true, and at the same time the simple \
decision for linearization correction together with perChanelInkLimits.<br>
<br>However, I made experiments with usage linearization curves inside \
"printrc" (GimpPrintPlugin core). Perhaps, if them will implement in \
paper.xml they to be considered in RCCM? <br><br></div><blockquote \
class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, \
204, 204);padding-left:1ex">
<div><div></div><div>> As to necessity of presence in new ColorCorrection mode \
necessities<br> > Gloss Separation - that it is caused by practical \
application<br> > multichannel (DeviceN) profiles. On the base led by me of<br>
> experiments in multichannel profiles, one problem came to light only<br>
> is that if we print in RAW gutenprint in this mode perceives simply<br>
> 8 raw channels. That is Gloss the channel should be controlled (to<br>
> generate it) still before we submitted on an input gutenprint, and<br>
> it is serious enough problem. As a result it turns out that if, for<br>
> example, we want to flood in R800-1800 an own InkSet, for example,<br>
> CMYKGBO+Gloss before to submit all 8 raw channels on an input<br>
> gutenprint we are obliged to generate somehow GlossChannel. On the<br>
> other side, I understand that it would be expedient for making at<br>
> kernel level gutenprint.<br>
><br>
> Concerning TIL - in particular necessities of new mode RAW + TIL -<br>
> this question rose for a long time, and necessity of presence of<br>
> such mode is quite obvious.<br>
<br>
</div></div></blockquote></div><br clear="all"><br><font style="color: rgb(0, 0, 0);" \
color="#888888">-- <br> Yours faithfully,<br>Dmitriy Chaplygin.<br>C \
уважением,<br>Дмитрий Чаплыгин.<br>+7 (495) 979-8412<br>Skype: Chapa75<br>ICQ: \
3167277</font><br>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic