Hi, we are testing out an Epson 9800 right now and were having some
issues.
The red (100%y 100%m) Doesnt get red enough. To low intensity. And
the Delta E value landing on 9! All other colors are good. Im been
searching the net but havent found anything about this.
Im using GMG Colorproof and Fogra39 values.
Any ideas whats wrong?
This might be th wrong forum to ask about this but I'll give it a go
anyway.
//
_________________________
Magnus Sandström
Alfa Print
Cirkusgränd 2
172 63 Sundbyberg
08-546 007 74
I dont know were to go
At our printphop we have Heidelberg sheetfed presses
Two 8c 70x100
One 8c 50x70
one 5c 70x100
We are thinking of changing our colour management workflow into ISO
standard
the
ISOcoated_v2_300_eci Will probebly work fine
but the
ISOuncoated
We have a problem with that profile, it´s set to total ink coverage of
320% even more than the coated one
These days we have around 260% of total ink coverage on uncoated paper
in sheetfeed environment
This is a problem we have if we should make it easy for our client to
start using ISO standard
Do any have any solution or idea for future ISO profiles for sheetfed
presses
Regards
Morgan Axelsson
Hi list,
I have recently become aware of the change to the tone response curve
(TRC) in ECI-RGB to be defined by L*. Previously it was defined by a
gamma 1.8 function. I have had a number of conversations with
colleagues including color scientists and engineers about what makes
this compelling.
1.
On the face of it, it seems like L* is a good idea because it's
perceptually uniform and all that. But that's not the TRC of any of
our devices. And in an 8bpc context, that is the whole reason why we
having image encoding - is to deal with limitations of how our
devices actually behave today.
2.
Adding to confusion are two seeming contradictions on the ECI web site:
a.) "The focus of the eciRGB_v2 profile still is on the print and
publishing industry."
and
b.) "Especially 8 bit data using eciRGB 1.0 should be kept in eciRGB
1.0 as any colour space conversion will lead to at least some loss of
quality."
I consider these two statements seemingly in conflict because "print
and publishing industries" are almost entirely 8bpc only workflows,
and yet ECI-RGB v1 is recommended in an 8bpc context.
So when is ECI-RGB v2 recommended?
3.
High end retouching is being routinely performed with non-trivial
edits on linear encoded ProPhoto in 16bpc. What's the problem
exactly? On the face of it, it doesn't seem to apply to 16bpc
workflows at all.
4.
So I thought, maybe 16bpc edit, with 8bpc deliverable file workflow.
In a best case scenario I would tone map directly from a linear
editing space to the final print space, in 16bpc. Then drop to 8bpc
and deliver that file. That represents the least amount of loss of
levels through tone mapping.
So the question is, if I have a linear encoded image in 16bpc and
make a copy, take one copy and convert to ECI-RGBv1 and the other to
ECI-RGBv2, and then drop both to 8bpc; how similar are those two
image encodings to the final TRC of the output device I will likely
end up at?
The TRC of print and publishing industries are still close to that of
a curve defined by a gamma 1.8 function. Not L*. That's the current
reality of how print publishing actually behaves. Re-mapping from an
L* TRC to that of a typical print TRC results in more loss, than had
we mapped to an intermediate space that has a TRC close to typical
print TRC, that being one defined by gamma 1.8.
5.
I've seen no actual data on the ECI-RGB web site that demonstrates L*
based TRC is actually better, just a number of very strongly worded
claims:
"substantial advantages in the shadows"
"risk of posterization effects ... is significantly reduced"
These statements imply the inverse, that gamma 1.8 encoding has been
demonstrated to have substantial disadvantages in the shadows, and
risks of posterization is significantly increased. This is totally
specious and at this point, unproven. Where is the data proving this
either mathematically or in practice?
6.
L* does not represent the TRC of actual print tonality.
It would be nice if we could compel all of our devices to conform to
L*, but the fact is, they do not have this behavior. Human vision is
defined by L*, but device behavior is not, and that's why we encode
images, and why we have tone mapping in the first place. (Yes there
are a very small number of displays that can successfully be
compelled to have L* TRC, but still not print.)
This is supported even by information on the ECI web site:
"[ECI-RGBv1] offers equidistance, i.e. equal difference between two
color values in eciRGB mirrors an perceived equal difference when
these colors are seen by the human eye"
This is the same claim made by ECI-RGB v2 with respect to L* based
TRC, for the same market segment. Both cannot be true.
7.
In the case of closed-loop image editing, and *final* output to some
device that has an L* defined TRC, I see a benefit to L*. This is
hardly a new concept, as it's effectively used in medical imaging
(e.g. DICOM).
Closing statement:
In each of these areas I find that L* based TRC is either no better
or worse than what previous workflows have recommended, or results in
additional loss compared to previous workflows.
Further I find that this has made ECI-RGB confusing to the market to
differ only by one character, 1 or 2.
In an 8bpc workflow it's better to tone map to a TRC closer to final
output TRC to minimize the loss of levels through tone-remapping.
In a 16bpc workflow we have a lot of bits available, so TRC selection
is not particularly important (within reason.)
So the overriding question I have here is, why ECI-RGB v2? I don't
see it as being even remotely compelling over ECI-RGB v1, which I do
find compelling over both sRGB as well as Adobe RGB (1998). And the
reason I don't find it compelling is because I don't find an L* based
TRC to be compelling (i.e. I'd like to limit the conversation to that
of TRC rather than gamut, which is a separate issue).
Chris Murphy
Od 18.02 do 25.02 przebywam poza biurem.
W pilnych sprawach proszę o kontakt telefoniczny.
I will be out of the office from 18.02 to 25.02.
If you need assistance, please call me (+48) 697 701 788
Pozdrawiam/Best Regards
Joanna Chamera
Dear sender,
I will be out of office from 18th - 22nd Feb 2008. I will have limited access to my emails during this period.
Please refer to Paul Foong (paul(a)datajet.com.sg) for all enquiries. Thank you.
With Regards,
Samuel LEE
Bits & Bytes Marketing Pte Ltd
Dear sender,
I will be out of office from 18th - 22nd Feb 2008. I will have limited access to my emails during this period.
Please refer to Paul Foong (paul(a)datajet.com.sg) for all enquiries. Thank you.
With Regards,
Samuel LEE
Bits & Bytes Marketing Pte Ltd
Dear sender,
I will be out of office from 18th - 22nd Feb 2008. I will have limited access to my emails during this period.
Please refer to Paul Foong (paul(a)datajet.com.sg) for all enquiries. Thank you.
With Regards,
Samuel LEE
Bits & Bytes Marketing Pte Ltd
Od 18.02 do 25.02 przebywam poza biurem.
W pilnych sprawach proszę o kontakt telefoniczny.
I will be out of the office from 18.02 to 25.02.
If you need assistance, please call me (+48) 697 701 788
Pozdrawiam/Best Regards
Joanna Chamera
Dear sender,
I will be out of office from 18th - 22nd Feb 2008. I will have limited access to my emails during this period.
Please refer to Paul Foong (paul(a)datajet.com.sg) for all enquiries. Thank you.
With Regards,
Samuel LEE
Bits & Bytes Marketing Pte Ltd
Dear sender,
I will be out of office from 18th - 22nd Feb 2008. I will have limited access to my emails during this period.
Please refer to Paul Foong (paul(a)datajet.com.sg) for all enquiries. Thank you.
With Regards,
Samuel LEE
Bits & Bytes Marketing Pte Ltd
