You are right regarding images But with respect to company colors defined as cmyk independant rgb- or lab-values absolute colorimetric conversions sometimes make sense. Though LAB seems to be the best choice it's not in daily production for two reasons LAB suffers from the 8-bit quantization limitation and the fact that more and more people are used to work in RGB (but not in LAB). Therefore people will define these colors as rgb-values in order to get a perfect match to the same color in an image. The more people learn to use the advantages of device independant color definitions the more white point issues will become an issue. For the time beeing it's just a topic of theoretical Florian Am 08.12.2003 um 19:50 schrieb Chris Murphy: -- Florian Suessl | Director Technology MetaDesign AG | Leibnizstrasse 65 | 10629 Berlin +49 30 590 054 246 | fax +49 30 590 054 114 | fsuessl(a)metadesign.de A Lost Boys company | http://www.metadesign.de

Am 09.12.2003 um 17:35 schrieb Chris Murphy: As mentioned in the thread with Darrian it's not that much a technological or quality question. And the advantage of using the right white point. With respect to gamut mapping no profile can be perfect. As long as gamut mapping does not take into account the individual source gamut we will always see problems in certain areas. Gamut mapping takes place in the printer profile coming from the PCS assuming a source gamut set by the profiling software - regardless whether the source was Adobe RGB, ECI-RGB or whatsoever. Adobe RGB is even smaller than print - e.g. ISO Coated exceeds the gamut in yellow, magenta and red plus green to cyan - not that good, isn't it I agree with respect to raising problems caused by large gamuts. That's why CIELAB does not work as 8bit - and for the same reason wide gamut RGB would be no good choice as well. BUT Some digital cameras have a larger gamut than ECI-RGB! Why should one want to shrink ECI-RGB? -- Florian Suessl | Director Technology MetaDesign AG | Leibnizstrasse 65 | 10629 Berlin +49 30 590 054 246 | fax +49 30 590 054 114 | fsuessl(a)metadesign.de A Lost Boys company | http://www.metadesign.de

On tirsdag, dec 9, 2003, at 23:48 Europe/Copenhagen, Chris Murphy wrote: Stock agencies including PhotoDisc migrated from small gamut to medium gamut source spaces in the initial ICC implementation phase for Photoshop. ColorMatch RGB is suitable for low gamut offset lithographic printing, but not for high gamut offset lithographic printing or inkjet presentation printing. For instance, BASF specificies ECI-RGB as the only way to reach the achievable colors in its high gamut process. If Florian doesn't mind, maybe a rephrasing as per past ECI discussions : Scanning into 8 bit Lab is a proven workflow as any Linocolor user knows, editing in 8 bit Lab may or may not cause artifacts depending on the contents of the image and other factors. Thanks, Henrik

Hi... Thomas Richard wrote: I think you are confusing displayed values in dialogs with internal encoding. I'm not a Linocolor user, so I'm probably the wrong person to say this. But my impression was: - Linocolor uses LCH values for editing, yes. But there is no 8-bit quantisation of L, C, H values themselves. An 8-bit quantisation of H would be rather coarse (a-b-wise) at high chroma... though one probably wouldn't notice :-) - LCH is converted from and to Lab values. When stored as pixel values, Lab is encoded in 8 bits per channel. The particular encoding used is called LabLH and uses a smaller range for a and b than the usual -128..+127. You're right that this wastes less 2-d encoding space, but I'm sure that there are still quite a few non-realizable colors (presumably mainly in the green-blue and violet region due to the square shape of the a-b region). Even with a cylindrically shaped LCH, you would have unused space outside the "sort-of double-cone" gamut of surface colors. (wasn't there a 16-bit mode? just without saving as 16-bit Lab Tiffs because of shortcomings in the TIFF 6.0 specs?) I do not want to end up splitting hairs... still it's not totally intuitive to use only LCH. To my mind, we always need Lab around the gray axis, since hue becomes meaningless. The same is true for color differences. Deltas in L, C, H are quite intuitive, yes, but for near-neutrals you'll need Delta a, b to know where you are. Best regards, Hanno Hoffstadt -- Dr. Johannes Hoffstadt / Color Solutions Software Tel.: +49 731 3886660 Mail: johannes.hoffstadt at color-solutions.de

On torsdag, dec 11, 2003, at 16:39 Europe/Copenhagen, Thomas Richard wrote: LCh is an interface on Lab. You do not save LCh on disk, you save Lab on disk. When you work in Linocolor you are setting up the equivalent of an Abstract profile which is an Lab to Lab (internal PCS) color move. But this is water under the bridge as the hope of a unitary source editing and archiving space did not make it through the many confusions over Lab interface and implementation details (DIN D65 and ANSI D50, 8 bit and 16 bit, and much more). Thanks, Henrik

On Dec 9, 2003, at 3:56 PM, Darrian Young wrote: That's the reality of image reproduction. People make these compromises all the time because some of them simply cannot be reproduced. If you think it's a good idea to contain colors which are printable but not naturally occurring, just for the sake of having a completely contained print gamut, at the expense of serious loss of detail and hue shifting then that's your choice. But quality conscious organizations are not eager to make that kind of exchange. Well now you have. That's great. So what is the basis for advocates of wide gamut RGB spaces (and I include anything larger than ColorMatch RGB in that category) if the gamut plots are being thrown out? Chris Murphy Color Remedies (TM) www.colorremedies.com/realworldcolor --------------------------------------------------------- Co-author "Real World Color Management" Published by PeachPit Press (ISBN 0-201-77340-6)

On Dec 9, 2003, at 5:07 PM, Darrian Young wrote: Tell me what naturally occurring object on the planet earth is 100% cyan only. Example, a banana is naturally occurring, and it's yellow comes close to that of process yellow. So for that kind of picture, it's a good thing to use something that can retain that yellow as a source space. But sky blue, green trees, orange flowers, grass, skin tones, hair, and even most man made product type shots, are not going to reproduce noticeably different if you use sRGB or ECI RGB. There's no question to the advantage of larger spaces when printing to wider gamut output devices. I'm not speaking about that. But most of the time people have an idea where their images are going to be printed. It is not at all common for people to not know they will be printing with a wide gamut output process. In the context of PDF/X-3 in particular, where the images simply get converted in the blind without any potential to inspect or correct the post converted CMYK files, the use of wide gamut RGB is questionable unless there is a reasonable chance the document is going to be printed to something that can take advantage of the wider source space. Otherwise you're committed to problems with reds shifting to red-orange, and blues shifting purple. And while you can say there are work arounds for this, they do not exist by default, and they're not easy for most individuals to deal with. I guess my point here is that general use of wide gamut RGB is just a bad idea right now. For it to be used in specific situations where the end user is sophisticated enough to take advantage of them, while also knowing to to contend with their bad side effects, is quite a good thing. Chris Murphy Color Remedies (TM) www.colorremedies.com/realworldcolor --------------------------------------------------------- Co-author "Real World Color Management" Published by PeachPit Press (ISBN 0-201-77340-6)

Jo Brunenberg writes: Hello Olaf, Thanks for your in-depth explanation! This certainly covers a lot of issues and answers several questions. But to be honest... I am not yet convinced that using ECI-RGB in practice will lead to better quality. However that might be my lack of experience..so I am really looking forward to the UGRA report. Still ( I am more focussed on practice than on theory) questions come up when I read your explanation: 1. I would like to set-up a practical test in which I could prove that using ECI-RGB working space really results into visible advantages compared to using Adobe RGB working space. Could you are anyone else define such a test? 2. Why still referring to the Photoshop 5.5 situation where we already are using 6, 7, 8 in which working spaces can be set as you like? 3. You put the question: and your answer is: I totally agree with this! But what would be the answer to the question: How does ECI-RGB compare to Adobe RGB? When comparing both RGB colourspaces with the ISO offset profiles I see that the Adobe RGB colourspace is large enough to cover the CMYK colourspaces of the ECI profiles. So why the need to go beyond the (already large) Adobe RGB colourspace? Best regards, Jo Brunenberg ------------------------------------------------------------------- >eci-en(a)lists.transmedia.de,Internet writes: >Hi, > > >I would like to draw attention to some aspects sometimes overlooked with >regard to this discussion and also to broaden the perspective a little bit: > >- focus on what's essential! eciRGB is definitely only one of several >reasonable options for a working color space RGB profile; so if your >image archive happens to be stored using Adobe RGB or what else, or you >are successful and happy using whatever you are using at the moment, >there typically is no need to switch to eciRGB just for the sake of it. >And: nobody _has to_ use eciRGB (though quite a few successful users are >using it). Stating eciRGB is a good option should not at all be >understood as stating everything else is rubbish. > >- what's the original? This is one very essential aspect often forgotten. >As I see it, the original is not what's out in the real world and getting >photographed, nor is it what even the best camera captures. It is what >the photographer or the person doing retouching/color correction etc. of >the raw image wants it to be. Thus it becomes an issue not only what >colors occur in the real world, but also what colors can be printed. > >- do we really always know where an image is going to be printed? Please >do not forget that images may be reused, the initial use being maybe a >display ad for a magazine general, then a similar campaign in newsprint, >then some digitally printed direct mailing pieces, then a huge poster at >some trade show, and so forth. eciRGB at least for many users in Europe >has proven to be a very suitable general purpose working color space. >Again: is it the only reasonable one? No. Does it have serious >deficiencies that some other profile does not have? Not that I know of. > >- color science does have a decent understanding of what real world >colors are. Some admittedly do not occur that often but they may occur. > >- Ugra in Switzerland has done a research project for Ifra (I am not >sure when the report is going to be available, probably first quarter >next year, they presented the preliminary results at the Ifra Color >Management Working Group during Ifra Expo October 2004 in Leipzig): Ugra >compared quite a few common RGB working color spaces and - using quite an >impressive range of metrics - arrived at the conclusion that all in all >eciRGB comes in first, with a couple of other profiles coming in next >very close. > >- one reason to not necessarily stay in a scanner profile color space >(unless you leave it un(re)touched) is that such profiles are not very >linear - thus color corrections, retouching etc. can result in >unnecessary loss of detail. > >- there are always trade-offs in every area of our business: e.g. detail >vs. gamut (especially as long as 8 bit data is used). If maximum detail >is key and there is no need to be prepared for all possible real world/ >pritable colors, some profile other than eciRGB may have advantages. > >- 8bit Lab does have its limitations: less than a third of the possible >Lab value triples exist as real world color, i.e. one is only making >sensible use of roughly 5 millions out of 16 millions possible color >value triples. This _is_ a threat to keeping as much detail as possible. > >- Jo is right in still asking for a summary of why eciRGB should be >considered and what's relevant to know about it. Here is a summary that I >have compiled for upload to the ECI website (going to be available there >shortly): > > >What is eciRGB 1.0, and why should I care? >------------------------------------------ >eciRGB 1.0 is recommended by the European Color Initiative (ECI) for use >as an RGB working color space and for color data exchange for ad >agencies, publishers, reproduction and printing houses. > >There are a couple of aspects that led to the development and release of >eciRGB by the ECI in 1999: >- Up to Adobe Photoshop 5.5 the default for the working color space was >the monitor profile of the computer on which Photoshop was running. This >turned out to be a less than perfect approach, as every computer may have >a different monitor profile, and a working color space should not depend >on what happens to be the monitor profile on a given computer, but should >always be the same, at least within any given workflow. >- Furthermore a monitor profile typically does not cover certain ranges >of colors that can easily be produced on a printing press - the major >area of weakness of a monitor compared with a press is in the Cyan color >region. >- Staying in the scanner profile's color space often makes no sense, as a >scanner's color space typically is not very uniform (a characteristic >offered for example by the Lab color space) this makes them unsuitable >for any corrections or editing. >- Lab in principle looked like a good alternative candidate, but hardly >any widely used software (until very recently) supported editing and >retouching for 16 bit Lab data or import of 16 bit Lab images (and while >PostScript/EPS supports up to 12 bit Lab data, in PDF 16 bit image data >have only been introduced very recently in version 1.5, earlier versions >only accommodating a maximum of 8 bit), and 8 bit Lab data was far too >inefficient, as only less than a third of all possible Lab color values >actually occur in real world color data: which means that out of the 8 >bit only a bit more than 6 bit would actually be used, which simply isn't >enough. Even with 16 bit Lab the issue arises that it uses twice the >amount of data - while the increase in file size often will be moderate >due to compression, the amount of RAM needed definitely doubles. >- while there were and still are other reasonable offerings around in >terms of RGB working space ICC profiles ECI wanted to see one that >... has a gamut that covers all colors that can be printed on today's >printing presses - whether sheet fed or web offset, gravure or newsprint >- but not much beyond (in order to not to waste precision for bits that >never really get used) >... produces a neutral gray whenever the values for Red, Green and Blue >are equal >... approximates uniform distribution of color values, i.e. equal >difference between two color values in eciRGB mirrors an perceived equal >difference when these colors are seen by the human eye >... is based on a Gamma of 1.8 and a light source of 5000K. >This profile was created and extensively tested in 1998/1999 and provided >to the public free of charge in 1999. Most ECI members have meanwhile >based their internal workflows on eciRGB as the preferred (and often the >only) RGB working color space, and have been more than satisfied with the >advantages achieved. > >Is eciRGB the only working color space that makes sense? >Definitely no. Other experts and user groups in the industry as well as >vendors have been working on this issue and have come up with alternative >options that may work as well as eciRGB. If you happen to have been >working with let's say Adobe RGB or ColorMatch RGB until now, it would >not be a good idea to convert your image database to eciRGB just for the >sake of then having eciRGB data. Nevertheless, when you are about to set >up a new print oriented workflow, the ECI is confident that there are >hardly better options than eciRGB (though possibly quite a few that are >comparably good). > >sRGB has seen excessively wide use, as especially HP and Microsoft were >promoting it as the standard RGB profile (in the end often going so far >that they - whether directly or indirectly - propose not to use any ICC >profiles anymore but instead to simply implicitly store and exchange any >RGB data as sRGB. More and more digital cameras, low end inkjet printers >and even monitors now simply assume sRGB. While this may look like a >smart move, it must not be forgotten, that sRGB as a color space has >serious weaknesses - there are a lot of colors today's printing presses >as well as other output devices like photo printers, large format >printers and many inkjets (not to speak of up to date monitors or digital >cameras) can produce that cannot be stored in sRGB. If quality is > >Should I get rid of my scanner profiles right away and use eciRGB instead? >No, definitely not. Simply assigning eciRGB instead of the specific >profile e.g. for a scanner is one of the worst things you can do. Always >use the correct source profile for the data at hand, and then convert >from that color space into eciRGB. > >Note 1: What's a working color space anyway? The short answer is, that >such a color space is good for working on an image (or rather any color >object), whether color correcting or retouching it or editing it in any >other way. A working color space can be made such that it is independent >of idiosyncrasies of a specific device (e.g. it can be made uniform to >preserve detail equally well in each area of the color space). At the >same time it can be made such that it serves a class of color spaces >well, e.g. that it comprises all or most of the colors that can be output >with all monitor and printing devices that are available today. > >Note 2: In ISO there is currently work underway - as ISO standard "ISO/CD >22028-2 Photography and graphic technology - Extended colour encodings >for digital image storage, manipulation and interchange - Part 2: >Reference Output Medium Metric RGB colour image encoding (ROMM RGB)" - to >possibly arrive at a working color space that is even better than eciRGB >or other widely used working color spaces. > > > >Sorry for the lengthy post, folks! > > >Olaf Druemmer >Vice chairman of the European Color Initiative > > >_______________________________________________ >ECI-EN mailing list >ECI-EN(a)lists.transmedia.de >http://lists.transmedia.de/mailman/listinfo/eci-en > > >

Hello Olaf, Thank you very much for this post. Exactly what I was looking for. For now, at least, I will continue to use AdobeRGB, but I think that it would be interesting, if there is a good upcoming space as you mention, for it to be communicated to software developers, camera manufacturers, etc. once it is ready. This way it would be much easier for users outside of Germany to implement it. Best regards. Darrian -----Mensaje original----- De: eci-en-admin(a)lists.transmedia.de [mailto:eci-en-admin@lists.transmedia.de] En nombre de Olaf Drümmer Enviado el: miércoles, 10 de diciembre de 2003 11:35 Para: Mailing List [ECI-EN] Asunto: [ECI-EN] Re: ECI-RGB / Any advantages? Hi, I would like to draw attention to some aspects sometimes overlooked with regard to this discussion and also to broaden the perspective a little bit: - focus on what's essential! eciRGB is definitely only one of several reasonable options for a working color space RGB profile; so if your image archive happens to be stored using Adobe RGB or what else, or you are successful and happy using whatever you are using at the moment, there typically is no need to switch to eciRGB just for the sake of it. And: nobody _has to_ use eciRGB (though quite a few successful users are using it). Stating eciRGB is a good option should not at all be understood as stating everything else is rubbish. - what's the original? This is one very essential aspect often forgotten. As I see it, the original is not what's out in the real world and getting photographed, nor is it what even the best camera captures. It is what the photographer or the person doing retouching/color correction etc. of the raw image wants it to be. Thus it becomes an issue not only what colors occur in the real world, but also what colors can be printed. - do we really always know where an image is going to be printed? Please do not forget that images may be reused, the initial use being maybe a display ad for a magazine general, then a similar campaign in newsprint, then some digitally printed direct mailing pieces, then a huge poster at some trade show, and so forth. eciRGB at least for many users in Europe has proven to be a very suitable general purpose working color space. Again: is it the only reasonable one? No. Does it have serious deficiencies that some other profile does not have? Not that I know of. - color science does have a decent understanding of what real world colors are. Some admittedly do not occur that often but they may occur. - Ugra in Switzerland has done a research project for Ifra (I am not sure when the report is going to be available, probably first quarter next year, they presented the preliminary results at the Ifra Color Management Working Group during Ifra Expo October 2004 in Leipzig): Ugra compared quite a few common RGB working color spaces and - using quite an impressive range of metrics - arrived at the conclusion that all in all eciRGB comes in first, with a couple of other profiles coming in next very close. - one reason to not necessarily stay in a scanner profile color space (unless you leave it un(re)touched) is that such profiles are not very linear - thus color corrections, retouching etc. can result in unnecessary loss of detail. - there are always trade-offs in every area of our business: e.g. detail vs. gamut (especially as long as 8 bit data is used). If maximum detail is key and there is no need to be prepared for all possible real world/ pritable colors, some profile other than eciRGB may have advantages. - 8bit Lab does have its limitations: less than a third of the possible Lab value triples exist as real world color, i.e. one is only making sensible use of roughly 5 millions out of 16 millions possible color value triples. This _is_ a threat to keeping as much detail as possible. - Jo is right in still asking for a summary of why eciRGB should be considered and what's relevant to know about it. Here is a summary that I have compiled for upload to the ECI website (going to be available there shortly): What is eciRGB 1.0, and why should I care? ------------------------------------------ eciRGB 1.0 is recommended by the European Color Initiative (ECI) for use as an RGB working color space and for color data exchange for ad agencies, publishers, reproduction and printing houses. There are a couple of aspects that led to the development and release of eciRGB by the ECI in 1999: - Up to Adobe Photoshop 5.5 the default for the working color space was the monitor profile of the computer on which Photoshop was running. This turned out to be a less than perfect approach, as every computer may have a different monitor profile, and a working color space should not depend on what happens to be the monitor profile on a given computer, but should always be the same, at least within any given workflow. - Furthermore a monitor profile typically does not cover certain ranges of colors that can easily be produced on a printing press - the major area of weakness of a monitor compared with a press is in the Cyan color region. - Staying in the scanner profile's color space often makes no sense, as a scanner's color space typically is not very uniform (a characteristic offered for example by the Lab color space) this makes them unsuitable for any corrections or editing. - Lab in principle looked like a good alternative candidate, but hardly any widely used software (until very recently) supported editing and retouching for 16 bit Lab data or import of 16 bit Lab images (and while PostScript/EPS supports up to 12 bit Lab data, in PDF 16 bit image data have only been introduced very recently in version 1.5, earlier versions only accommodating a maximum of 8 bit), and 8 bit Lab data was far too inefficient, as only less than a third of all possible Lab color values actually occur in real world color data: which means that out of the 8 bit only a bit more than 6 bit would actually be used, which simply isn't enough. Even with 16 bit Lab the issue arises that it uses twice the amount of data - while the increase in file size often will be moderate due to compression, the amount of RAM needed definitely doubles. - while there were and still are other reasonable offerings around in terms of RGB working space ICC profiles ECI wanted to see one that ... has a gamut that covers all colors that can be printed on today's printing presses - whether sheet fed or web offset, gravure or newsprint - but not much beyond (in order to not to waste precision for bits that never really get used) ... produces a neutral gray whenever the values for Red, Green and Blue are equal ... approximates uniform distribution of color values, i.e. equal difference between two color values in eciRGB mirrors an perceived equal difference when these colors are seen by the human eye ... is based on a Gamma of 1.8 and a light source of 5000K. This profile was created and extensively tested in 1998/1999 and provided to the public free of charge in 1999. Most ECI members have meanwhile based their internal workflows on eciRGB as the preferred (and often the only) RGB working color space, and have been more than satisfied with the advantages achieved. Is eciRGB the only working color space that makes sense? Definitely no. Other experts and user groups in the industry as well as vendors have been working on this issue and have come up with alternative options that may work as well as eciRGB. If you happen to have been working with let's say Adobe RGB or ColorMatch RGB until now, it would not be a good idea to convert your image database to eciRGB just for the sake of then having eciRGB data. Nevertheless, when you are about to set up a new print oriented workflow, the ECI is confident that there are hardly better options than eciRGB (though possibly quite a few that are comparably good). How does eciRGB compare to sRGB? sRGB has seen excessively wide use, as especially HP and Microsoft were promoting it as the standard RGB profile (in the end often going so far that they - whether directly or indirectly - propose not to use any ICC profiles anymore but instead to simply implicitly store and exchange any RGB data as sRGB. More and more digital cameras, low end inkjet printers and even monitors now simply assume sRGB. While this may look like a smart move, it must not be forgotten, that sRGB as a color space has serious weaknesses - there are a lot of colors today's printing presses as well as other output devices like photo printers, large format printers and many inkjets (not to speak of up to date monitors or digital cameras) can produce that cannot be stored in sRGB. If quality is important, sRGB is not an option. Should I get rid of my scanner profiles right away and use eciRGB instead? No, definitely not. Simply assigning eciRGB instead of the specific profile e.g. for a scanner is one of the worst things you can do. Always use the correct source profile for the data at hand, and then convert from that color space into eciRGB. Note 1: What's a working color space anyway? The short answer is, that such a color space is good for working on an image (or rather any color object), whether color correcting or retouching it or editing it in any other way. A working color space can be made such that it is independent of idiosyncrasies of a specific device (e.g. it can be made uniform to preserve detail equally well in each area of the color space). At the same time it can be made such that it serves a class of color spaces well, e.g. that it comprises all or most of the colors that can be output with all monitor and printing devices that are available today. Note 2: In ISO there is currently work underway - as ISO standard "ISO/CD 22028-2 Photography and graphic technology - Extended colour encodings for digital image storage, manipulation and interchange - Part 2: Reference Output Medium Metric RGB colour image encoding (ROMM RGB)" - to possibly arrive at a working color space that is even better than eciRGB or other widely used working color spaces. Sorry for the lengthy post, folks! Olaf Druemmer Vice chairman of the European Color Initiative _______________________________________________ ECI-EN mailing list ECI-EN(a)lists.transmedia.de http://lists.transmedia.de/mailman/listinfo/eci-en

Hello, I would be very careful about judging which colors are ok to lop off and which are not. I have never heard anyone advocating Colormatch RGB. You have chopped off cyan, yellow and green, so that just about leaves red, magenta, and cyan as the worthwhile colors. In Billmeyer and Saltzman's "Principles of Color Technology" their advice is to tear up any colored chromaticity diagrams, as they are not accurate protrayals of the colors which are represented. Regards. Darrian Young -----Mensaje original----- De: eci-en-admin(a)lists.transmedia.de [mailto:eci-en-admin@lists.transmedia.de] En nombre de Chris Murphy Enviado el: martes, 09 de diciembre de 2003 17:35 Para: eci-en(a)lists.transmedia.de Asunto: [ECI-EN] Re: ECI-RGB / Any advantages? On Dec 8, 2003, at 3:27 PM, Florian Süßl wrote: OK, so what would be the big advantage of ECI-RGB in this context, compared to ColorMatch RGB? I see a small slice of press yellow out of the ColorMatch gamut, but I think it's probably negligible considering how insensitive to different yellows we are as humans. The slice of cyans and light blue is maybe worth it to someone, but not the vast majority. If output profile packages let us select a source space, like ECI-RGB, upon which to predicate gamut compression, I'd be more interested in wide gamut RGB spaces. But because we have such limited gamut compression options in profile packages, we get generic gamut compression which means generic results. We either get too much gamut compression if the source space is sRGB, or too little if it's Adobe RGB or ECI-RGB especially in reds. The red primary for ECI-RGB is way out there, well beyond Adobe RGB. This does induce posterization and detail loss in finely detailed, highly saturated reds even in Adobe RGB let alone ECI-RGB. Once the detail is lost in conversion, no amount of CMYK color correction can get it back. The conversions become inherently more risky the larger the source space, especially if the workflow is going to depend on automatic conversions with no possibility of inspecting and editing the CMYK file before proofing/printing. Chris Murphy Color Remedies (TM) www.colorremedies.com/realworldcolor --------------------------------------------------------- Co-author "Real World Color Management" Published by PeachPit Press (ISBN 0-201-77340-6) _______________________________________________ ECI-EN mailing list ECI-EN(a)lists.transmedia.de http://lists.transmedia.de/mailman/listinfo/eci-en