11:41 a.m.
Hi,
there is one thing that has kept chasing me for quite a while now, and
I'd like to share this with you for some possibly interesting discussion:
Assumptions:
- at least some 'color management' - whether correctly or not - is done
everywhere (and be it only conversion to CMYK or retouching in CMYK of
some image in Photoshop)
- for most documents that get printed on a printing press any necessary
conversion to CMYK or establishment of CMYK values - again: whether
correctly or not - is done early on in the food chain (e.g. by the
designer or layouter, as opposed to the printer)
- in terms of number of different pages produced altogether, more pages
are created by not so professional people but also often printed in
smaller print runs, whereas a comparably smaller number of pages printed
in higher print runs (magazine/newspaper ads, catalogues, direct mailing
pieces, packaging, etc.) is typically produced by more professional
people (though your mileage may vary significantly ;->)
- the number of printers (i.e. people/companies running print presses) is
relatively small when compared to the number of people creating/producing
pages to be printed on presses.
- the number of people in the graphic arts industry who master color
management (i.e. they get it right nearly all of the time) is relatively
small; these people are typically more often found down stream in the
food chain, often as staff in high quality prepress service providers or
prepress departments of larger agencies/industry customers/printers.
- anybody else in the industry - for more than one reason - is having a
hard time getting color management right and getting reliable results
- those professionals mastering color management typically have learnt
that real color management is about process control: know what your color
will look like, and how to make sure it does look like that in the end
(i.e. after having been printed on the press). They accept that quite
often it might have been possible to get 'better' color, but due to the
fact that under the given circumstances it has not been possible to
predict and control in what way the color would have been better these
people resort to slightly less ideal, but predictable color.
- many other people involved in the graphic arts industry - whether those
working inside it or those buying its services - are (often unknowingly)
rather looking for the best possible result. They do not mind if a repeat
print run looks slightly different as long as it looks 'nice' (though
this is less true for specific colors, e.g. Coca Cola will always want
that their Coca Cola red looks as much the same all the time as possible).
Conclusions:
- at the moment the majority of people who are (knowingly or unknowingly)
doing color management (e.g. conversion of a digital camera image from
some kind of ICC based RGB to whatever kind of CMYK, editing of color in
CMYK on screen, judging color from a color print printed from CMYK data)
... do no have a clue about color management
... do not have ideal equipment to do color management well
... do not have the means nor the knowledge or experience
to set up equipment for reliable color management
which means this in a way is like asking a deaf person to listen to the
radio and write down what they understood from the broadcast.
- because of files today being often delivered digitally directly from
the creating side to the printing side there are no gateways anymore as
there were until a couple of years ago in the form of service bureaus
that imaged files onto film and, where desired/required, did analogue
proofs. This hurts some printers more than others: for example,
newspapers are complaining quite often that total ink coverage for ads is
sometimes too high, the reason being that some image was converted to
CMYK in Photoshop using for example a Euroscale profile.
- one of the reasons printers can nevertheless get their presses going
somehow and can produce more or less pleasant looking results is that not
so professional people often screw up their data in similar ways (so
certain heuristics, once found, will compensate for similar problems in
most of the files). Nevertheless there are often also pages ending up on
the same sheet that have significantly different characteristics.
Applying a heuristic to improve one of the pages will deteriorate one of
the other pages on the same sheet.
- having color management done early on in the food chain by people who
do not master it means that a lot of options to get it right again are
unretrievably lost. If on the other hand files had been left in their
initial color space, more professional people further downstream had
better options to convert images/pages to a more reliable, more
predictable, more easily producible and nicer result.
- also, in terms of overall economy, it is much smarter to have the fewer
people at printing plants and associated prepress departments/service
bureaus learn to master color management than trying to educate the
masses (whose job description most of the time does not include a bit
about color reproduction as such) towards some pretty complex matter.
Summary:
- prefer digital files with as much device independent color retained as
possible (though it will always be acceptable if a professional document
creator submits device dependent CMYK files - they know what they are
doing...)
- establish knowledge and equipment at every printer or at a service
provider associated with every printer that enables the printer to
convert incoming digital files to device dependent data appropriate for
the printing process at hand
- be pragmatic about the strategy: if files seem to come from
professionals, convert 'as is'; if files seem to come from not so
professionals, convert them in a way to make them 'as nice/pleasant as
possible'.
- the ideal format for this is PDF/X-3: it accommodates both device
dependent and device independent data in any combination.
- also, there are now enough decent tools (with varying degrees of
quality and price tag) available - especially iQueue from Gretag Macbeth,
SuperColor from Heidelberg, Acrobat 6 Professional from Adobe, Quite A
Box Of Tricks from Quite - to easily color convert PDF files to process
specific CMYK.
Essence:
It is not smart to request CMYK files from people who do not understand
color. Instead by default postpone color conversion to CMYK as long as
possible. Promote PDF/X-3 as the natural carrier for digital files that
maintains all options and can handle files from professionals as well as
from not so professionals.
Olaf Druemmer
12:14 p.m.
Hi Olaf,
I fully agree with the essence of your well written posting.
But even working in RGB requires a basic knowledge of color management,
color models and the concept of a working space - along with a
calibrated and profiled system. Otherwise " if files seem to come from
not so professionals, convert them in a way to make them 'as
nice/pleasant as possible'" will result in a try and error method that
is neither productive nor will it result in a consistant color quality.
We love PDF/X-3 but don´t promise "perfect color automatically". I
know, you did not, but people are easily tempted to understand it that
way. Color management vendors have made this mistake very early on, and
we are still fighting the extreme expectations, this has created in the
customer´s mind.
Karl Koch
Am Montag, 04.08.03, um 11:41 Uhr (Europe/Berlin) schrieb Olaf Druemmer:
Hi,
there is one thing that has kept chasing me for quite a while now, and
I'd like to share this with you for some possibly interesting
discussion:
Assumptions:
- at least some 'color management' - whether correctly or not - is done
everywhere (and be it only conversion to CMYK or retouching in CMYK of
some image in Photoshop)
- for most documents that get printed on a printing press any necessary
conversion to CMYK or establishment of CMYK values - again: whether
correctly or not - is done early on in the food chain (e.g. by the
designer or layouter, as opposed to the printer)
- in terms of number of different pages produced altogether, more pages
are created by not so professional people but also often printed in
smaller print runs, whereas a comparably smaller number of pages
printed
in higher print runs (magazine/newspaper ads, catalogues, direct
mailing
pieces, packaging, etc.) is typically produced by more professional
people (though your mileage may vary significantly ;->)
- the number of printers (i.e. people/companies running print presses)
is
relatively small when compared to the number of people
creating/producing
pages to be printed on presses.
- the number of people in the graphic arts industry who master color
management (i.e. they get it right nearly all of the time) is
relatively
small; these people are typically more often found down stream in the
food chain, often as staff in high quality prepress service providers
or
prepress departments of larger agencies/industry customers/printers.
- anybody else in the industry - for more than one reason - is having a
hard time getting color management right and getting reliable results
- those professionals mastering color management typically have learnt
that real color management is about process control: know what your
color
will look like, and how to make sure it does look like that in the end
(i.e. after having been printed on the press). They accept that quite
often it might have been possible to get 'better' color, but due to the
fact that under the given circumstances it has not been possible to
predict and control in what way the color would have been better these
people resort to slightly less ideal, but predictable color.
- many other people involved in the graphic arts industry - whether
those
working inside it or those buying its services - are (often
unknowingly)
rather looking for the best possible result. They do not mind if a
repeat
print run looks slightly different as long as it looks 'nice' (though
this is less true for specific colors, e.g. Coca Cola will always want
that their Coca Cola red looks as much the same all the time as
possible).
Conclusions:
- at the moment the majority of people who are (knowingly or
unknowingly)
doing color management (e.g. conversion of a digital camera image from
some kind of ICC based RGB to whatever kind of CMYK, editing of color
in
CMYK on screen, judging color from a color print printed from CMYK
data)
... do no have a clue about color management
... do not have ideal equipment to do color management well
... do not have the means nor the knowledge or experience
to set up equipment for reliable color management
which means this in a way is like asking a deaf person to listen to the
radio and write down what they understood from the broadcast.
- because of files today being often delivered digitally directly from
the creating side to the printing side there are no gateways anymore
as
there were until a couple of years ago in the form of service bureaus
that imaged files onto film and, where desired/required, did analogue
proofs. This hurts some printers more than others: for example,
newspapers are complaining quite often that total ink coverage for ads
is
sometimes too high, the reason being that some image was converted to
CMYK in Photoshop using for example a Euroscale profile.
- one of the reasons printers can nevertheless get their presses going
somehow and can produce more or less pleasant looking results is that
not
so professional people often screw up their data in similar ways (so
certain heuristics, once found, will compensate for similar problems in
most of the files). Nevertheless there are often also pages ending up
on
the same sheet that have significantly different characteristics.
Applying a heuristic to improve one of the pages will deteriorate one
of
the other pages on the same sheet.
- having color management done early on in the food chain by people who
do not master it means that a lot of options to get it right again are
unretrievably lost. If on the other hand files had been left in their
initial color space, more professional people further downstream had
better options to convert images/pages to a more reliable, more
predictable, more easily producible and nicer result.
- also, in terms of overall economy, it is much smarter to have the
fewer
people at printing plants and associated prepress departments/service
bureaus learn to master color management than trying to educate the
masses (whose job description most of the time does not include a bit
about color reproduction as such) towards some pretty complex matter.
Summary:
- prefer digital files with as much device independent color retained
as
possible (though it will always be acceptable if a professional
document
creator submits device dependent CMYK files - they know what they are
doing...)
- establish knowledge and equipment at every printer or at a service
provider associated with every printer that enables the printer to
convert incoming digital files to device dependent data appropriate for
the printing process at hand
- be pragmatic about the strategy: if files seem to come from
professionals, convert 'as is'; if files seem to come from not so
professionals, convert them in a way to make them 'as nice/pleasant as
possible'.
- the ideal format for this is PDF/X-3: it accommodates both device
dependent and device independent data in any combination.
- also, there are now enough decent tools (with varying degrees of
quality and price tag) available - especially iQueue from Gretag
Macbeth,
SuperColor from Heidelberg, Acrobat 6 Professional from Adobe, Quite A
Box Of Tricks from Quite - to easily color convert PDF files to process
specific CMYK.
Essence:
It is not smart to request CMYK files from people who do not understand
color. Instead by default postpone color conversion to CMYK as long as
possible. Promote PDF/X-3 as the natural carrier for digital files that
maintains all options and can handle files from professionals as well
as
from not so professionals.
Olaf Druemmer
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci-en
1:15 p.m.
Hello,
I just recently signed up to this list as I had not been aware of when
the English version became available. An interesting post, and I would
agree that ultimately, this solution would probably be optimal, but
there are some points in which I see difficulty. If I understood
correctly the message, to sum it up, it was that due to the fact that
there are many non-color knowledgeable people at the creative or
beginning end of the production chain, that the best solution is to
maintain RGB data within a PDF/X-3 file format in order for the
knowledgeable to later process as necessary at the end of the line. I
would argue, however, that one needs to have more color knowledge in
order to use an RGB workflow that a CMYK one. If we take a typical user
who may have scanned in an image directly to CMYK and proofed that image
at a service bureau or on an in-house RIP, and done correction for
example, (which is currently pretty common), the chances are quite good
that the print will at least be quite similar to what they were seeing.
To do this same job in RGB, this user must have the knowledge of RGB
working spaces, embedding profiles, setting up the CMYK softproof in
Photoshop and how to proof correctly an RGB image. In this case, then
this user has at least a base of color management. If you add on to
that the ability to create a PDF/X-3 file correctly, then this is not a
"green" uninformed user.
It also appears, and correct me if I did not understand correctly, that
the great part of the problem with the correct reproduction of color
lies with the designers, creatives, photographers, etc. while the
printers and pre-press houses have the know-how to get the job done
correctly. This is often not the case, or at least even in instances
where it is, many times external variables anul this. Blanket or other
mechanical problems, time crunches and the need to get many jobs printed
in a small amount of time, printing without density control, incorrect
proofs due to low-cost solutions or lack of rigorous recalibration,
operator errors, etc, etc. are an everday occurence. So when the
beginning of the chain simply hands off an RGB file for print and
blindly waits for it to print correctly, what do they have to protect
themselves in the event that it doesn't? With a CMYK file and a proof,
there is something to show what should have come out.
Once again, I am well of aware of the workflow you are supporting here,
and I also work generally in the same direction, but it is not as simple
of a solution as it seems, and done too soon, can also be
counter-productive. It is kind of an all or nothing situation -
everyone continues to need to protect themselves until there is a
guarantee that things will be done correctly at the end, and in the
instances that they do not, at least the real reason has to come to
light.
Regards.
Darrian Young
Hi,
there is one thing that has kept chasing me for quite a while now, and
I'd like to share this with you for some possibly interesting
discussion:
Assumptions:
- at least some 'color management' - whether correctly or not - is done
everywhere (and be it only conversion to CMYK or retouching in CMYK of
some image in Photoshop)
- for most documents that get printed on a printing press any necessary
conversion to CMYK or establishment of CMYK values - again: whether
correctly or not - is done early on in the food chain (e.g. by the
designer or layouter, as opposed to the printer)
- in terms of number of different pages produced altogether, more pages
are created by not so professional people but also often printed in
smaller print runs, whereas a comparably smaller number of pages printed
in higher print runs (magazine/newspaper ads, catalogues, direct mailing
pieces, packaging, etc.) is typically produced by more professional
people (though your mileage may vary significantly ;->)
- the number of printers (i.e. people/companies running print presses)
is relatively small when compared to the number of people
creating/producing pages to be printed on presses.
- the number of people in the graphic arts industry who master color
management (i.e. they get it right nearly all of the time) is relatively
small; these people are typically more often found down stream in the
food chain, often as staff in high quality prepress service providers or
prepress departments of larger agencies/industry customers/printers.
- anybody else in the industry - for more than one reason - is having a
hard time getting color management right and getting reliable results
- those professionals mastering color management typically have learnt
that real color management is about process control: know what your
color will look like, and how to make sure it does look like that in the
end (i.e. after having been printed on the press). They accept that
quite often it might have been possible to get 'better' color, but due
to the fact that under the given circumstances it has not been possible
to predict and control in what way the color would have been better
these people resort to slightly less ideal, but predictable color.
- many other people involved in the graphic arts industry - whether
those working inside it or those buying its services - are (often
unknowingly) rather looking for the best possible result. They do not
mind if a repeat print run looks slightly different as long as it looks
'nice' (though this is less true for specific colors, e.g. Coca Cola
will always want that their Coca Cola red looks as much the same all the
time as possible).
Conclusions:
- at the moment the majority of people who are (knowingly or
unknowingly) doing color management (e.g. conversion of a digital camera
image from some kind of ICC based RGB to whatever kind of CMYK, editing
of color in CMYK on screen, judging color from a color print printed
from CMYK data)
... do no have a clue about color management
... do not have ideal equipment to do color management well
... do not have the means nor the knowledge or experience
to set up equipment for reliable color management
which means this in a way is like asking a deaf person to listen to the
radio and write down what they understood from the broadcast.
- because of files today being often delivered digitally directly from
the creating side to the printing side there are no gateways anymore as
there were until a couple of years ago in the form of service bureaus
that imaged files onto film and, where desired/required, did analogue
proofs. This hurts some printers more than others: for example,
newspapers are complaining quite often that total ink coverage for ads
is sometimes too high, the reason being that some image was converted to
CMYK in Photoshop using for example a Euroscale profile.
- one of the reasons printers can nevertheless get their presses going
somehow and can produce more or less pleasant looking results is that
not so professional people often screw up their data in similar ways (so
certain heuristics, once found, will compensate for similar problems in
most of the files). Nevertheless there are often also pages ending up on
the same sheet that have significantly different characteristics.
Applying a heuristic to improve one of the pages will deteriorate one of
the other pages on the same sheet.
- having color management done early on in the food chain by people who
do not master it means that a lot of options to get it right again are
unretrievably lost. If on the other hand files had been left in their
initial color space, more professional people further downstream had
better options to convert images/pages to a more reliable, more
predictable, more easily producible and nicer result.
- also, in terms of overall economy, it is much smarter to have the
fewer people at printing plants and associated prepress
departments/service bureaus learn to master color management than trying
to educate the masses (whose job description most of the time does not
include a bit about color reproduction as such) towards some pretty
complex matter.
Summary:
- prefer digital files with as much device independent color retained as
possible (though it will always be acceptable if a professional document
creator submits device dependent CMYK files - they know what they are
doing...)
- establish knowledge and equipment at every printer or at a service
provider associated with every printer that enables the printer to
convert incoming digital files to device dependent data appropriate for
the printing process at hand
- be pragmatic about the strategy: if files seem to come from
professionals, convert 'as is'; if files seem to come from not so
professionals, convert them in a way to make them 'as nice/pleasant as
possible'.
- the ideal format for this is PDF/X-3: it accommodates both device
dependent and device independent data in any combination.
- also, there are now enough decent tools (with varying degrees of
quality and price tag) available - especially iQueue from Gretag
Macbeth, SuperColor from Heidelberg, Acrobat 6 Professional from Adobe,
Quite A Box Of Tricks from Quite - to easily color convert PDF files to
process specific CMYK.
Essence:
It is not smart to request CMYK files from people who do not understand
color. Instead by default postpone color conversion to CMYK as long as
possible. Promote PDF/X-3 as the natural carrier for digital files that
maintains all options and can handle files from professionals as well as
from not so professionals.
Olaf Druemmer
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.transmedia.de
http://lists.transmedia.de/mailman/listinfo/eci-en
8:04 p.m.
On Monday, Aug 4, 2003, at 13:15 Europe/Copenhagen, Darrian Young wrote:
To do this same job in RGB, this user must have the
knowledge of RGB
working spaces, embedding profiles, setting up the CMYK softproof in
Photoshop and how to proof correctly an RGB image. In this case, then
this user has at least a base of color management. If you add on to
that the ability to create a PDF/X-3 file correctly, then this is not a
"green" uninformed user.
Considering that the ColorSync Users List was still scratching its
scalp in an effort to figure out how the View > Custom > Proof Setup
window worked months after the release of Photoshop 6, this is a
reasonable assessment.
It also appears, and correct me if I did not
understand correctly, that
the great part of the problem with the correct reproduction of color
lies with the designers, creatives, photographers, etc. while the
printers and pre-press houses have the know-how to get the job done
correctly.
US consultants are still recommending to target a profile for the
printer's proofing system on the strength of the argument that printing
processes are too unpredictable. Four years of evangelizing
standards-based printing conditions, and use of characterization tables
in the ICC Registry for printing and proofing profiles, hasn't made a
difference.
There is a massive lack of information on a technology that reaches
ever more deeply into publishing software. Aside from the welter of
settings, the chief problem is the accepted view that workflow
standards and workflow information are commodities and that software
documentation is for the encapsulated functionality only.
Best regards,
Henrik Holmegaard
5:54 p.m.
Darrian Young wrote:
...the message, to sum it up, it was that due to the fact that
there are many non-color knowledgeable people at the creative or
beginning end of the production chain, that the best solution is to
maintain RGB data within a PDF/X-3 file format in order for the
knowledgeable to later process as necessary at the end of the line.
I would argue, however, that one needs to have more color knowledge in
order to use an RGB workflow that a CMYK one. If we take a typical user
who may have scanned in an image directly to CMYK and proofed that image
at a service bureau or on an in-house RIP, and done correction for
example, (which is currently pretty common), the chances are quite good
that the print will at least be quite similar to what they were seeing.
To do this same job in RGB, this user must have the knowledge of RGB
working spaces, embedding profiles, setting up the CMYK softproof in
Photoshop and how to proof correctly an RGB image. In this case, then
this user has at least a base of color management. If you add on to
that the ability to create a PDF/X-3 file correctly, then this is not a
"green" uninformed user.
Is anyone from Hewlett Packard here? It seems to me that their strategy
is that CMYK (or Hexachrome, or an extra grey or pale cyan or whatever)
should all be internal matters to be taken care of inside the printing
machine, and that all printing equipment, from the desktop printer to
the Indigo and who knows how much further, should receive RGB data. In
this case, the user need know scarcely anything at all.
George Battrick
ERA
9:08 a.m.
George Battrick wrote:
Is anyone from Hewlett Packard here? It seems to me
that their strategy
is that CMYK (or Hexachrome, or an extra
grey or pale cyan or whatever) should all be internal
matters to be
taken care of inside the printing machine, and >that all printing
equipment, from the desktop printer to the Indigo and who knows how much
further, should receive >RGB data. In this case, the user need know
scarcely anything at all.
I am not so sure that comparing the technology involved to enhance
inkjet prints is the best example to use for an RGB offset workflow, but
it is interesting that you mention HP. They are one of the few inkjet
manufacturers that take in CMYK data as compared to Epson (RGB), for
example. Example. - Designjet 755, 2500, 5500. And, if I recall
correctly (it has been some time since I have looked), even if you take
an HP10 with the bundled RIP to which you can send RGB or CMYK data, the
default RGB profile does not match the default RGB profile of Photoshop.
Also, HP advocates sRGB and neither ECI-RGB nor Adobe RGB (1998), which
is not a particularly optimal working space for offset. Of course it is
much easier to simply hand-off RGB data and hope that everything comes
out great (no clipping, no loss of gammut, no banding), but the problem
is that invariably people start to ask questions when their beautiful
blues come out flat.
Regards.
Darrian Young
9:34 a.m.
Olaf Druemmer wrote:
......prefer digital files with as much device independent color retained as
possible (though it will always be acceptable if a professional document
creator submits device dependent CMYK files - they know what they are
doing...)
---------------------------------
I see some movements in the market place which support Olaf Druemmer's vision:
Recently our largest customer, a publishing company has decided:
- to switch from a CMYK workflow to an RGB workflow
- to start building an output independent image library of digital photographs and scans
in RGB, TIFF LZW with included ICC source profile
- to switch from Quark XPress to InDesign for several reasons one of them being the more
advanced colormanagement capabilities of InDesign
Of course extra training is needed at the creative side but more and more I see that for
instance photographers are attending workshops and courses to learn the ins and outs of
ICC based colour management.
That is a good sign.
On the other hand I sometimes see quite a lack of knowledge at the printers side where
people like to stick to CMYK workflows just because they do not know how to use the new
workflows and tools or they just do not have the required up-to-date tools.
Some work to do on that side of the chain!
Jo Brunenberg
Logic Use - Roto Smeets
12:43 p.m.
New subject: Re(2): Why be scared by device independent color?
Hello Jo,
jo.brunenberg(a)rsdb.com wrote Thu, 7 Aug 2003 09:34:19 +0200
On the other hand I sometimes see quite a lack of
knowledge at the
printers side where people like to stick to CMYK workflows just because
they do not know how to use the new workflows and tools or they just do
not have the required up-to-date tools.
I agree - and I also wanted to try to repeat that because the number of
printers in the world is much smaller than the number of people creating
documents for print production, it makes more sense to focus on educating
the printers and have them learn how to handle device independent data
and how to get hold of the necessary tools and use them.
A few years ago this would have been so much harder and much more
expensive. Today - especially when focussing on PDF based workflows -
tools have become relatively inexpensive, and sources of education are
more readily available. It may still be challenging here and there, but
it definitely is not rocket science anymore, and would be one of the
smartest investments (in time and money) that a printer could do today
(so we have him still around tomorrow ;->).
Some work to do on that side of the chain!
So let's get started. What would be the best approach to get this going?
How can we make printers hungry for device independent data?
Olaf Druemmer
2:20 p.m.
Olaf Drümmer wrote:
So let's get started. What would be the best
approach to get this going?
How can we make printers hungry for device independent data?
Find customers who are willing to pay them for the extra work they have
to do processing it?
Or persuade the printers that it is actually less work than dealing with
CMYK?
George Battrick
9:18 a.m.
eci-en(a)lists.transmedia.de,Internet writes:
Olaf Drümmer wrote:
> So let's get started. What would be the best approach to get this going?
> How can we make printers hungry for device independent data?
Printers shouls to be explained that if they want to serve their customers in the near
future they will have to learn device independant data workflows because their clients
will demand it.
Best regards,
Jo Brunenberg
2:24 p.m.
New subject: Re(2): Why be scared by device independent color?
Olaf Druemmer wrote:
So let's get started. What would be the best
approach to get this
going? How can we make printers hungry for
device independent data?
That is a good question. It would be necessary to show more revenue,
less waste, faster turnarounds, fewer problems. Not sure that is
necessarily the case at the moment. I would also like to mention the
need for security measures. For a printer to go to device independent
data, he will want to have a way to identify and show (and hopefully
correct) where the problem lies in case the job does not come out right.
It seems this is actually more difficult than when receiving CMYK data.
Regards.
Darrian Young
3:22 p.m.
olaflist(a)callassoftware.com,Internet writes:
So let's get started. What would be the best approach to get this going?
How can we make printers hungry for device independent data?
Olaf Druemmer
Hello Olaf,
In our case as printers we want to go the "device independant color route"
because some of our clients need it as they want to build device independant image
libraries and want to supply us device independant PDF's.
And...the client is leading...
In the prepress we have noticed a quality and efficiency improvement using profile-to
profile conversions instead of letting scanner operators fiddle around with settings when
producing CMYK scans.
Best regards,
Jo Brunenberg
4:50 p.m.
On Thursday, Aug 7, 2003, at 15:22 Europe/Copenhagen, Jo Brunenberg
wrote:
In the prepress we have noticed a quality and
efficiency improvement
using profile-to profile conversions instead of letting scanner
operators fiddle around with settings when producing CMYK scans.
May I ask a question: How do you organize image sharpening on the
document level?
Among the objections to an RGB document workflow often listed are (1)
different separations for different objects in the page are desirable
and (2) different sharpening for different printing processes is
desirable.
I seem to remember checkboxes for sharpening in some production RIP
interfaces, but never got round to investigating.
Thanks,
Henrik
9:24 a.m.
Hello Henrik,
Concerning: USM in an RGB workflow.
We do not yet have a good solution for this.
All scans are made at approx. A4 size. Sharpening has to be done after sizing of the image
for a specific document.
It currently is done in Photoshop by visual judgement.
Do you know of any automated solution?
Best regards,
Jo Brunenberg
eci-en(a)lists.transmedia.de,Internet writes:
On Thursday, Aug 7, 2003, at 15:22 Europe/Copenhagen,
Jo Brunenberg
wrote:
In the prepress we have noticed a quality and
efficiency improvement
using profile-to profile conversions instead of letting scanner
operators fiddle around with settings when producing CMYK scans.
May I ask a question: How do you organize image sharpening on the
document level?
Among the objections to an RGB document workflow often listed are (1)
different separations for different objects in the page are desirable
and (2) different sharpening for different printing processes is
desirable.
I seem to remember checkboxes for sharpening in some production RIP
interfaces, but never got round to investigating.
Thanks,
Henrik
10:02 a.m.
Am Montag, 11.08.03 um 09:24 Uhr schrieb Jo Brunenberg:
Concerning: USM in an RGB workflow.
We do not yet have a good solution for this.
All scans are made at approx. A4 size. Sharpening has to be done after
sizing of the image for a specific document.
It currently is done in Photoshop by visual judgement.
Do you know of any automated solution?
Hello Jo, in ColorBlind Edit there is a functionality to apply
sharpening in batch-processing. It works a little bit rudimentary (but
on L only), so the better way is you might use PhotoShop actions to
apply automated sharpening (and colortransformation as well).
Regards, Andre
9:28 a.m.
Andre,
Thanks!
We are actually using Photoshop actions for colortransformations but for USM it is tricky
to use actions because sometimes incoming RGB files have alrady USM applied (by the
photographer) Sometimes not. So visual judgement still is needed i.m.o.
Best regards,
Jo Brunenberg
eci-en(a)lists.transmedia.de,Internet writes:
Hello Jo, in ColorBlind Edit there is a functionality
to apply
sharpening in batch-processing. It works a little bit rudimentary (but
on L only), so the better way is you might use PhotoShop actions to
apply automated sharpening (and colortransformation as well).
Regards, Andre
10:03 a.m.
Am Dienstag, 12.08.03 um 09:28 Uhr schrieb Jo Brunenberg:
So visual judgement still is needed i.m.o.
Yes it is. Even if the data source is always the same (same scanner
with same settings for example) there can be need for individual
image-sharpening - hair can have more than skin. But that is why we
aren’t ruled by the machines yet, right? :-)
Regards, Andre
10:14 a.m.
Am Montag, 11.08.03 um 09:24 Uhr schrieb Jo Brunenberg:
Do you know of any automated solution?
BTW, sharpening on some images tends to be an individual progress. So
if one needs absolute fine adjustments, there won’t be any automated
solutions. But this is not different to than it was before and will not
change - this is a general issue and not directly related to device
independent workflows.
We handle this by applying basic sharpness to the device independent
reference data with the intention to individually apply additional
sharpness if required. So we can always go back to a reasonable
starting point with individual further adjustments.
Regards, Andre Schützenhofer
1:27 p.m.
On Monday, Aug 11, 2003, at 09:24 Europe/Copenhagen, Jo Brunenberg
wrote:
Concerning: USM in an RGB workflow.
We do not yet have a good solution for this.
All scans are made at approx. A4 size. Sharpening has to be done after
sizing of the image for a specific document.
It currently is done in Photoshop by visual judgement.
Do you know of any automated solution?
Hello Jo,
The RIP I was referring to was Fuji Celebrant. It appeared to have a
checkbox for sharpening, but I didn't investigate.
Henrik
4:55 p.m.
Am Donnerstag, 07.08.03 um 15:22 Uhr schrieb Jo Brunenberg:
olaflist(a)callassoftware.com,Internet writes:
>
> So let's get started. What would be the best approach to get this
> going?
> How can we make printers hungry for device independent data?
Olaf,
I completely agree with your statements. We run a device independent
workflow in reproduction since a couple of years now and noticed large
increasement of quality and efficiency. Jo's reply is highly
significant, because pushing things to the limit is situated in the
nature of device independent workflows. Once they are established they
provide us with high levels of consistency and predictability.
In order to support this statement I will reply to answers of your
first post.
------------------------------------------------------------------------
Am Montag, 04.08.03 um 13:15 Uhr schrieb Darrian Young:
I am well of aware of the workflow you are supporting
here,
and I also work generally in the same direction, but it is not as
simple
of a solution as it seems, and done too soon, can also be
counter-productive.
IMO, the specification of PDFX3 combines perfectly traditional working
principles with advanced and device independent workflows. To postpone
CMYK as long as possible does not mean to prevent it in any case. The
way we talk about media neutral data means at the moment: preferably a
3-channel colorspace which is big enough to cover ideally all
outputspaces. If we would have a CMYK-colorspace which is big enough to
cover most other spaces, it would become kind of device-independent in
this meaning.
One unitary device independent colorspace increases compatibility and
gives less transformation needs (plus other major advantages of
RGB-spaces, like perfect gray balance).
From this viewpoint, in a sense it does not really matter which kind of
colorspaces are in PDFX3 - we only have to take care of the right
choice in correct rendering to the output intent.
This sounds too easy to be possible, but in fact today's workflow-tools
are sophisticated enough to allow this on a high professional level.
PDFX3 gives us all options - completely CMYK or completely RGB or
completely mixed, preferably device independent. No reason to be scared.
------------------------------------------------------------------------
Am Montag, 04.08.03 um 12:14 Uhr schrieb kk_cs:
But even working in RGB requires a basic knowledge of
color
management, color models and the concept of a working space - along
with a calibrated and profiled system. Otherwise " if files seem to
come from not so professionals, convert them in a way to make them 'as
nice/pleasant as possible'" will result in a try and error method that
is neither productive nor will it result in a consistant color >
quality.
In a well calibrated and profiled working environment handling of all
kinds of files becomes easier than it first looks like. There are two
eventualities: 1 - profiles are attached knowingly or 2 - not.
In the first case, everything is fine - we are able to convert the data
to where we want to, including leaving it as is.
In the second case, all we have to do is to assign a profile which
looks good on monitor or proof (in a well profiled and calibrated
working environment we naturally do not need to hardproof the file
first, because the monitor shows us what we will get).
The process of decision works simple: if there is no profile attached
or obviously a wrong one, we do not assume that the creator of this
file really expects that the outcome will be exactly like anything he
saw on his equipment. So he will be satisfied with a pleasing look. We
never had real problems from that with proofed or printed data, because
in the mind of them only the proof shows what they will get - and that
is what we give them.
(BTW, a obviously wrong attached profile happens seldom. If we receive
data with SWOP or ToyoInks from germans, the data normally has been
created with this settings in for example Photoshop - therefore, the
right profile has been attached to the data. With this knowlegde, we
can make the right decisions to handle these files.)
I think to teach principles like this to printers and reproduction
companys might be workable.
------------------------------------------------------------------------
Am Donnerstag, 07.08.03 um 15:22 Uhr schrieb Jo Brunenberg:
In the prepress we have noticed a quality and
efficiency improvement
using profile-to profile conversions instead of letting scanner
operators fiddle around with settings when producing CMYK scans.
This is very true. :-)
------------------------------------------------------------------------
Am Donnerstag, 07.08.03 um 14:20 Uhr schrieb George Battrick:
Find customers who are willing to pay them for the
extra work they have
to do processing it?
Or persuade the printers that it is actually less work than dealing
with
CMYK?
If we do our work well with showing them they can in fact save costs,
increase and secure quality and efficiency to an undeniable improvement
regarding knowledge and image as well - they will. There are a lot of
advantages appearing after implementation which we can point out.
Regards, Andre Schützenhofer
9:09 a.m.
Hello,
Very interesting post. There are a few things I would like to ask
about, however.
Andre Schützenhofer wrote:
We run a device independent workflow in reproduction
since a couple
of years now and noticed large increasement of quality and
efficiency.
Are you a print house? Great that you have been able to implement such
a workflow since a couple of yearas ago. What percentage of your
clients would you estimate give you RGB PDF/X-3 documents? Or in the
case that you are a prepress house, what percentage of printhouses ask
you for RGB PDF/X-3 documents?
From this viewpoint, in a sense it does not really
matter which kind
of colorspaces are in PDFX3 - we only have to take care of the
right
choice in correct rendering to the output intent.
This sounds too easy to be possible, but in fact
today's workflow-tools
are sophisticated enough to allow this on a high
professional level.
Are you saying that you are using some application that makes on-the-fly
decisions about whether to use a RelCol or Perceptual trasnfomation
depending on the image? If you don't mind divulging secrets, I would be
very interested to know.
PDFX3 gives us all options - completely CMYK or
completely RGB or
completely mixed, preferably device independent. No reason to be
scared.
I definitely agree - we currently set up CMYK PDF/X-3 workflows and it
works very well.
The process of decision works simple: if there is no
profile attached
or obviously a wrong one, we do not assume that the creator of this
file
really expects that the outcome will be exactly like
anything he saw
on his equipment. So he will be satisfied with a pleasing look.
As you mention, when an image comes in with an incorrect profile or no
profile, a decision must be made using the monitor output as to which
profile to assign - and there are not so many choices as it may seem at
first (usually three or 4 at most) But, it is not so easy to know what
is pleasing. If you are fotunate and have images with known colors or
people in them, for example the decision is usually much easier but this
is often not the case. Ex. Images from art books (of course with an
abstract painting just about anything could be "pleasing" or not
"pleasing"), fashion shots - many times the photographer is looking for
a mood depending upon the type of clothes the advertising is aimed at
(greenish skintones, or for the younger generation, very dark images
which have almost no shadow detail). Assigning a profile with a 1.8
gama, for instance, looks much more "pleasing", but is incorrect.
Furniture - the wood tones change greatly depending upon whether sRGB or
Adobe RGB is assigned.
We never had real problems from that with proofed or
printed data,
because in the mind of them only the proof shows what they will get -
and that >is what we give them.
You have not had problems with your proof being substantially different
from some other place the client may have gone before or after your
site?
Can you explain, also, what security measures you employ with RGB images
when the results are not what the client expected?
Regards.
Darrian Young
3:02 p.m.
At 08:09 08/08/2003, Darrian Young wrote:
This kind of on-the-fly decision would mean that you are not making PDF/X-3
compliant output. One of the main points of the PDF/X standards is to
ensure maximum similarity between output of the same file on different
sites, using different equipment. You can only do that by making the same
decisions about rendering intent at every site, and the way the standard
requires you to do that is to use the intent selected in the file (or using
the PDF default).
Despite many discussions with lots of people I still don't really
understand the value of a CMYK-only PDF/X-3 workflow. If you want CMYK only
isn't it easier to ask for PDF/X-1a? That's simpler to describe and simpler
to configure the tools for.
The only half-way sensible reason for CMYK-only PDF/X-3 that I've heard is
that people want to use device independent colour spaces for the alternate
colour space of spot colours - the idea being that they're likely to get
proofed more accurately on a CMYK proofer. I still have serious concerns
about this workflow because there's nothing to stop a designer creating a
file with 'spot' colours that should be converted to CMYK for the press.
Then you have device independent objects in something that's nominally
CMYK-only, and sooner or later you'll get bitten by colours that are
supposed to be identical in different objects not matching on the final print.
Avoiding that issue just makes the description of how a designer should
make a good file more difficult again.
Regards
Martin Bailey
-------------------------------------------------------------
Senior Technical Consultant +44 1223 873800
Global Graphics Software http://www.globalgraphics.com
Developers of Harlequin, Jaws, Jaws PDF & MaxWorkFlow
martin.bailey(a)globalgraphics.com
-------------------------------------------------------------
If my views didn't usually coincide with those of my employer
I wouldn't want to work here, but I am not a spokesman for
Global Graphics Software
and the buck stops with me for what I say.
-------------------------------------------------------------
From this
viewpoint, in a sense it does not really matter which kind of
colorspaces are in
PDFX3 - we only have to take care of the right
choice in correct rendering to the output
intent.
This sounds too easy to be possible, but in fact
today's workflow-tools
are sophisticated enough to allow this on a high
professional level.
Are you saying that you are using some application that makes on-the-fly
decisions about whether to use a RelCol or Perceptual trasnfomation
depending on the image? If you don't mind divulging secrets, I would be
very interested to know. PDFX3 gives us
all options - completely CMYK or completely RGB or
completely mixed, preferably
device independent. No reason to be scared.
I definitely agree - we currently set up CMYK PDF/X-3 workflows and it
works very well.
9:12 a.m.
New subject: Why be scared by device independent color? (Martin Bailey)
Hello,
Hope everyone had a good vacation.
Martin Bailey wrote:
>At 08:09 08/08/2003, Darrian Young wrote:
>Are you saying that you are using some application that makes
>on-the-fly
>decisions about whether to use a RelCol or Perceptual trasnfomation
>depending on the image? If you don't mind divulging secrets, I would
be
>very interested to know.
This kind of on-the-fly decision would mean that you
are not making
PDF/X-3
compliant output. One of the main points of the PDF/X standards is to
ensure maximum similarity between output of the same file on different
sites, using different equipment. You can only do that by making the
same
decisions about rendering intent at every site, and the
way the
standard
requires you to do that is to use the intent selected
in the file (or
using
the PDF default).
If we finally do get some sort of intelligent best image conversion
method engine, then I am sure this would have to change. The simple
fact that the PDF/X standard specifies that a certain RI has to be used
shows that this is a real problem area - different RIs can give very
different and very poor results. If a technology evolves which can
solve this, then this would become a non-issue and the 4 choices could
even disappear from the user-interface altogether (at least in basic
mode). This is presently one of the main stumbling blocks in automated
workflows.
> > PDFX3 gives us all options - completely CMYK
or completely RGB or
> completely mixed, preferably device independent. No reason to be
> scared.
>
> I definitely agree - we currently set up CMYK PDF/X-3 workflows and
> it
> works very well.
Despite many discussions with lots of people I still
don't really
understand the value of a CMYK-only PDF/X-3 workflow. If you want CMYK
only
isn't it easier to ask for PDF/X-1a? That's
simpler to describe and
simpler
to configure the tools for.
Not really. What often happens in discussions about CMYK or RGB
workflows is that it is usually supposed that if you mention CMYK
somewhere, then this means that you are going into this space from the
start. With the exception maybe of legacy scanners, many workflows are
actually mixed, and the conversion from RGB to CMYK may happen anywhere
along the chain. Maybe the following example could explain better. An
editorial which captures digitally has RGB input. The images are then
optimized, retouched, etc. in RGB and left there. Page layout also is
done with the RGB images, although there might be some CMYK images as
well which could come from other sources. Once the layout is done, the
PDF can be created, and this PDF, usually X-3, then is ready to go
anywhere. As the usual final destination is a web offset press, the PDF
is then given to iQueue and converted to CMYK for proofing and sent
along with the proof to the print shop. If, in the future, the RGB
chain could be extended to the print shop, or in the case of the PDF
going somewhere other than to web offset, then it is a simple decision
of not sending it to the iQueue queue. X-3, I think, gives greater
flexibility in this respect.
My understanding of the original part of the thread was that it referred
to the whole workflow, but in particular to the part of data exchange
between prepress and press, for example, where PDF comes into play. At
this part of the chain, I do not see any overwhelming benefits of
maintaining RGB data, and at the same time there are many disadvantages,
and hence the reason I maintain (IMO) that it should be CMYK for this
stage of the process.
The only half-way sensible reason for CMYK-only PDF/X-3
that I've heard
is
that people want to use device independent colour
spaces for the
alternate
colour space of spot colours - the idea being that
they're likely to
get
proofed more accurately on a CMYK proofer. I still have
serious
concerns
about this workflow because there's nothing to stop
a designer creating
a
file with 'spot' colours that should be
converted to CMYK for the
press.
Then you have device independent objects in something
that's nominally
CMYK-only, and sooner or later you'll get bitten by colours that are
supposed to be identical in different objects not matching on the final
print.
I am not really sure I followed you here. I don't understand the need
for the document to have device independent color to proof spot colors
correctly. A good proofing software will have its database of the
necessary (CMYK, CcMmYKk, etc.) values to give the closest reproduction
possible of the spot color whose name it picks out during processing.
Could you explain bit more what you mean here?
Regards.
Darrian Young
9:16 a.m.
Jo Brunenberg wrote:
In the prepress we have noticed a quality and
efficiency improvement
using profile-to profile conversions instead >of letting
scanner
operators fiddle around with settings when producing CMYK scans.
Hello,
Would you mind explaining a bit more? When you mention profile to
profile, do you mean RGB or does that also include scanner RGB profile
to CMYK print profile? Also, when scanning using profile conversions,
do you mean that the operator not allowed to "fiddle around". My
experience has been that the best combination is scanning software that
is ICC compatible (like Linocolor) which increases quality and
efficiency as you mention, but at the same time allows the scanner
operator to make to necessary corrections and adjustments during
scanning, whether in RGB, CMYK or L*a*b*. Thanks.
Regards.
Darrian Young
12:48 p.m.
Hi,
I would like to highlight a couple of important issues in this very
interesting discussion:
(1) There is rarely such a thing as a wrong ICC profile
3:50 p.m.
Hello,
Yes, it is a very interesting discussion. Just a thought before
vacation.
Olaf Druemmer wrote:
(1) There is rarely such a thing as a wrong ICC profile
From my point of view (similar to what Andre
Schuetzenhofer stated)
there is never a 'wrong ICC profile' attached >to
an image (or some
other object, or a whole page). Instead, the only question is whether
one likes what an image >looks like. The end result counts, not how you
get there.
Not so sure I agree here. Take an image, convert to WideGammut RGB and
assign sRGB. Now, correct the image with curves, levels or any other
tool to get it to what you think it should be looking like. Then
compare to a duplicate of the original image without retouching, simply
assigning WideGammut RGB. A very large chance that the results are
better by simple assigning the "correct" profile, and no chance that now
the two images are alike. If you don't like the idea that sRGB was
wrong here, maybe we can agree that WideGammut RGB is more right. This
situation happens every day in a large number of service bureaus. Due
to a lack of knowledge, no effort is made to respect embedded profiles,
or to find a "pleasing" one, and so the operator simply selects "no
color management" and hence uses probably sRGB (if he hasn't changed
Photoshop) for incoming RGB images, and marvels at how unsaturated
digital camera images are.
Let me elaborate:
If I grab some image from the internet or some photo CD that does not
have any
source profile associated with it, >and I then open it in e.g.
Photoshop, knowingly or not associating an ICC profile with it, and I
like what it
looks like or tweak it until I like the way it looks,
and then e.g.
save as TIFF or JPEG or Photoshop file w/ICC
profile or PDF - then this is all just fine. It does
not matter whether
I understand a single bit of color
management of know what an ICC profile is.
I don't think it is just fine to have an image with a jagged histogram
due to unnecesary edits. We are also supposing here that this probably
non-color savvy user is making these decisions and edits with a
perfectly calibrated display. I prefer to tell photographers to never
ever send off an image without the "correct" profile if they want to
have any chance of seeing a result comparable to what they saw on their
own screen. I believe that the person most qualified to make the
judgement regarding the pleasantness of an image is the one who created
it.
(4) The image/page looks awful...
... and you have decided this is meant to look nicer
than that. Well -
tweak it. If you have the customer around, >ask him whether he
likes it.
If you cannot reach him easily, trust your own judgement.
Dangerous territory here - let's take two examples. 1. The print comes
out poorly or better stated, the customer is dissatisfied. You printed
the image as is, and so if this customer does not like it, you could say
with cause that you printed what he gave you. 2. The customer is once
again dissatisfied. In this case you have modified their file to make
it more pleasing according to your criteria. You are definitely
responsible here because you have modified his data. If you are going
to trust your judgement in this way, you had better hope that you both
have the same tastes.
If the print run is expensive, insist that the customer
signs off a
proof or even a test print run.
Excellent advice.
(5) How often is a page in need of (color) tweaking?
This is an area where I am not very sure. I believe
that a lot of pages
get created from office applications, and >sending them to
press as they
are often results in less than perfect results (e.g. the bright blue on
screen most >of the time looks to much pink/purple on press). I believe
one could develop a default strategy for this type of
jobs (and get the bright blue as well as other colors)
right (or at
least such that the customer likes it).
With a spot color?
Conclusion
To make this very long story short: Leaving aside the
professionals
(a.I) who anyway know what they are doing, for >everybody else and
for
print content created by anybody else, life will be much easier if
content stays in
whatever RGB as long as possible, and if already
associated with ICC
profiles - the better. If an image/a page
looks good, there is no problem to be solved - nobody
should care which
profile if any was used to get there. Last >but not least,
forcing
people who do not have a clue about prepress or color management to
convert their print
content to CMYK is simply not a very smart approach.
There is a very important turn here which I think needs mentioning:
"forcing people to convert to CMYK". The only time there is
"forcing"
involved is when going to RGB, not CMYK. I suppose countries may vary,
but the great majority of images, files, etc. which go to print go in
CMYK and have been for years. I prefer to educate, and then implement
color management and a workflow in CMYK, in which the customer has been
working for quite some time. This way they can start in color
management and with workflow, which is quite a load for some, and once
that is stable, then to continue to evolve to RGB - and I can say, it
has worked for me. This evolution, however is not so easy as it
involves everyone along the chain as has been mentioned here in the list
several times. To go into a prepress house, for example and force them
to RGB without taking into account where these files will be printed
will inevitably cause more problems than it solves.
PS: In a perfect world we'd have a flag in every
PDF/X file stating
"This file has been created by a real
professional who knew what he/she was doing". But
then - who would want
to submit a file with this flag not set...
Speaking of PDF, you mentioned the vast majority of unskilled people who
are involved in the creation, edition, etc of pages and hence why they
should not be concerned with color management. Who is going to create
the PDF/X files?
Regards.
Darrian Young
4:46 p.m.
On Friday, Aug 8, 2003, at 12:48 Europe/Copenhagen, Olaf Drümmer wrote:
From my point of view (similar to what Andre
Schuetzenhofer stated)
there
is never a 'wrong ICC profile' attached to an image (or some other
object, or a whole page). Instead, the only question is whether one
likes
what an image looks like. The end result counts, not how you get there.
Hmm ...
The consumer of a printed publication never gets to see the original.
The consumer gets to see multiple reproductions of the original. And
probably does not notice discrepancies unless the image is run in
multiple national newspapers, for instance.
Because images are edited with the photographer's monitor as reference,
the press operator has no everyday concept of what the color should
look like. This is defined by the tagged RGB working space and not by
what the press operator thinks, as Martina Stahl up at Prinfo once said.
Which all boils down to the observation that people who make their
money on images, and the people who buy these images, are the ones
driving color management. Which again boils down to the observation
that photographers took the lead from the very beginning.
Because its their . . . . on the line -:).
It does not matter whether I understand a
single bit of color management of know what an ICC profile is.
Right, scratching music is not the same as playing the original musical
score, assigning profiles is not the same as preserving intended color
appearance. But where is this taking us . . .
(2) Let's have a statistic excursion...:
(a) looking at the population of all print content creators (from hobby
artists to secretaries to freelance graphic designers to magazine
layouters to very highly skilled prepress specialist) I'd say that
(a.I) very few (definitely below 5 %, my personal estimate though would
say below 1 %) understand prepress in general and color management
specifically, and master both.
Yes, but the people using these products do care or they wouldn't buy
into the concept of preserving color appearance. True, they are a very,
very small group in the huge color market. But they pay for the
software and hardware development that makes the whole discussion
relevant in the first place.
(d) I dare to say that for many reasons we will never
manage to educate
the majority of 95 % or 99 % of people who are print content creators.
That's what defaults are for. They are what the manufacturer believes
the user should confidently rely upon. Defaults need much stronger and
more structured backing, but that has been said very loudly and very
publically before.
Is there an insurance against making the wrong
decision? No (at least
none that I know of ;->). If it is an expensive print run, have the
customer sign off professionally created proofs. If it is a relatively
inexpensive print run, learn to live with the risk (will be less
expensive in the long run than being too wary).
Right, shorter runs implies lower risks implies less fretting and
fussing. Point also hit on by Laurel Brunner. You are both right, of
course.
life will be much easier if content
stays in whatever RGB as long as possible, and if already associated
with
ICC profiles - the better.
Absolutely.
If an image/a page looks good, there is no
problem to be solved - nobody should care which profile if any was used
to get there.
No. No again. And no once more, just to be on the safe side.
The ICC framework is based on the concept of the device profile. The
user self-configures, self-calibrates, self-characterizes and
self-profiles the devices in her studio, plugs into the connection
space, and simulates the devices (: printing processes, film recorders,
whatever) she does not have in her studio.
Try the playing-it-by-chancing-it pitch in the PhotogamutRGB.icc
thread. Personally, I wouldn't have the temerity -:).
Last but not least, forcing people who do not have a
clue
about prepress or color management to convert their print content to
CMYK
is simply not a very smart approach.
Absolutely.
But then again Kodak, Apple, PhotoDisk, Heidelberg . . . everybody and
her neighbour specified color in deviceCMYK for all marketing until
recently, and some probably still do for all I know. It's about putting
one's mouth where one's money is to some extent -:).
Thanks,
Henrik
1:35 p.m.
New subject: Re(2): Why be scared by device independent color?
Hi,
henholm(a)post2.tele.dk wrote Fri, 8 Aug 2003 16:46:07 +0200
but here is a fat wave coming our way: digital cameras, alreayd now or
within in very short time the source of way over 90% of all images. A
digital typically does not give us CMYK files, but rather RGB files of
some kind. Even if most often sRGB is used (which admittedly and rightly
so is not a prepress pro's darling) this is not that bad for non-
professional and semi-professional work. Let's get to a situation where
these image files are left as they are - ICC profiled RGB files.
Olaf Druemmer
Last but not
least, forcing people who do not have a clue
about prepress or color management to convert their print content to
CMYK
is simply not a very smart approach.
Absolutely.
But then again Kodak, Apple, PhotoDisk, Heidelberg . . . everybody and
her neighbour specified color in deviceCMYK for all marketing until
recently, and some probably still do for all I know. It's about putting
one's mouth where one's money is to some extent -:).
5:53 p.m.
New subject: Re(2): Why be scared by device independent color?
On Saturday, Aug 9, 2003, at 13:35 Europe/Copenhagen, Olaf Drümmer
wrote:
but here is a fat wave coming our way: digital
cameras, alreayd now or
within in very short time the source of way over 90% of all images. A
digital typically does not give us CMYK files, but rather RGB files of
some kind. Even if most often sRGB is used (which admittedly and
rightly
so is not a prepress pro's darling) this is not that bad for non-
professional and semi-professional work. Let's get to a situation where
these image files are left as they are - ICC profiled RGB files.
Right, currently ICC solutions don't work for and are not applied to
digital camera captures. These captures are managed by assigning a
reasonable RGB working space and making them look good in this space,
using the preview on the calibrated and characterized monitor.
But how many professional photographers base their business on digital
cameras? Split the message into a professional and a prosumer /
consumer dimension, and it works. Merge the message leaving only the
prosumer / consumer dimension, and it doesn't work. At least IMHO.
Thanks,
Henrik
9:32 a.m.
Hello Darian,
Our workflow:
We scan in RGB, have profiled the scanners for transmission and reflection copy.
In scanning only white and blackpoint arec set. No further editing in the scanner
software.
Later the RGB scans are converted into CMYK using the scanner source profile and offset or
gravure target profile.
This workflow results in rather good "facsimile reproduction".
If corrections are needed because of deficiancies in the original or because of
"creative reasons" we correct the RGB scan in Photoshop before converting in
CMYK.
Best regards,
Jo Brunenberg
eci-en(a)lists.transmedia.de,Internet writes:
Jo Brunenberg wrote:
In the prepress we have noticed a quality and
efficiency improvement
using profile-to profile conversions instead >of letting
scanner
operators fiddle around with settings when producing CMYK scans.
Hello,
Would you mind explaining a bit more? When you mention profile to
profile, do you mean RGB or does that also include scanner RGB profile
to CMYK print profile? Also, when scanning using profile conversions,
do you mean that the operator not allowed to "fiddle around". My
experience has been that the best combination is scanning software that
is ICC compatible (like Linocolor) which increases quality and
efficiency as you mention, but at the same time allows the scanner
operator to make to necessary corrections and adjustments during
scanning, whether in RGB, CMYK or L*a*b*. Thanks.
Regards.
Darrian Young 
1:48 p.m.
New subject: Re(2): Why be scared by device independent color?
Am Donnerstag, 07.08.03, um 12:43 Uhr (Europe/Berlin) schrieb Olaf
Drümmer:
So let's get started. What would be the best
approach to get this
going?
How can we make printers hungry for device independent data?
I know many printers who reject under the existing circumstances
working with device independent colour. Some print houses even are not
willing to publish characterisation data of their printing conditions.
To my mind there are two major reasons for this behavior:
1. Actual many print houses reject the responsibility for a publishing
obligatory printing conditions, because it seems to be a right-free
area. So they fear complaints. Under the existing circumstances it
seems to be more safe and easier to work with device dependent data. If
there will be an agreement about the responsibilities of the working
process in general, perhaps more print houses loose their fear to deal
with colour management and device independent data. I think, it will be
very important to reach also the little and middle size print houses
and not only the major players in printing business. So federations
like e. g. FOGRA in Germany, should try to set up these circumstances.
A campaign like publishing the "ProzessStandard Offsetdruck" (rules for
standardisation of working process) perhaps will help to get many
people interested in dealing with this methods of working.
2. Easier tools in workflow tools, more control and more online
connection to the press machines in print houses. To my mind the
concept of a big press machine manufacturer to define the colour
management starting at the press in print houses and not in prepress
workflow will be the right way to get many printers dealing with colour
management. If their consultants will do a good job in teaching them
who to apply these techniques, they will get hungry sooner or later.
Best Regards,
Karsten Ackmann
**************************************************
Reproduktion Onnen & Klein GmbH & Co. KG
Karsten Ackmann · Geschäftsführer
Neumann-Reichardt-Str. 27-33 / Haus 11
D-22041 Hamburg (Wandsbek)
Telefon: ++49 (0) 40 / 65 68 58 57
Telefax: ++49 (0) 40 / 65 68 58 11
mailto:ackmann@reproduktion-hamburg.de
http://www.reproduktion-hamburg.de
DFÜ: ++49 (0) 40 / 65 73 10
(Leonardo, 4Sight ISDN-Manager, Eurofile)
*************************************************
5:21 p.m.
New subject: Re(2): Why be scared by device independent color?
On Sunday, Aug 10, 2003, at 13:48 Europe/Copenhagen, Karsten Ackmann
wrote:
1. Actual many print houses reject the responsibility
for a publishing
obligatory printing conditions, because it seems to be a right-free
area. So they fear complaints.
Back before the FOGRA Media Wedge was what it has become there were
requests not to publish proof to print tolerances as tight as dE 3.
The spectrophotometer is both a boon and a bane. It helps take the Mac
to the media, but at the same time it makes the media fear the Mac as
paying customer.
Thanks,
Henrik
10:13 a.m.
On Thursday, Aug 7, 2003, at 09:08 Europe/Copenhagen, Darrian Young
wrote:
They are one of the few inkjet
manufacturers that take in CMYK data as compared to Epson (RGB), for
example. Example. - Designjet 755, 2500, 5500.
True, but the DesignJet pipeline has several safeguards against a CMYK
workflow, including the UseCIE architecture which is leveraged to
reseparate incoming deviceCMYK (by assigning a ToCIE reference to the
deviceCMYK object).
And, if I recall
correctly (it has been some time since I have looked), even if you take
an HP10 with the bundled RIP to which you can send RGB or CMYK data,
the
default RGB profile does not match the default RGB profile of
Photoshop.
As far as I remember AdobeRGB(1998) is installed. In all fairness Adobe
also allows multiple default RGB working spaces, one of which is sRGB
and another AdobeRGB(1998).
Also, HP advocates sRGB and neither ECI-RGB nor Adobe
RGB (1998), which
is not a particularly optimal working space for offset. Of course it
is
much easier to simply hand-off RGB data and hope that everything comes
out great (no clipping, no loss of gammut, no banding), but the problem
is that invariably people start to ask questions when their beautiful
blues come out flat.
One may argue that sRGB is even less optimal for inkjet presentation
prints where the maximum gamut available is desired. But the DesignJet
pipeline does not impose any hardwired restriction on the addressable
gamut. It is not the case that every incoming RGB object is assumed to
be sRGB which would mean that nothing the user might do would allow the
printing system to address the maximum gamut of the colorant and media
combination.
However, the problem remains that one has to assign defaults to
untagged device RGB or accept a PostScript level 1 RGB to CMYK
conversion . . . ugh. The UseCIE procedure listed above for device CMYK
objects also applies to device RGB objects.
Some years ago when what was then Purup-Eskofot was introducing the New
Age workflow, the developers were scratching their scalps over which
RGB working space to set as default for the CTP system. It's
everybody's headache -:).
I guess the question is whether inkjets should be receiving CMYK,
because in the majority of cases the incoming CMYK is targetted for
newsprint, offset or gravure with ink limit and black generation
behaviours that are not so great on an inkjet system. Which is why
UseCIE procedures allow in-RIP reseparation.
Thanks,
Henrik
2:14 p.m.
Henrik Holmegaard wrote:
However, the problem remains that one has to assign
defaults to
untagged device RGB or accept a PostScript level 1 RGB to CMYK
conversion . . . ugh. The UseCIE procedure listed above for device CMYK
objects also applies to device RGB objects.
Thank you Henrik - I would like to translate the above into Spanish and
run it across a number of non-color knowledgeable users and see if it is
as easy as it sounds ;-).
Regards.
Darrian Young
2:32 p.m.
On Thursday, Aug 7, 2003, at 14:14 Europe/Copenhagen, Darrian Young
wrote:
I would like to translate the above into Spanish and
run it across a number of non-color knowledgeable users and see if it
is
as easy as it sounds ;-).
I realized after writing it that it fell a bit to the left of center.
Just an itsy bitsy bit, mind you -:).
Seriously, one of the ideas that came up a little over two years ago in
the ECI was something like a list of the concepts that carry the ICC
framework. This wasn't intended to have a graphical dimension, though.
Joseph Holmes is quite right that understanding how intents are linked
on the fly into a virtual color network where the RGB original stays
RGB and CMYK is built on demand / on the fly is much easier to
understand when a graphics system is involved.
So let's see what rabbits are in the hat to get this done in a short
and sweet space, given that the main thing is to get enough people to
understand the benefits of an RGB workflow that they stop trying to
hobble the press operator with miscellaneous CMYK.
Hmm . . . maybe a little shorter and a little sweeter than Martin
Bailey's PDF/X piece -:).
Thanks,
Henrik
1:11 p.m.
Hello,
in my opinion the conditions for data exchange between pre-press and
press houses have to be clearly defined for working with device
independent colour. I think that at the moment there is a lack of
transparency, which working steps are necessary in processing device
independent colour.
I agree with the posting of Karl Koch. The "basic knowledge of color
management, color models and the concept of a working space" has to be
learned by all people working at the production chain. To my mind
colour management has to be seen more as a sub process of a production
process. The understanding of the complete production process would
help to set up the necessary standards for working with independent
colour. Standardisation campaigns of national and international
federations like FOGRA, ECI, and others will help to publish new
techniques.
If the work at the educational standard of people at the production
chain will be continued, I think in future, anybody would be scared by
working with device independent colour. Hopefully, there are enough
people to carry out this fastidious task.
The PDF/X-3 standard has so much publicity at the moment, but many
media agencies and press houses still want to receive open data instead
of PDF-Files. Perhaps we should be able to have a little more patience.
Best Regards,
Karsten Ackmann
____________________________________
Reproduktion Onnen & Klein GmbH & Co. KG
2:56 p.m.
Am Freitag, 08.08.03 um 13:11 Uhr schrieb Karsten Ackmann:
The "basic knowledge of color management, color
models and the concept
of a working space" has to be learned by all people working at the
production chain.
Right. But at the moment, statements like this can easily be misused by
some people who want to AVOID learning colormanagement and its
principles - too difficult, time-consuming, why not leaving everything
like it is and so on.
I think we need a clear vision. We need to point out the advantages
that agencies, photographers, prepress companys, printers and
consumer/clients can profit from, and this means colormanagement in
general.
Best regards, Andre Schützenhofer
4:37 p.m.
Am Freitag, 08.08.03, um 14:56 Uhr (Europe/Berlin) schrieb Andre
Schützenhofer:
Am Freitag, 08.08.03 um 13:11 Uhr schrieb Karsten
Ackmann:
There are always people, who have problems by learning and practising
now methods or techniques. If I want to convince them to ignore their
doubts, it is necessary to give them comprehensive Information about
the advantages, but also about the requirements.
The major point is, how this information is given to the target group.
If federations or experts are publishing manuals, which nearly
everybody could understand, in my opinion many people will try working
in device independent colour. To my mind, nobody will be encouraged to
use colour management by reading the e. g. the ICC-Specs. I think, we
need manuals and material for exercises, which are easily to
understand. This will help. According to my experiences most people
want to understand and use colour management. So why shall I conceal
the requirements for working with device independent colour or colour
management in general?
Best regards,
Karsten Ackmann
**************************************************
Reproduktion Onnen & Klein GmbH & Co. KG
Karsten Ackmann · Geschäftsführer
Neumann-Reichardt-Str. 27-33 / Haus 11
D-22041 Hamburg (Wandsbek)
Telefon: ++49 (0) 40 / 65 68 58 57
Telefax: ++49 (0) 40 / 65 68 58 11
mailto:ackmann@reproduktion-hamburg.de
http://www.reproduktion-hamburg.de
DFÜ: ++49 (0) 40 / 65 73 10
(Leonardo, 4Sight ISDN-Manager, Eurofile)
*************************************************
The "basic knowledge of color management,
color models and the
concept of a working space" has to be learned by all people working
at the production chain.
Right. But at the moment, statements like this can easily be misused
by some people who want to AVOID learning colormanagement and its
principles - too difficult, time-consuming, why not leaving everything
like it is and so on.
I think we need a clear vision. We need to point out the advantages
that agencies, photographers, prepress companys, printers and
consumer/clients can profit from, and this means colormanagement in
general.
5:21 p.m.
On Friday, Aug 8, 2003, at 16:37 Europe/Copenhagen, Karsten Ackmann
wrote:
I think, we need manuals and material for exercises,
which are easily
to understand.
In the traditional desktop publishing book, you document a single
software application.
Because ICC color management is a workflow technology, you will not get
beyond thinking about such a project unless you take a decision to
document specific products, complete with user interface settings and
the inevitable bugs upstream / downstream that affect workflow
strategies. Which is why the fora of the traditional prepress and
printing magazines failed in their early efforts to support this
technology while the on-line fora in the US succeeded. They don't care
about political correctness, they only care about utility. It's the
McDonald's and Levi's approach to mass education: If it wears and
tastes OK, who cares if it's politically correct -:).
Thanks,
Henrik
4:58 p.m.
On Friday, Aug 8, 2003, at 13:11 Europe/Copenhagen, Karsten Ackmann
wrote:
The "basic knowledge of color management, color
models and the concept
of a working space" has to be learned by all people working at the
production chain. To my mind colour management has to be seen more as
a sub process of a production process.
Amen to that.
Regardless of how many characterization charts are printed and
averaged, a process which is not controlled cannot be color managed.
The problems on the production side of the fence can't be addressed by
ICC color management, averaging features in software, spot spectros,
strip spectros, x-y spectros or any combination thereof
nothwithstanding.
Thanks,
Henrik
8:10 p.m.
Bye the bye, just as ICC color management essentially cannot address
the problems on the production side of things, it also cannot in and of
itself address the problems on the creative side of things.
There is always the same fly in the ointment. The idea of a three
channel workflow with tagging of the source profile is a weakness
compared to an L*a*b* workflow with an LCh interface.
First, there was the DIN D65 / ANSI D50 issue. Then there was the 8 bit
/ 16 bit issue. But from a workflow point of view the fact that,
(1) RGB working spaces can be renamed by the user
(2) RGB working spaces can be omitted in the file
(3) RGB working spaces are an ever changing battleground for the ideal
archival space
still indicates that the original decision to base desktop workflows on
monitor profiles and synthetic monitor profiles was not good thinking
IMHO.
Thanks,
Henrik
3:35 p.m.
On Monday, Aug 4, 2003, at 11:41 Europe/Copenhagen, Olaf Druemmer wrote:
Nevertheless there are often also pages ending up on
the same sheet that have significantly different characteristics.
Applying a heuristic to improve one of the pages will deteriorate one
of
the other pages on the same sheet.
The good thing about a PDF/X-3 workflow with RGB device to CMYK device
profiles is that ink limiting and black generation is the same for all
objects in the page, in the document, and in the imposition. No need to
worry about whether to favour advertising or favour editorial in the
press run. Without density control in the separations there is no color
control on the press, either. Because there is a clean division of
labour and division of responsibilities between the page designer and
the press operator, the RGB model is the nicest and safest, if as
Darrian wrote the page designer and press operator know the basics of
an RGB workflow.
In the early ICC implementation period from 1996 to 2000 when the
industry was shifting from the idea of targetting proofing systems to
the idea of targetting press printing conditions, there was a concept
of separating to no more than a score of reference printing conditions
in the prepress stage. In the printing stage the CMYK document would be
reseparated using a device link to the house printing condition. This
idea is still alive and seems to drive demands for special processing
solutions. People who advocate device links need to read / re-read the
ICC Specification IMHO. What is often overlooked is that device links
may not be embedded and are thus incapable of supporting an
object-oriented color management model, or even a document color
management model.
Best regards,
Henrik Holmegaard
7557
days inactive
7580
days old
eci-en@lists.callassoftware.com
41 comments
10 participants
participants (10)
-
Andre Schützenhofer -
Darrian Young -
George Battrick -
Henrik Holmegaard -
Jo Brunenberg -
Karsten Ackmann -
kk_cs -
Martin Bailey -
Olaf Druemmer -
Olaf Drümmer