Hallo Eci-mailing-list members,
I have encountered a problem with a PDF/X-3 (2002) file which I was
trying to print with an offset printing house.
Embedded in this PDF file are several RGB and CMYK files with their
profiles. The PDF should have been separated by the RIP of the
printing house to their output profile by IN-RIP-Separation.
Unfortunately only the RGB files where printed correctly (according
to the proof) but not the CMYK pictures. The printing house told me,
that these CMYK files where not converted by their RIP because only
one kind of files can be put into a PDF X-3 file (RGB or CMYK but not
both of them simultaniously).
The PDF was created by indesign (CS 3) by the direct export function
(!! not by creating a postscript file and then distilling it to a
PDF!!). The PDF file had pictures in RGB and CMYK with their single
profiles embedded. Afterwards I made a preflight test with Adobe
Acrobat (CS3) and it found no problems with that file (Konform. PDF/
x-3:2002). Output - intend: ISO-coated. All pictures where nicely put
in the PDF file: RGB with their RGB profiles and CMYK pictures with
their Cmyk-profiles.
I proofed the PDF file with GMG (ColorProof 4) sending the pdf file
to the rip (ColorProof also) and then printed it with the ISO coated
profile on GMG Paper. Everything was fine and showed like the
softproof in Indesign, Acrobat or PS.
Does somebody have any idea what could be the problem or if maybe the
printing house is wrong.
If it is true, that it is not possible to have both RGB files and
CMYK files together in one PDF x-3 file, then why Acrobat gives no
error message after the preflight??
Thank you very much for any suggestions.
Best regards
Norbert Heyl
STUDIO NORBERT HEYL
Norbert Heyl, Dipl. Volksw.
Düsseldorf: Tel. +49 (0) 211 934 77 51
Fax. +49 (0)211 5448800
Venezia: Tel/Fax. +39 041 520 2434
Mobile (D): +49 (0) 171 126 30 97
Mobile (IT): +39 348 6936970
info(a)norbertheyl.com
info(a)colibrimarketing.com
AIM: norbertheyl
Skype: norbertheyl
www.norbertheyl.comwww.colibrimarketing.com
Postal addresses:
Studio Norbert Heyl
Germany: Birkenhof 7, D-40225 Düsseldorf
Italy: Dorsoduro 2212, I-30123 Venice
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this e-
mail. Any unauthorized copying, disclosure or distribution of the
material in this e-mail is strictly forbidden.
Hi Morgan,
I just finished a project to "harmonize" all incoming files for a sheet fed
offset printer.
It's based on a Heidelberg/Callas/Alwan workflow and the TAC for uncoated
is max. 260% and
the TAC for coated is max. 300%. Even the 320% files (regular ISOcoated)
get a TAC/GCR treatment.
The GCR is just a little bit higher than the ECI-conditions.
The printers and the finishing guys love it.
By the way, for rich black backgrounds (photo magazine) they use K 100%, C
50%, M 40% and Y 40%.
Total 230% for coated and K 95%, C 40%, M 30% and Y 30% for uncoated.
Totals 195%.
The images in the black background improve a lot.
In the past they used just 100K without any addition of color.
That's a to high contrast with regular images. (100% versus 300%).
Trapping (knockouts etc) have to be OK.
On a 70 x 100 cm machine and good paper/shop conditions this is no problem.
Henk
At 14:41 14-3-2008 +0100, you wrote:
>We are using "Binuscan PDF Server" and converting ISOuncoated (320) 2 to
>Press-profile with TIC@250 (delta E 1).
>Works great!
>
>/ Magnus
>
>
>14 march 2008 14:31 wrote Jo Brunenberg:
>
>>Concerning: TAC of ISOuncoated profile
>>
>>Following the question of Morgan I have a question as well on this subject:
>>
>>- Is the present TAC value in the ISOuncoated profile (320%) acceptable
>>for sheetfed offset printers? As Morgan states that it is too high for
>>his press room I am wondering what are the experiences of other sheetfed
>>offset printers?
>>- By the way: We are using a modified version (TAC 240%) of this profile
>>for web offset.
>>
>>Best regards,
>>Jo Brunenberg
>>ROTO SMEETS
>>
>>
>>
>><mailto:eci-en@lists.callassoftware.com>eci-en(a)lists.callassoftware.com,Internet
>>writes:
>>
>>Message: 2
>>Date: Wed, 27 Feb 2008 11:11:40 +0100
>>From: Morgan Axelsson
>><<mailto:morgan.axelsson@atta45.se>morgan.axelsson(a)atta45.se>
>>Subject: [ECI-EN] Uncoated paper in Sheetfed enviroment
>>To: <mailto:eci-en@lists.callassoftware.com>eci-en(a)lists.callassoftware.com
>>
>>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
Concerning: TAC of ISOuncoated profile
Following the question of Morgan I have a question as well on this subject:
- Is the present TAC value in the ISOuncoated profile (320%) acceptable for sheetfed offset printers? As Morgan states that it is too high for his press room I am wondering what are the experiences of other sheetfed offset printers?
- By the way: We are using a modified version (TAC 240%) of this profile for web offset.
Best regards,
Jo Brunenberg
ROTO SMEETS
eci-en(a)lists.callassoftware.com,Internet writes:
>
>Message: 2
>Date: Wed, 27 Feb 2008 11:11:40 +0100
>From: Morgan Axelsson <morgan.axelsson(a)atta45.se>
>Subject: [ECI-EN] Uncoated paper in Sheetfed enviroment
>To: eci-en(a)lists.callassoftware.com
>Message-ID: <F5356E56-606F-4BDA-878B-0B966260F9BB(a)atta45.se>
>Content-Type: text/plain; charset="iso-8859-1"
>
>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
Yes you will get closer, but then look into the drying properties and perfecting possibilities.
Rgs Lance
Kind Regards
Lance Blizzard
07919335060
----- Original Message -----
From: eci-en-bounces(a)lists.callassoftware.com <eci-en-bounces(a)lists.callassoftware.com>
To: eci-en(a)lists.callassoftware.com <eci-en(a)lists.callassoftware.com>
Sent: Fri Mar 14 09:31:49 2008
Subject: Re: [ECI-EN] SunChemicals - PSOExact
Thanks Lance,
Conventional inks yes.
Higher dE compared to what other inks?
I guess that if you got dE within the tolerances using the World Series, there should be even better dE with the PSOExact series.
Lars
Den 14. mars. 2008 kl. 10.27 skrev Lance Blizzard:
Hi Lars,
I have done internal tests on 4 different inks including SUN and although SUN inks were slightly higher (delta E) they still came well within the ISO 12647-2 tolerances. The series I used was World Series. I take it we are talking about conventional inks?
Regards
Lance.
On 14/3/08 07:53, "Lars Jacobsen" <lars.j(a)merkurtrykk.no> wrote:
Hello,
Do to some not-important reasons we need to change inks. Today we use K+E Novavit Supreme Bio from a pumping system and we are considering a moveover to SunChemicals.
Are there anyone out there with experience on Sun Inks and hitting the ISO12647-2/Amd1 targets?
I have heard some rumors about the Yellow giving to high A values (orange), while the Target is towards green (A-6). I have tried to read a bit and understand that Sun has two different Yellows, one that hit the ISO target easily and one that is more orange.
Any other experiences considering the colors behavior are very welcome to be shared (trapping, drying, perfecting etc.).
Thanks!
1x SM102 8p
2x CD102 4
ImageControl
EyeOnePro
Lars Jacobsen
________________________________
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.callassoftware.com
http://lists.callassoftware.com/mailman/listinfo/eci-en
The contents of the e-mail and any transmitted files are confidential and intended solely for the use of the individual or entity to whom they are addressed. AGI Media Packaging Europe Limited and subsidiary companies hereby exclude any warranty and any liability as to the quality or accuracy of the contents of this email and any attached transmitted files. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited.
AGI Media Packaging Europe Limited, Drayton House, Drayton, Chichester, West Sussex PO20 2EW. Registered in England No. 948696.
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.callassoftware.com
http://lists.callassoftware.com/mailman/listinfo/eci-en
The contents of the e-mail and any transmitted files are confidential and intended solely for the use of the individual or entity to whom they are addressed. AGI Media Packaging Europe Limited and subsidiary companies hereby exclude any warranty and any liability as to the quality or accuracy of the contents of this email and any attached transmitted files. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited.
AGI Media Packaging Europe Limited, Drayton House, Drayton, Chichester, West Sussex PO20 2EW. Registered in England No. 948696.
Hello,
Do to some not-important reasons we need to change inks. Today we use K
+E Novavit Supreme Bio from a pumping system and we are considering a
moveover to SunChemicals.
Are there anyone out there with experience on Sun Inks and hitting the
ISO12647-2/Amd1 targets?
I have heard some rumors about the Yellow giving to high A values
(orange), while the Target is towards green (A-6). I have tried to
read a bit and understand that Sun has two different Yellows, one that
hit the ISO target easily and one that is more orange.
Any other experiences considering the colors behavior are very welcome
to be shared (trapping, drying, perfecting etc.).
Thanks!
1x SM102 8p
2x CD102 4
ImageControl
EyeOnePro
Lars Jacobsen
My simple premise is that the legacy 1.8 and 2.2 gamma for displays
and working spaces are flawed (no one's fault really) in that these
functions do not match with human vision. Clearly many of the color
management experts are correct in that the ICC process will iron out
these issues, and that with 16 bit images it's a mathematical moot
point. However in my personal opinion as a digital photography
specialist, the gamma gradations in working color spaces and displays
have resulted in tremendous confusion for end users. The decisions by
ECI and ISO should be applauded as these organizations have introduced
a sound, logical improvement that will allow digital photography and
printing to mature to new levels of consistency worldwide.
I think what we are experiencing in these forum discussions is a
gradual process of people trying to grasp these changes as they have
become accustomed to one way of working and thinking for over a more
than a decade-especially in the US where for some reason people feel
that Adobe could do no wrong.
In the L* based workflow a physical 50L (the middle of the LAB model)
is mapped to 128,128,128 (the middle of the digital RGB model) When
the display is also calibrated to L* there is a wonderful 1:1:1
relationship. Sure ICC moves tones around to make all this work in
other environments such as Adobe RGB/2.2 Gamma, but my feeling is that
we are over-relying on math to fix tonal relationships that could be
correct from the start. I am not a color scientist, or a math genius,
but I would prefer a process that requires the least alteration
through the workflow. And as a photographer, I respect the nature of
human vision.
In 1999 I was involved in a project at the Metropolitan Museum of Art
where we needed to photograph the famous Unicorn Tapestries in
extremely high resolution. Using a Leica scan camera suspended on an
overhead rig these artworks were photographed in 3X3' tiles. The
resulting data was so large that we could not assemble the full
resolution images, but the artworks were only available for two weeks
to be photographed. Several years later with the help of some
mathematicians and the use of their super computer we were able to
assemble the data. Here is the interesting thing and why I bring this
up: every single piece of equipment used on this project is long since
obsolete the top of the line Macintosh workstation is most probably in
a junkyard in the US somewhere, the Leica camera was long since
discontinued. Photoshop is many versions newer, but many of the core
flaws in Photoshop still exist from over a decade ago. On the positive
side, If we photographed the Unicorn tapestries today we could capture
higher resolution images and with a loaded computer and the photomerge
function of photoshop we could perform the assembly on the desktop.
The work a decade ago at the Met Museum and the media exposure of the
project may have inspired Adobe to add the photomerge funtion so in
many ways everything is inter-connected.
NOVA | scienceNOW | Profile: Brothers Chudnovsky | PBS
If you look at this whole experience from the point of view of the
artwork on a timeline of hundreds of years. The entire digital
revolution is simply a tiny moment in the life of these incredible
artworks. While all of that computer equipment is gone, the Unicorn
Tapestries are still hanging on the wall for all to see. So for those
that have gotten so involved with computers that Apple, Adobe and
Microsoft have become your primary reality, I suggest that you go to a
museum and look at the incredibly powerful things people have created
without the crutch of technology. After spending time in front of art
objects that are hundreds of years old, you realize that the computer
at best can only simulate reality, and that as humans we can only
experience images with our eyes (so far). Photography has always been
a curious mixture of science and art, and the methods of photography
also predate computers by many many years. The LAB color model also
began to form up over a hundred years ago. The way I look at this
particular moment in the history of imaging, is that the technology
has just started to mature and the ECI/ISO standards are one of the
first steps of that process. The sooner we learn to respect the work
of people in the past, the sooner we will enjoy the benefits of the
digital age. There are unlimited possibilities that computers offer
that have yet to be explored but it is always good to take a step back
and take a fresh look.
Scott Geffert
Hi Lars,
After the firestorm of controversy my ISO standards document has
created in the US this artwork of Cai Guo-Qiang sums up how I feel at
the moment. The tiger on the left is me, notice arrows are in my back.
The Tiger on right is USA arrows into the ECI/ISO tiger. The question
is why all the violence?
But seriously, thanks for contacting me. I am glad to speak with
someone from Adobe on this topic. Several people have pointed out
quite bluntly some of my reasonings in the document are flawed
however, your discussion regarding HDTV does not seem to directly
relate to the end user experience that we were testing. This was
specifically high-end digital still cameras, off-the-shelf Macs and
PC's running Adobe Photoshop, Calibrated displays (1.8/2.2/L*), ink
jet printers, proofers, and printing presses using ICC color
management and the various working spaces.
After taking the same exact calibrated digital captures and targets
though various capture applications to 16bit tiff files of various
working spaces, the results were improved using the L* based eciRGBv2
working space. To be clear, as the document states, the differences
were minimal, but nonetheless they are apparent to all who have
reviewed the work. The testing also indicated that the press dot gain
and tonal compression were areas to investigate further. The document
was not put out to discredit any person of company, but it was an
attempt to take a look back at how we came to where we are today, and
where we are going in the future when it comes to digital workflow and
standards.
I did not create the eciRGBv2 working space nor did I vote on the ISO
standardization, but every test I have performed indicates that it
(and especially the L*) takes care of problems that have confused
users for years. What gamma do I calibrate to? What working space
should I use? How do I expose a digital camera? These are very simple
questions to answer if we agree on the fact that the only way humans
can interact with digital information is through our analog senses
(until someone invents a direct neural implant-welcome to the
matrix!). The ISO adopting these standards will go a long way to help
the community agree on the tonal relationships of a digital image and
will go a long way to stabilize the foundation of what we consider a
digital image.
Try a simple experiment. Send 100 random photographers a simple Kodak
Q-14 scale and ask them to photograph it and send you the files. What
do you expect to get back? I expect that you will end up with a bell
shaped curve meaning that the process is pretty much chance-governed
(I learned this at RIT as a student years ago). But this is a shame
because with digital cameras and great tools like Camera RAW users
should be able to achieve much better results with any DSLR or studio
digital camera. Now do the same test, but tell the user to select
eciRGBv2 working space (even though they currently cannot in ACR) and
to expose the chart to a middle gray value of 128 and neutralize. The
results would begin to look much better. Lastly, ask them to select
eciRGBv2 working space, then to create a custom ICC profile. The
consistency would be better yet with just a few simple steps. Of
course there is no built-in profiling in ACR, but just imagine the
possibilities. If Adobe is not interested in this level of
granularity, just let X- Rite or others provide plug-ins for this
capability. The bottom line is that users can have a fighting chance
to create fantastic repeatable images with only a few simple steps.
This would far easier than the current slider based camera calibration
functions in ACR. Of course any working space could be used, but the
various gamma gradations of each working space make RGB readouts
confusing. 118 for Adobe 100 for ProRGB etc. This is why the eciRGBv2
makes so much sense to me. there is a 1:1 relationship form capture to
working space to display at the core. In 8 or 16 bit the less tones
are altered the better. No one has been able to clearly articulate a
good argument for AdobeRGB other than that it is widely used and that
is bears the name Adobe.
What can Adobe do?
If Adobe simply added support for eciRGBv2 in Lightroom and
distributed it's own internal space of lightroom (supposedly a linear
version of ProPhotoRGB) users could make their own choices as to what
standards they wish to use and Adobe could be considered a participant
in the worldwide movement towards open standards. It would also be
helpful for Adobe to decide to use similar RGB readouts in all
applications and to support custom camera profiling. These few
additions are all quite easy to integrate for Adobe, but will go far
to help the user experience.
Your email is very thought provoking and I appreciate the insight,
but what are you suggesting is the ideal environment? Adobe RGB? sRGB?
XVYCC? or is it Bruce RGB?
As far as the $30,000 HDTV display goes, I suggest that one would
simply calibrate it to L* so the image will match the same image
displayed in Adobe Photoshop on your Mac or PC calibrated to L*. It's
just so simple.
You should read some of the early works of Albert Munsell (see
attached 1901 patent) I feel that photographic exposure is closely
linked to the LAB model and both are closely linked to human
perception. If I build a replica of this device, I can almost
guarantee that if I put a 50L patch in the unit, the needle will line
directly up with the middle of the LAB scale. In terms of output for
museums, we would love to see exact copies or at least have the
opportunity to experience what that looks like! If a user sees exact
copies of artworks and is not happy the user can use the extensive set
of Adobe tools to take it wherever they choose. I do not know if the
goal of standards or software should be to improve on reality as
baseline, I think users are more than capable of making those creative
decisions from a well-defined consistent starting point.
I f you really honestly care about this topic and want to help, ask
John Nack if you could get on a plane to New York and and spend a day
with me at the Met Museum. I guarantee that if we met in person with a
few folks from Adobe, you will see right away what we are striving
for. My only goal has been to open a dialog. Boy have I opened a dialog!
Thanks,
Scott
On Mar 11, 2008, at 10:29 PM, Lars Borg wrote:
> Scott,
>
> L* is great if you're making copies. However, in most other
> scenarios, L* out is vastly different from L* in. (This is sometimes
> known as rendering.) And when L* out is different from L* in, an L*
> encoding is very inappropriate as illustrated below.
>
> Although it's sometimes meaningless to use L* for colors on set, let
> me provide an example for video. Let's say you have a Macbeth chart
> in the studio and it's lit perfectly for this case, so L* measures
> 96 for the whitest patch. On set, the six gray patches would measure
> around L* 96, 81, 66, 51, 36, 21. (Note that I didn't tell you the
> color temperature of the studio lights.)
>
> Assuming the camera is Rec.709 compliant, using a 16-235 digital
> encoding, and the camera is set for the exposure of the Macbeth
> chart, the video RGB values would be 224,183,145,109,76,46.
>
> Displaying this video on a calibrated $30,000 reference HD TV
> monitor should reproduce these patches at L* 95.5, 78.7, 62.2, 45.8,
> 29.6, 13.6.
> If say 2% flare is present on the monitor (for example at home), the
> projected values would be different, here: 96.3, 79.9, 63.8, 48.4,
> 34.1, 22.5.
>
> As you can see, L* out is clearly not the same as L* in.
> This is sometimes called the system gamma, and this is a required
> feature of the video reproduction pipeline, and follows
> international standards from ITU and IEC.
> Except for copiers, a system gamma greater than 1 is a required
> feature (for user acceptance) for all image reproduction systems
> aiming to please human eyes. For example, film still photography has
> a much higher system gamma than video.
>
> Now, if you prescribe an L* encoding for the video, which set of
> values would you use:
> 96, 81, 66, 51, 36, 21 or
> 95.5, 78.7, 62.2, 45.8, 29.6, 13.6 or maybe
> 96.3, 79.9, 63.8, 48.4, 34.1, 22.5?
> Either is wrong, when used in the wrong context.
> If I need to restore the scene colorimetry for visual effects work,
> I need 96, 81, 66, 51, 36, 21.
> If I need to re-encode the HD TV monitor image for another device,
> say a DVD, I need 95.5, 78.7, 62.2, 45.8, 29.6, 13.6.
>
> In this context, using an L* encoding would be utterly confusing due
> to the lack of common values for the same patches. Video solves this
> by not encoding in L*. (Admittedly, video encoding is still somewhat
> confusing. Ask Charles Poynton.)
> Similar examples can be made for print.
>
> When cameras, video encoders, DVDs, computer displays, TV monitors,
> DLPs, printers, etc., are not used for making exact copies, but
> rather for the more common purpose of pleasing rendering, the L*
> encoding is inappropriate. And as noted above, this is reflected in
> current international standards.
> Further, as most combinations of displays and printers (regardless
> of TRC) make for very poor copying systems (they mismatch in gamut,
> dynamic range, viewing conditions, etc.), the L* encoding remains
> equally inappropriate here.
>
> Maybe you are constructing a copying system?
>
> Lars Borg
>
> --
> Lars Borg
> Principal Scientist
>
> Adobe Systems Inc.
> 345 Park Avenue
> San Jose, CA 95110-2704
> Phone 408 536.2723
> Fax: 408 537.4068
> borg(a)adobe.com
> http://www.adobe.com
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ken, Jan-Peter,
for the conventional printing Chris's arguments against L* are correct.
The TRC with a gamma of 1.8 is closer to print output with a more or
less linear behavior. This results in a lower loss of digital values
when converting from one to the other.
For the output on conventional monitors the opposite is true. A gamma of
2.4 can be called the typical characteristic of a monitor and that is
where the gamma actually comes from (see
http://www.poynton.com/GammaFAQ.html for more details).
All the photographic output devices have a logarithmic behaviour similar
to that of a monitor when exposing to photographic silver halide material.
The other printing technologies are somewhere between these extreme
behaviors. A good working space has to serve all these different kinds
of applications.
On the other hand the main thing we are talking about is images that are
made for and meant to be viewed by a human observer. Therefore the
natural approach would be to store the image in an encoding that is
close to human perception if that does not conflict with the output
devices. What all the postings on the Color Sync, ICC, and ECI website
are about is the problems in the dark area which is the weak point of
most linear output processes.
If you look at the encoding of the dark areas which you can find in the
attached "gamma visualization" you will see that the L* characteristics
is a good compromise between a 1.8 and a 2.2 gamma. This means it serves
all the output processes equally well and provides the ideal solution
for human perception.
I have noticed a lot of passion in the argumentation on the different
lists. To be honest my opinion is that if you have a preprocessed image
that has all major tonal and color corrections applied and your output
referred 8 Bit working space is not too big it does not really matter
what gamma you use. You will not get a bad output depending on your
choice of gamma in the region between 1.8 and 2.4 or L*.
I do not see the benefit of a ProStarRGB because this space is too big
to be used in 8Bit encoding and for 16 Bit it really does not matter
which luminance approach you take.
And Chris, it does not really make a big change in workflow if you use
eciRGBv1 or eciRGBv2 does it? That is why ECI recommends to keep v1
images in the existing space and not converting it to v2. Even if you
convert you will not notice a loss in quality. If you are in favor of v1
keep it. If you like the L* approach better you can use that one as
well. We had both sides on the ECI committee and had to decide which way
we proceed for the standardization process and the majority was in favor
of the more universal L* idea. I do not see a need to change that
decision which was reached after 2 years of discussion at a time where
the L-star approach was already very popular in Germany and parts of
Europe. You will neither get worse nor better images by selecting one or
the other working space.
Best regards
Dietmar
Image Engineering
Dietmar Wueller
Augustinusstr. 9d
50226 Frechen
Germany
phone +49 2234 912141
fax +49 2234 912142
d.wueller(a)ivent.de
www.image-engineering.de
Hello list,
On several public and one ICC internal mailinglist, I monitored
discussions about L* based RGB workingspaces like e.g. eciRGBv2, ISO
22028-4 and L* based monitor calibration. See also http://www.eci.org
The idea behind L* based RGBworkingspaces is a perceptual uniform
encoding of ligthness. Equal steps in RGB in an L* based workingspace
are leading to visual equal steps. As the profile connection space
between ICC profiles is mostly Lab (for LUT-profiles...), profile
conversion from an L* based workingspace to the PCS and from there to an
L* calibrated output device will avoid unnecessary tonal conversions,
especially for 8-Bit data.
We have now several vendors of high-end monitors and high end monitor
calibration / profiling solutions offering L* based monitor-calibration,
which are used in eciRGBv2 workflows especially in Germany in the area
of post production for photography and prepress.
In the netherlands, the center for digital imaging posted a paper for L*
/ ISO 2208 based workflows in digital imaging for museums and archives.
You can find the paper here:
http://www.cdiny.com/ArticlesWhitePapers/ISO%20Standards%20for%20Museum%20I…
They created also L* based version of the ProPhotoRGB called ProStarRGB.
It is available as opensource at
http://www.cdiny.com/color_profiles.html
They decided to use this profile, because modern Inkjet printers and
glossy photopapers have in the dark areas often a bigger colorgamut as
eciRGBv2 or AdobeRGB.
A strong opinion against L* based workingspaces and outputput
calibration comes from the well known color expert Chris Murphy. He
states, that the "native Gamma" or native tone reproduction curve of
printing processes is better represented by a Gamma of 1,8 and not of L*.
But till today, he has not pointed to scientific research, to verify
this statement.
My personal view on this topic:
The L* based concept for an RGB workingspace makes the most sense, if we
have also L* based monitor- AND printer calibration.
I agree that eciRGBv2 is not an option for high-end retouche and color
correction of master files, when also the output on wide gamut inkjet
printers is an option.
(eciRGBv2 is fine for prepress with targeting offset printing). So I
think the initiative for ProStarRGB makes a lot sense and should be
integrated into ISO 22028
We still need more research about the native tone reproduction curves of
printing processes like e.g. ISO 12647-2 / FOGRA-data, G7, standard
inkjet drivers, or standard settings of digital printing systems.
Comments are welcome
Jan-Peter
- --
*********** Neue Adresse / new adress ************
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Christinenstr. 21 ------ http://www.colormanagement.de
10119 Berlin -------- mailto:homann at colormanagement.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH1rfD7Olj94xfLY4RAs9LAKCpNSc/wtcEM6eFI16/LECIR4qYOgCglrpG
zoOofKkBwSt2v+5FIvBdlEU=
=s7n5
-----END PGP SIGNATURE-----
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 will be out of the office starting 07/03/2008 and will not return until
25/03/2008.
I'm currently out of the office on 2 weeks paternity leave returning to the
office on Wednesday the 26th March.
Your UK contacts in my absence will be -
Phil Deane
Email: philip.deane(a)rrd.com
Office: +44 (0)1423 796440
Steve Fisher
Email: stephen.fisher(a)rrd.com
Office: +44 (0)1423 796107
Many thanks,
Regards, John.
