Re: [Printing-architecture] Colour
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 | Next > |
 |
|
|
|
Re: [Openicc] [Printing-architecture] Colour
by Kai-Uwe Behrmann
::
Rate this Message:
The following text will merely describe what I would like to see as a
user. Some comments are added to explain what is meant colour management wise. Please do not wonder when not even print device selection is mentioned in my text. I assume such all to be covered elsewhere. As Scribus and other projects have focus and a long experience with printing, it would shureley be great to read their thoughts or comments, what they would think are useful CM options for CPD. Starting the print button I would like to see in a colour management tab, offering following basic controls: Colourmanage by System (*) Colourmanage in Application ( ) No Colourmanagement ( ) The first would be part of the CUPS *toraster system once its implemented. Colourmanage in Application (early colour binding): A print device profile is needed. So with this option enabled a selection for a "Separation profile" should appear showing the system installed profiles. The one ICC profile matching the actual print conditions the most should be preselected. The other matching and non matching profiles should follow in a descending order in the selection list. Once Oyranos is distribution ready and availabel it can help in preselection and device to profile association. The set of useful profiles is dependent to the print process. E.g. for a "Rgb" printer I would not like to select a Cmyk or nColour profile, for "Cmyk" not a Rgb one. For application colour management the responsibility to match between options and ICC profile lays in the hand of the user with the help of a hopefully well designed application and its helpers. It is important to note that any print profile is useful only within a defined set of variables associated with print device, medium, ink set, driver and driver settings. The Oyranos CUPS module tries to cover these relations as they are programatically reachable. Two ways to get profile to print condition matching UI wise I may outline. preserve - would mean the user selects a print queue. Then a profile selection system can detect a list of available and useful profile and they are presented to the user. All colour related options, except the above and below mentioned colour management options are not changeable. So e.g. a user can change positioning but not the ink set. This is a typical colour managed mode as many vendor drivers offer. A UI, offering expert level control, may allow to prominently breaking the profile to print settings relation as a special option. Typical a warning dialog could popup to say "Hey, do'nt change this setting or your profile does not match any more. Cancel[x] Break[]". You may have an alternative to popups. sync - a user can select whatever options are permitted by the other UI components. The ICC device profile selection is updated instantly (assuming its fast enough). The rendering intent, blackpoint compensation would be needed as the minimum of options. Additionally a "Simulation profile" and further options of the selected CMM can be helpful to designers and prepress people. E.g. "Preserve Black" and the like for Cmyk2Cmyk conversions. After that I would expect the document gets flattened and converted to the requested device colour space, which in turn is sent unaltered to the printer. The selected separation profile (must) be embedded and the whole thing marked as further not to be colourmanaged. Some PDF variants allow for that. But I am no PDF expert. So someone with certain knowledge in this field could hopefully tell more precisely, which exact PDF versions and attributes are needed to do this in a standard way. Colourmanage by System (late colour binding): Here is not much to say. The document needs all colour spaces be assigned properly, that a remote print host can make colourful sense of the content. A option for "Flatten Document Colour Spaces" would help in disambiguating the compositing colour space. That is useful for mixed colour space documents only. The resulting colour space of a colour space flattened document would be the compositing colour space, which is typical the default editing Rgb colour space, but can differ in some situations. The responsibility to correctly render the document is by the print system. Such documents are most portable, as they do not need a retargetting, and should therefore be the default setting. This approach is in colour terminology called late colour binding, because the colours get their final values in a rather later stage. No Colourmanagement: Omit all colour management related settings and enshure that the content is not altered during the spooling and printing. This option is important to print colour target, prematched files and for special applications, where altering of the content is undesireable. It preserves the state as is now. A print preview with a check box to "Simulate on Monitor" would be great and many consider it a basic feature, as it will help users to predict the print results. To do the proofing, the selected print profile would work as the simulation or proofing profile. The target is the actual monitor profile for that screen region. Oyranos has code in the CUPS module to obtain certainly the locally stored user accessible ICC device profile. Any CUPS profiles, being them local or remote, need more details worked out to fit in seamless in a easy manageable workflow. If you want to make a professional feature available the kind of on screen simulation can be selectable. This means to be able to alter the rendering intent for the proofing profile which is separate from the document to print rendering intent. The rendering intent for the proofing profile can be eigther relative colourimetric as a default and optional absolute colorimetric. The later would allow for a "Match to Light Booth", compensating for white point differences and do no compensation for the monitor white point. A further option would be to "Simulate Paper White" on screen, which is included in the previous option as well but without the absolute white point. Vendor ICC colour profile can be included by device dedicated PPDs and therein configured ICC profiles. A "Save to PDF" button with all settings applied would be welcome, but is shurely already covered by the requirement. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org PS: I would have loved to refere to the linuxfoundation page on print related CM but could not find. I would like to update links to it. Did it move(?): https://www.linuxfoundation.org/collaborate/workgroups/openprinting/color_management Am 10.11.09, 14:32 +0100 schrieb Till Kamppeter: > Cross-posting to the OpenICC and Gutenprint mailing list, to get more > input from the color experts. > > Anyone of the color printing/management experts can help Kate? > > Till > > P. S.: OpenICC mailing list info page: > http://lists.freedesktop.org/mailman/listinfo/openicc > > Gutenprint mailing list info page: > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > > kate price wrote: >> >> I am working on the UI design of the CPD and looking at the controls >> and parameters for colour, both as presets/profiles and as more >> detailed controls. Therefore, I'll need to get a good understanding of >> how this all works. >> >> Including: >> the workflow from application to printer >> colour profiles >> color management; in applications, and printer colour management. >> what happens where? >> detailed user interaction: what controls need to be there? >> >> >> Can someone point me in the right direction? Provide some useful >> information or sources of information? >> >> Thanks in anticipation, >> >> >> Kate >> >> man + machine interface works ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Hal V. Engel
::
Rate this Message:
On Wednesday 11 November 2009 01:28:24 am Kai-Uwe Behrmann wrote:
> The following text will merely describe what I would like to see as a > user. Some comments are added to explain what is meant colour management > wise. Please do not wonder when not even print device selection is > mentioned in my text. I assume such all to be covered elsewhere. > As Scribus and other projects have focus and a long experience with > printing, it would shureley be great to read their thoughts or comments, > what they would think are useful CM options for CPD. > > > Starting the print button I would like to see in a colour management tab, > offering following basic controls: > > Colourmanage by System (*) > Colourmanage in Application ( ) > No Colourmanagement ( ) > The first would be part of the CUPS *toraster system once its > implemented. > > > Colourmanage in Application (early colour binding): > A print device profile is needed. So with this option enabled a > selection for a "Separation profile" should appear showing the > system installed profiles. The one ICC profile matching the actual print > conditions the most should be preselected. The other matching and non > matching profiles should follow in a descending order in the selection > list. Once Oyranos is distribution ready and availabel it can help in > preselection and device to profile association. > The set of useful profiles is dependent to the print process. E.g. for a > "Rgb" printer I would not like to select a Cmyk or nColour profile, for > "Cmyk" not a Rgb one. > > For application colour management the responsibility to match between > options and ICC profile lays in the hand of the user with the help of a > hopefully well designed application and its helpers. > It is important to note that any print profile is useful only > within a defined set of variables associated with print device, medium, > ink set, driver and driver settings. The Oyranos CUPS module tries to > cover these relations as they are programatically reachable. > > Two ways to get profile to print condition matching UI wise I may outline. > preserve - would mean the user selects a print queue. > Then a profile selection system can detect a list of > available and useful profile and they are presented to the > user. All colour related options, except the above and below > mentioned colour management options are not changeable. So e.g. > a user can change positioning but not the ink set. This is a > typical colour managed mode as many vendor drivers offer. > A UI, offering expert level control, may allow to prominently > breaking the profile to print settings relation as a special > option. Typical a warning dialog could popup to say "Hey, do'nt > change this setting or your profile does not match any more. > Cancel[x] Break[]". You may have an alternative to popups. > sync - a user can select whatever options are permitted by the other > UI components. The ICC device profile selection is updated > instantly (assuming its fast enough). > > The rendering intent, blackpoint compensation would be needed as the > minimum of options. Additionally a "Simulation profile" and further > options of the selected CMM can be helpful to designers and prepress > people. E.g. "Preserve Black" and the like for Cmyk2Cmyk conversions. > > After that I would expect the document gets flattened and converted to the > requested device colour space, which in turn is sent unaltered to the > printer. The selected separation profile (must) be embedded and the whole > thing marked as further not to be colourmanaged. > Some PDF variants allow for that. But I am no PDF expert. So someone with > certain knowledge in this field could hopefully tell more precisely, which > exact PDF versions and attributes are needed to do this in a standard way. > I am not sure that "Colourmanage in Application" is a good descriptive term for this option although "early binding" is somewhat descriptive. What is being described is color management on the user machine (in user land) in the CPD (or perhaps a CPD color management add in of some sort). The distinction is that some applications do their own CM (Scribus, CinePaint PhotoPrint...) and the print system has no way of knowing about this. Doing color management in these apps the user would select the No Color Management option and calling this option color management in application could be confusing. > > Colourmanage by System (late colour binding): > Here is not much to say. The document needs all colour spaces be assigned > properly, that a remote print host can make colourful sense of the > content. A option for "Flatten Document Colour Spaces" would help in > disambiguating the compositing colour space. That is useful for mixed > colour space documents only. The resulting colour space of a > colour space flattened document would be the compositing colour space, > which is typical the default editing Rgb colour space, but can differ in > some situations. The responsibility to correctly render the document is by > the print system. Such documents are most portable, as they do not need a > retargetting, and should therefore be the default setting. > This approach is in colour terminology called late colour binding, because > the colours get their final values in a rather later stage. This should be the default once CUPS has CM aware *toraster filters (or at least a CM aware path). Like the early binding setting it should have a way for users to select rendering intents, black point compensation and possibly preserve black. Also these setting need to be passed to and used by the back end. > > > No Colourmanagement: > Omit all colour management related settings and enshure that the content > is not altered during the spooling and printing. This option is important > to print colour target, prematched files IE. output from apps that are CM aware. > and for special applications, > where altering of the content is undesireable. It preserves the state as > is now. That is all color values are assumed to be device values and should not be altered. > > > A print preview with a check box to "Simulate on Monitor" would be great > and many consider it a basic feature, as it will help users to predict the > print results. To do the proofing, the selected print profile would work > as the simulation or proofing profile. The target is the actual monitor > profile for that screen region. Even without proofing the CPD should use any installed (IE. X11 _ICC_PROFILE atoms) profiles to color manage what is displayed on the screen. This is a good starting point and adding proofing later will be much easier. > Oyranos has code in the CUPS module to > obtain certainly the locally stored user accessible ICC device profile. > Any CUPS profiles, being them local or remote, need more details worked > out to fit in seamless in a easy manageable workflow. > > If you want to make a professional feature available the kind of on screen > simulation can be selectable. This means to be able to alter the rendering > intent for the proofing profile which is separate from the document to > print rendering intent. The rendering intent for the proofing profile can > be eigther relative colourimetric as a default and optional absolute > colorimetric. The later would allow for a "Match to Light Booth", > compensating for white point differences and do no compensation for the > monitor white point. A further option would be to "Simulate Paper White" > on screen, which is included in the previous option as well but without > the absolute white point. Currently the CPD only allows for a fairly small preview. This limits it's usefulness for soft proofing. Most users interested in having on screen soft proofs will be using applications that have the ability to do soft proofing and that allow these proofs to be displayed in a larger window. GIMP, Scribus and I think CinePaint all support soft proofing. > > > Vendor ICC colour profile can be included by device dedicated PPDs and > therein configured ICC profiles. > > > A "Save to PDF" button with all settings applied would be welcome, but is > shurely already covered by the requirement. > > > kind regards > Kai-Uwe Behrmann > > > Cross-posting to the OpenICC and Gutenprint mailing list, to get more > > input from the color experts. > > > > Anyone of the color printing/management experts can help Kate? > > > > Till > > > > P. S.: OpenICC mailing list info page: > > http://lists.freedesktop.org/mailman/listinfo/openicc > > > > Gutenprint mailing list info page: > > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > > > > kate price wrote: > >> I am working on the UI design of the CPD and looking at the controls > >> and parameters for colour, both as presets/profiles and as more > >> detailed controls. Therefore, I'll need to get a good understanding of > >> how this all works. > >> > >> Including: > >> the workflow from application to printer > >> colour profiles > >> color management; in applications, and printer colour management. > >> what happens where? > >> detailed user interaction: what controls need to be there? > >> > >> > >> Can someone point me in the right direction? Provide some useful > >> information or sources of information? > >> > >> Thanks in anticipation, > >> > >> > >> Kate > >> > >> man + machine interface works > > _______________________________________________ > openicc mailing list > openicc@... > http://lists.freedesktop.org/mailman/listinfo/openicc > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Chris Murphy-2
::
Rate this Message:
I'm not sure to which list it's best to respond. So I will reply to all and we'll see what happens.
I've considered print architecture issues quite a bit dealing with the multitude of problems we have on Mac OS with various print drivers and applications. Linux is in a unique position to learn from the mistakes made on Mac OS and Windows, and also avoid their legacy baggage as well. So I'm interesting in engaging on a discussion on these issues and perhaps come up with a model architecture that is superior to any platform. A major hinderance on Mac OS is poor documentation for developers, something which perhaps Linux can do much better on, regardless of the architectural details. An added complexity is that printer manufacturers are most interested in default print behavior being set to proprietary driver enabled color management rather than either application or system level color management. Yet something must be done to normalize color modes and color spaces prior to such hand off as the driver itself is ignorant when it comes to the multitude of color spaces that potentially exist in a document let alone the world. Yet this default behavior is desirable from their point of view because they want to have parity in print behavior on various platforms. Again, documentation and possibly even reference implementations for them to model, is key. I'm not particularly stuck on having really explicitly "application color management, system color management, no color management" options with a modern operating system. This is just how it is on Windows and and Mac OS. If the architecture is smart about things, the user should not even need to make such duplicative choices in the print dialog. Now, perhaps some of these things cannot be avoided, but I'd like to think if we had an early enough start to really think about an "end goal" for how a printing architecture would function, it wouldn't force the user into confronting duplicative choices. Examples: 1. Application level page setups that do not interface with operating system/driver provided page setups (i.e. paper size, margins, number of copies) 2. The selection of an ICC output device profile for a particular device condition (implying a specific media, specific printer color mode, and resolution) in the application, and yet then having to specify all of this yet again in the system/driver print dialog. Also, consider that a big part of why Windows and Mac OS have "application color management" is due to legacy limitations of system level color management. The system and/or driver would not reliably choose the correct ICC profile for the user selected media type, color mode, and resolution. So it was decided to allow the user to manually disable the system color management, and the print driver color management, and enable application color management and manually choose an output device profile. Very tedious, and complex and prone to user error. One way do to this instead of considering really specific UI elements, is to list things most any applications need to do, a list of things users want to do, and a list of things drivers need to do. Then once the pieces are there, plot out an architecture that can elegantly handle these requirements. Now, maybe due to CUPS on Mac OS X already having a lot of these capabilities, it might just be easier for me to describe the basic of the OS X print architecture, and then I can point out the flaws with that system (in my opinion, obviously). And then the engineers reading this who know CUPS and Linux can consider ways they can possibly avoid those problems, rather than completely reinventing a whole new architecture. Anyway, my point is, I don't think we need to involve the user in choosing application color vs system color vs no color management. The user is in a poor position to know what to choose. This is really up to the application correctly tagging its various objects (whether or not it has converted those objects to a different color mode/space), and then the system normalizing that data into a single color mode/space prior to handoff to the driver. So really the color options for the driver would be: (*) Manufacturer named default color matching method. Example: "Epson Standard (sRGB)" and possibly provide a popup menu for additional manufacturer defined color matching methods, again example: "Epson Vivid" and "Adobe RGB (1998)" which are typical of various Epson CUPS drivers on Mac OS X. ( ) System color matching. Example: "Oyranos" That's really it. The user needs to pick between a proprietary color matching method just because that default is what the major print manufacturers tend to want. If that's not a consideration at all then no UI even required. Just normalize correctly behind the scenes (and I can go through various combinations of all of this from very simple to very complex). And I'd definitely avoid having a No Color Management or Off option in the driver UI. That's even more confusing. An application that needs a completely raw path needs to request that path, that way it's consistently chosen correctly rather than depending on the user to do it. Plus such an application is a very special use case, and is a huge hurt me button for most users, best not directly exposed in the UI. Document the off switch that's under the hood, and have an application that explicitly asks for that behavior. My 2 cents. Chris Murphy Color Remedies (TM) New York, NY ---------------------------------------------------------------------- Co-author "Real World Color Management, 2nd Ed" On Nov 10, 2009, at 8:32 AM, Till Kamppeter wrote: > Cross-posting to the OpenICC and Gutenprint mailing list, to get more > input from the color experts. > > Anyone of the color printing/management experts can help Kate? > > Till > > P. S.: OpenICC mailing list info page: > http://lists.freedesktop.org/mailman/listinfo/openicc > > Gutenprint mailing list info page: > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > > kate price wrote: >> >> I am working on the UI design of the CPD and looking at the controls >> and parameters for colour, both as presets/profiles and as more >> detailed controls. Therefore, I'll need to get a good understanding of >> how this all works. >> >> Including: >> the workflow from application to printer >> colour profiles >> color management; in applications, and printer colour management. >> what happens where? >> detailed user interaction: what controls need to be there? >> >> >> Can someone point me in the right direction? Provide some useful >> information or sources of information? >> >> Thanks in anticipation, >> >> >> Kate >> >> man + machine interface works >> _______________________________________________ >> Printing-architecture mailing list >> Printing-architecture@... >> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture >> > > _______________________________________________ > openicc mailing list > openicc@... > http://lists.freedesktop.org/mailman/listinfo/openicc ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Michael Sweet-3
::
Rate this Message:
On Nov 11, 2009, at 9:45 PM, Chris Murphy wrote:
For the general case, I actually think you want no color controls. If a printer driver provides ICC color profiles, the printing system uses them to convert all color data in the document using that profile (document color -> PCS -> device color). If a printer driver says to use a standard color space (sRGB, AdobeRGB, etc.), then that is implicitly the device color space. Let the printer drivers actually support the color space they advertise and do their best to reproduce the colors - we all know they will not exactly match the screen since there are too many variables to account for: screen, printer, lighting, humidity, temperate, marker (ink/toner/wax/etc), media type, resolution, eyes, marketing segment for a printer, etc. One of the biggest problems we have with Mac OS X color management are the color controls. Too many users try to tweak every knob we have, and too many drivers provide extra knobs that interfere with managed color reproduction. The best advice we can give to our users is to turn off all of the vendor controls (if necessary) and leave our color controls set to the defaults. If Linux wants to avoid the "mistakes" of the Mac and Windows world, eliminate vendor controls and minimize (or eliminate) the "standard" color controls. Let the "expert" applications provide controls for color profile and rendering intent, which is equally important to make out-of-gamut colors look reasonable, and leave those controls out of the standard/general print dialog. .... From the point of view of a color-managed workflow, the ideal color space for printer drivers is DeviceN, i.e. a 6-color printer gets 6 color channels, with the separation defined by the ICC profile for that printer, media, color mode, etc. However, the reality is that we don't have tools to create or the infrastructure (at least on Mac OS X) to handle profiles with more than 4 channels, and thus most drivers take RGB or CMYK and map it to DeviceN as needed. Because of this, custom printer profiles are of limited usefulness in a printing workflow - you can (and many people do) tweak the output for a particular set of printer, inks, and media, but the results are not ideal because you are not manipulating the color in the printer's native color space. Moreover, many high-end printers now provide so-called "closed loop" profiling on the printer to normalize the output for the current supplies and environment, making the "traditional" manual profiling workflow unnecessary. ___________________________________________________ Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by edmund ronald
::
Rate this Message:
Actually, the only color mode I cannot live without is "No Color
Management", which can also be called "Application Color Management" All the rest is useful but not essential, and as all the rest can be counted on to break, but "No color Management" allows any graphics pro to get good results by color managing upstream. I know that the big fashion nowadays is to talk about "users" and "Desktop Linux", but I would like to remind people that Linux got its good reputation from serious applications that really worked rather than from zillions of buggy features. If professionals and photo enthusisasts start being able to use Linux boxes as print drivers with the GIMP, that will get the color management stuff bootstrapped by providing a solid motivated userbase. Edmund ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Michael Sweet-3
::
Rate this Message:
On Nov 13, 2009, at 5:07 AM, edmund ronald wrote:
> Actually, the only color mode I cannot live without is "No Color > Management", which can also be called "Application Color Management" Keep in mind that many printers do not offer a "no color management" mode. For example, all but a few of HP's inkjet printers only support printing with sRGB (there is no DeviceN path), and both Canon and Epson are moving to sRGB command sets as well. Even for printers that *do* support DeviceN paths, none of the available drivers (not even Gutenprint) provides a true DeviceN color path, so your "Application Color Management" path is less useful than you think. > All the rest is useful but not essential, and as all the rest can be > counted on to break, but "No color Management" allows any graphics pro > to get good results by color managing upstream. I would argue that most "graphics pros" do not actually understand what they are doing WRT color management and profiling, or the limitations of their workflow. ___________________________________________________ Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
|
|
|
Re: [Openicc] [Printing-architecture] Colour
by Chris Murphy-2
::
Rate this Message:
On Nov 12, 2009, at 2:57 PM, Michael Sweet wrote:
I don't agree with most of this. The quality of the RGB->DeviceN "black box" provided by a manufacturer for an e.g. 6-color printer, is what determines how effective profiling it can be. For example the Epson Stylus Photo 2200 had a really piss poor Off (No Color Adjustment) LUT. It was wider gamut than the Photo Realistic or Vivid LUTs, but it had nasty gray balance and seriously clipped detail in shadows. It was worth profiling over despite this, for certain classes of imagery. Other classes, it was best to profile over the Photo Realistic mode. Newer printers, Epson Stylus Pro 3800 or 3880, for example, the Off (No Color Adjustment) LUT is quite well behaved, even compared to the sRGB or Adobe RGB LUTs offered by the driver. Professional, fine-art photographers have been building custom RGB ICC output device profiles over these LUTs for such professional printers for years, using the manufacturer supplied driver, and have achieved superior results compared to either the sRGB or Adobe RGB LUTs. There are a couple of products on the market that can build 5+ channel ICC output device profiles. They are old, and expensive, and it's unclear exactly how well they work compared to an RGB ICC output device profile over a good (or decent) RGB->deviceN black box LUT provided by the manufacturer. What is clear is that it's non-trivial making such deviceN ICC output device profiles even if you have the software to build them, or an OS that could support them. The profile target you use is a challenge to figure out how you're even going to print it correctly. And then you have a healthy amount of testing to manually determine what the ink limit should be, since ink limiting is the responsibility of the profile, in this paradigm, if there is no black box in the middle of the process. And channel cross over behavior, ink limiting and GCR is really non-trivial. Looking and high-end proofing products, even that is rarely done with DeviceN ICC profiles for inkjet proofers. If it's an Epson inkjet, most products on the market today depend on Epson's HTM (halftoning module), which is the guts of their black box which can accept either RGB or CMYK input. So the inkjet is still profiled as either an RGB or CMYK device, and the HTM is responsible for further separating that out to deviceN. (For dot proofing on inkjet, other considerations are needed.) So I disagree that "custom printer profiles are of limited usefulness" or that the "results are not ideal." I have much bigger complaints than not being able to peak inside the Epson/Canon/HP black box. I'm annoyed that it's so f'n difficult to reliably print profile targets on Mac OS X without ColorSync sticking its nose into the wrong business. When that happens, the resulting profile is completely FUBARd and that is truly of limited usefulness and results that are not ideal. Chris Murphy ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Michael Sweet-3
::
Rate this Message:
On Nov 13, 2009, at 9:20 AM, Chris Murphy wrote:
I see it as a combination of inertia - before color management you needed all those controls - and marketing pressure where more controls == better in the eyes of marketing. In any case, whether they provide such controls or not, the default should be to do a good job of rendering colors in the handoff space their driver specifies. "Vivid" color should be an option, not a default.
While you are quick to blame ColorSync, the issue of providing colors in the device color space to avoid transforms is well-known and every profiling tool I know of for the Mac already does the right thing to print a target. The most common problem is drivers - vendors incorrectly choose defaults or ignore color settings (applying *both* the colorsync profile *and* their own "enhancements") which leads to strange results. A very common problem with the Epson drivers is that the Epson color controls are not actually disabled in ColorSync mode! However, bugs like those are propagated to avoid "breaking" existing users' workflows (!?!) So, while you may be able to use custom printer profiles with off-the-shelf printer drivers under specific circumstances, most people lack the knowledge or equipment to actually make use of those profiles, so I say they are of limited usefulness with less than ideal results. ___________________________________________________ Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by edmund ronald
::
Rate this Message:
Michael,
On Fri, Nov 13, 2009 at 10:35 PM, Michael Sweet <msweet@...> wrote: > > In any case, whether they provide such controls or not, the default should > be to do a good job of rendering colors in the handoff space their driver > specifies. "Vivid" color should be an option, not a default. Indeed, good default behavior is desirable! > > While you are quick to blame ColorSync, the issue of providing colors in the > device color space to avoid transforms is well-known and every profiling > tool I know of for the Mac already does the right thing to print a target. At the ICC we seem to have a collective sense that printing profiling targets *reliably* is presently impossible. Furthermore Joe User cannot know whether his target was printed correctly or not. > The most common problem is drivers - vendors incorrectly choose defaults or > ignore color settings (applying *both* the colorsync profile *and* their own > "enhancements") which leads to strange results. A very common problem with > the Epson drivers is that the Epson color controls are not actually disabled > in ColorSync mode! However, bugs like those are propagated to avoid > "breaking" existing users' workflows (!?!) Yes, indeed. But those bugs we could live with. Targets not printing, we cannot. > So, while you may be able to use custom printer profiles with off-the-shelf > printer drivers under specific circumstances, most people lack the knowledge > or equipment to actually make use of those profiles, so I say they are of > limited usefulness with less than ideal results. I strongly disagree. Professional photographers and enthusiasts are now every day downloading custom profiles from media vendor sites, they are buying solutions such as ColorMunki and Spyder3Print. Photo labs use Mac systems by the thousands with standard inkjet drivers and custom media profiles to do big enlargements. Every Photoshop photo tutorial book now documents profiled printing with custom profiles. Enough already. Give us back our ability to print targets, and let us then choose a forum for the public discussion of desirable exposed features of inkjet drivers - I suggest this be debated within the ICC Digital Photography Workgroup. > ___________________________________________________ > Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Robert Krawitz-2
::
Rate this Message:
Date: Sat, 14 Nov 2009 00:13:06 +0100
From: edmund ronald <edmundronald@...> On Fri, Nov 13, 2009 at 10:35 PM, Michael Sweet <msweet@...> wrote: > So, while you may be able to use custom printer profiles with > off-the-shelf printer drivers under specific circumstances, most > people lack the knowledge or equipment to actually make use of > those profiles, so I say they are of limited usefulness with less > than ideal results. I strongly disagree. Professional photographers and enthusiasts are now every day downloading custom profiles from media vendor sites, they are buying solutions such as ColorMunki and Spyder3Print. Photo labs use Mac systems by the thousands with standard inkjet drivers and custom media profiles to do big enlargements. Every Photoshop photo tutorial book now documents profiled printing with custom profiles. Enough already. Give us back our ability to print targets, and let us then choose a forum for the public discussion of desirable exposed features of inkjet drivers - I suggest this be debated within the ICC Digital Photography Workgroup. I think arguments of the form "most people don't need to/don't know how to do this, so there's no reason to allow anyone to", along with counter-arguments of the form "but my friends and I do!", quickly become unproductive. The former, because they ignore the diversity of people's needs, and the latter because purport to answer the former but don't really attack the basic premise. Which is unfortunate, since I think the basic premise of the former -- that we should just cater to the needs of the masses, and consciously ignore anything more specialized in the name of simplicity -- is way off base. It's undoubtedly true that the vast majority of people don't have the knowledge or equipment to make profiles. There are umpteen million Mac users out there but probably only umpteen thousands of people who can usefully make profiles. So you're basically reduced to pleading a special case: my needs are so special that they should override the goal of simplicity. That's not going to work very well: people who believe in this goal of ultimate simplicity of interface are predisposed against special cases, and granting that kind of override to one means granting it to everyone, which means the product has to grow all manner of special cases. I think the right argument here is simply that one size never fits all, and that things need to be designed in such a way that most people can ignore the fancy stuff and get their work done, but that there needs to be an appropriately designed escape hatch allowing people with more sophisticated needs to meet them. A successive disclosure of complexity is fine; people who don't need anything more elaborate can simply not enable anything beyond the basics, but as people's needs change, those additional facilities are available. If nothing else, full 16-bit data paths (enabling adjustments at the application level to preserve sufficient precision) and some kind of unmanaged RGB, CMYK (if appropriate for the device), and DeviceN inputs should be available. -- Robert Krawitz <rlk@...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Robert Krawitz-2
::
Rate this Message:
From: Michael Sweet <msweet@...>
Date: Fri, 13 Nov 2009 08:37:34 -0800 On Nov 13, 2009, at 5:07 AM, edmund ronald wrote: > Actually, the only color mode I cannot live without is "No Color > Management", which can also be called "Application Color Management" Keep in mind that many printers do not offer a "no color management" mode. For example, all but a few of HP's inkjet printers only support printing with sRGB (there is no DeviceN path), and both Canon and Epson are moving to sRGB command sets as well. Even for printers that *do* support DeviceN paths, none of the available drivers (not even Gutenprint) provides a true DeviceN color path, so your "Application Color Management" path is less useful than you think. Gutenprint absolutely provides a true DeviceN color path (for Epson printers, at any rate). We just don't have a reasonable vehicle for exposing it to end users. But the API is there and is stable, and it's implemented for all supported Epson inkjets. Actually, there are multiple DeviceN paths available, everything from gamma and density corrected to just density corrected to no correction at all, all the way to full control over ink drop size, but it's all with the same API. Someone could certainly write an application that uses it (I'd suggest extending PhotoPrint, for starters). I'm dubious of sRGB-only command sets for inkjet printers. It artificially restricts the available gamut, and doesn't work if you use a medium other than that specified by the manufacturer. -- Robert Krawitz <rlk@...> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Chris Murphy-2
::
Rate this Message:
On Nov 13, 2009, at 4:35 PM, Michael Sweet wrote:
Well they don't. None of them do this correctly. All try to submit a target and then the driver defaults to vendor color matching, typically expecting sRGB as the source space. The user must manually set a "no color management" color setting, because none of the profiling tools use the APIs to inform the OS which then informs the driver to change to the proper mode for building an ICC profile. If we get the driver configured correctly, then yes we get a valid profile target, without ColorSync involving itself. However, none of the high end profiling tools print targets directly through the OS. Those targets are TIFF, and need to be printed from an application that can correctly print and not color manage the target, and then also inform the OS (the pdftoraster filter, and also ColorSync) to not convert the target. Presently on Mac OS the application of choice is Photoshop, with which we are presently having problems because the No Color Management based PDF spool file has different profiles set for the profile target object, and OutputIntent, causing ColorSync to color manage. It autoconfigures newer print driver settings correctly, but the PDF spool file is malformed, so we get a converted profile target. I have looked quite long and hard on Apple's developer web site for documentation explaining the architecture and how to avoid transforms and was not successful. The API to get the print driver to set itself to the proper mode for use with an ICC profile using application color matching isn't locatable either.
Yet an off mode for ColorSync doesn't exist. It depends on null transforms. That's the bigger flaw, in my view, because achieving null transforms is complicated. An off switch is much easier, and thus more reliable. An explicit off switch is allowed in PDF/X-3, while still implicitly tagging the data. DeviceRGB being persona non grata, by Apple, in the PDF spool file is a big source, in my opinion, of the problems we've been having on Mac OS. DeviceRGB could have (and should have) acted as a fail safe for calibration/characterization/prematching workflows. While a small percent of the market, these workflows are the #2 workflow behind simply leaving the driver set to defaults.
I have two current drivers for two different Epson printers and neither of them behave the way you're describing. When I set ColorSync mode, the Color Settings pop-up menu changes to "Off (No Color Adjustment)" and all of its color controls found in Advanced Color Settings vanish. Instead, they are replaced by text explaining the profile that will be used when printing. It appears to be the correct behavior. I know older drivers, for way too long, did behave the way you describe. And yes that's all on Epson, but the documentation is weak, and documentation search on the dev site simply sucks. So, presently we're unable to reliably print profile targets from Photoshop, using No Color Management (in Photoshop) and Off (No Color Adjustement) in a wide assortment of newer Epson drivers. What happens is, I get a completely borked profile target in printed form. Inspection of the PDF spool file indicates source≠destination, and thus ColorSync is going to come riding in to convert the job. DeviceRGB being set as the color space would avoid this. Content that is calibration/characterization/prematch from an application, has no business being ICCBased in the PDF spool file. Chris Murphy ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Hal V. Engel
::
Rate this Message:
On Friday 13 November 2009 08:56:12 am Chris Murphy wrote:
> It depends entirely on how it's implemented. > > All driver dialogs on Windows and Mac OS (not sure about Linux, but I > suspect it's the same) are not the actual driver itself, merely the OS > drawing those features on-screen. The user makes the settings, including a > "No Color Management" option. But that selection does NOT directly > communicate with the driver. It's capture metadata that the operating > system includes into a print spool file (and/or corresponding job ticket > file). Later, that print spool file and included metadata with the > captured driver settings, is passed onto the manufacturer's print driver > and interpreted - i.e. you get the "Off" LUT instead of an sRGB LUT or > Adobe RGB LUT. > > So that's already a "smart" or "automatic" mechanism, because there is no > direct mechanism anyway. On most *nix (non-OS/X) systems where users are trying to do color critical work the users will be using the GutenPrint drivers if there is a GutenPrint driver for their printer(s). Not those from the device vendor. In many cases the device vendor does not even have a *nix driver for the device. When using the GutenPrint driver the user is interacting directly or nearly directly with the driver and has a degree of control that is far beyond what OS/X or Windows users have over these devices. That interaction is generally controlled by the printer driver PPD file. This includes the ability to do RGB, CMYK and DeviceN (if the printer has more than 4 channels) printing as well as to change things like ink limits, GCR, sub-channel transitions and LUTS. The UI for doing some of these things is a little on the primitive side however. In addition work is underway on a tool that will create calibration (linearization) curves for GutenPrint driven printers using various measurement instruments (actually using ArgyllCMS to do the measurements). This tool is called GPLin and is still an alpha level tool but it is getting closer to being a useful tool as it goes through regular updates by it's author (Alastair M. Robinson). But to Chris' main point. For RGB and CMYK printing paths there is indeed a black box built into the driver that is doing some "color management" but with our open source drivers we also have true DeviceN available. I have done extensive measurements of the response curves of my GutenPrint driven Epson R2400 printer and for the most part it's CMYK channels have fairly smooth response curves with minimal anomalies in the dark to light ink transitions although the magenta channel could be improved in this regard. In other words the GutenPrint driver presents this printer as fairly well behaved CMYK device and CMYK profiles I have created for it using ArgyllCMS give very good results. I suspect that the same thing is true for those who are using this driver/printer combination but are using it's RGB mode and it is likely true for most of the Epson printers supported by the GutenPrint drivers. > > Further, on Mac OS X for some time now, there is no explicit off switch for > ColorSync. Apple requires multiple square dances with a dog, a pig, and a > pony, under a full moon, in order to get ColorSync to piss off. ColorSync > is only turned off through null transforms. Only when the source profile > for content is identical to the destination profile, is ColorSync > disabled. > > In order to make this work, Apple has a rather convoluted mechanism for > certain applications to request, NOT the disabling of ColorSync, but to > get the current canned manufacturer profile registered for a particular > print mode. The application must then bogusly tag objects with that > profile, in order to achieve this null transform. And this is critical for those folks who are doing color critical work. If we don't have a straight forward way to print profiling/calibration targets then there is a problem. Robert Krawitz quotes Eric Crampton in the footer of all of his emails thusly. "Linux doesn't dictate how I work, I dictate how Linux works." I think it is fitting to use that quote to help make the point that many Linux users expect to be in total control of their machines. Anything that reduces their control will at best be viewed with suspicion. For example I have been running patched and hand modified kernels for a long time and I have other software on my system that I have modified so that it works the way I want. No Windows or OS/X user would even think about running a customized kernel yet it is fairly common for Linux users. On the other hand since we are dealing with open source code the problems listed below should not happen. For example if the drivers don't work the way they should and if the vendor will not fix the issues then we can fork the code and get things fixed. We are NOT dependent on hardware vendors to get things fixed. > > And as we are seeing with the clusterf8ck.com situation we've got going on > with Mac OS X, newer Epson drivers, and Photoshop, we've got ColorSync > converting ICC profile targets. And if we recall history, we've had all > kinds of problems with Mac OS X and printing color reliably. > > In my view, Apple made a colossal mistake by attempting to follow a PDF/X-3 > like format for their print spool file format, but then deciding to go on > a vendetta against DeviceRGB which is a rather important color space in > PDF/X-3 to explicitly indicate such content should not be color managed if > the content is sent to the device it was intended for. Instead, Apple is > double tagging the PDF spool file: first the individual objects are aways > being tagged, instead of say prematched data and profile targets being set > to DeviceRGB, and then yet again with an OutputIntent profile. > > Now, the OutputIntent tag should always be set to something. That indicates > the intended output space, and for prematched data can be used to soft > proof the print job before it goes to the printer. But in the case of > calibration/characterization/prematching, the color space for those > objects should be DeviceRGB (I am referring to desktop inkjet printers, > treated as RGB output devices). I think the same things should be true for DeviceCMYK since this is simply a variation on the same use case. > But Apple has banished DeviceRGB and > disallows any specialized applications from using it. Instead, they > require the object to be tagged with a profile, and for the OutputIntent > to also be set with the same profile. If an application does not submit a > source profile for its content, the OS will assume a color space and tag > that data when the PDF spool file is written to disk. So there is no way > around this. (Generic RGB is what's used on 10.5 and older, sRGB on 10.6 > and newer). > > Apple has argued that untagged data is evil. Yet the great thing about > PDF/X-3 (or X-4 or X-5) is that DeviceRGB is special because it is an > explicit indication that content to the intended device is not to be color > managed, but it still has an implicit source profile. And that's the > OutputIntent. So DeviceRGB isn't untagged. The problem of course is that in the larger world many PDF documents use DeviceRGB as a way of doing untagged RGB. In fact I don't think the PDF specification allows for untagged objects so the only option people have for creating PDF documents where they don't have to tag the objects in very specific ways is to use DeviceRGB. Apple appears to be trying to "fix" this problem and their fix has the unintended consequence that it makes calibration/characterization/prematching very difficult. My gut tells me that they are trying to fix this problem in the wrong place and this is why we are having these issues. > > The problem is, driver vendors who don't get their print modes and > associate profiles, and default profiles, registered correctly with the OS > for some reason. It's been an on-going problem. Canon had the problem and > seems to have fixed it. HP had the problem, and seems to have fixed it. > Epson had the problem, and sometimes gets it fixed, and them sometimes > (like now) regresses back to broken behavior. This whole area is very difficult because of it's complexity. There was lots of work this summer on Oyranos in this area and I think it is worth while to follow up on that work to see if we can't iron out any remaining issues so that a linux (or other FOSS OS)/Oyranos/CUPS/... system really works the way it should. But lets be clear that this will not be easy to solve. > When they don't work > correctly, it can mean ColorSync will become invited to the party when it > wasn't asked to, but more importantly when we don't want it to: > calibration/characterization/prematching. > > So, a user selectable off switch we do not have. And we don't even really > have a developer off switch either, but rather an indirect means of doing > this through a convoluted, and unreliable, null transform dependency. > > If the architecture is designed correctly to fail safe, instead of fail > chaos,we would not need a driver option for Off (No Color Management). > That option, is a big fat lie anyway. Obviously color management of some > sort is required because inkjet printers do not have merely three inks > comprised of red, green and blue. This is back to the RGB only assumption of Windows and OS/X. Many of our open source printer drivers support RGB as well as CMYK and true DeviceN. Since we have more flexible drivers available I think it changes how we should approach this problem to some extent. Hal ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Michael Sweet-3
::
Rate this Message:
On Nov 13, 2009, at 3:13 PM, edmund ronald wrote:
I humbly suggest that what you want is a utility that allows the user to print targets and generate/install ICC profiles for a particular combination of printer, media, and other settings. If you have to select a profile at print time, then the printing workflow is broken. ___________________________________________________ Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Michael Sweet-3
::
Rate this Message:
On Nov 13, 2009, at 3:53 PM, Robert Krawitz wrote:
___________________________________________________ Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Michael Sweet-3
::
Rate this Message:
On Nov 13, 2009, at 4:04 PM, Robert Krawitz wrote:
___________________________________________________ Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Michael Sweet-3
::
Rate this Message:
On Nov 13, 2009, at 4:39 PM, Chris Murphy wrote:
___________________________________________________ Michael Sweet, Senior Printing System Engineer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
|
Re: [Openicc] [Printing-architecture] Colour
by Chris Murphy-2
::
Rate this Message:
On Nov 14, 2009, at 12:13 AM, Michael Sweet wrote:
> That's the kicker - most inkjet drivers use vendor color matching by default, and usually with vendor-specific "enhancements" that don't get turned off when you tell the driver to go into ColorSync mode. We file bugs with the vendors all the time for this... :( I understand, vendors regularly get things wrong. > The API for setting up an identity transform isn't public but *is* available through developer technical support. Basically this hasn't been included in public documentation because even the "experts" writing profiling software have used the API incorrectly (for various reasons the API is semi-complicated), and we don't want to encourage the use of device color on Mac OS X except when it is actually needed (which is basically only when printing a target or doing application color management...) a.) Sounds like it's too complicated. b.) Sounds like it's too complicated for the documentation Apple is willing to provide. c.) Vendors are still getting things wrong. > ... and thus more likely to be used. It is hard to turn off ColorSync on purpose - there are very few scenarios that actually require it. Sure. Any scenario involving calibration, characterization, or application prematching, requires it. That would be a few scenarios. But they are rather mission critical scenarios for those who depend on it. It doesn't seem like making ColorSync so hard to turn off has really achieved anything, but lots of problems over the past 5 or so years, for professionals who depend on printing, especially to inkjet printers. > The problem is that DeviceRGB was being used for everything, not just for those cases that needed it, so it was basically impossible to know what the intent was and get consistent output from applications. That was an opt in system of color management. The default was DeviceRGB. I am not proposing that model. I'm proposing simplifying the opt out mechanism, and making it robust. Right now it's the year 2009 and this is as bad and inconsistent as it has ever been. > Epson (and all of the other printer vendors) work closely with Apple engineering, but there are still problems that slip through our combined testing. The problem I described has come and gone for specific drivers many times, and often re-appears in new drivers the first time we get an update from them - we reject any that we catch, but as you can imagine we can't test every driver and printer so problems *do* slip through. Well if Apple didn't operate like the KGB, as though everything is such a huge fricking secret, and clearly and thoroughly documented how things are supposed to work, it would at least make it easier to identify what is incorrect behavior, and whose bugs these are. > >> So, presently we're unable to reliably print profile targets from Photoshop, using No Color Management (in Photoshop) and Off (No Color Adjustement) in a wide assortment of newer Epson drivers. What happens is, I get a completely borked profile target in printed form. Inspection of the PDF spool file indicates source≠destination, and thus ColorSync is going to come riding in to convert the job. > > We are working with both Adobe and Epson on this issue... Michael, yes, I have no doubt about that. The problem is that these sorts of color problems with printing are recurring themes. Epson is not the only one who has had problems, although they very well may be the worst offender. But we don't have these kinds of problems on Windows. That should be a WTF moment for Apple. Sane people have started to wonder, rationally, if there is something wrong with the architecture when there are so many recurring problems of this sort, through multiple major revisions of the operating system. We've experienced color related problems with Tioga drivers too. > DeviceRGB (like what we went through in 10.4 and earlier) only led to more problems since all output was uncalibrated. There is a very rational, workable medium between totally uncalibrated, which is not what I'm advocating, and forcing everything to be ICCBased. It is fundamentally inappropriate for calibration/characterization/prematch data to be ICCBased. That is a serious systemic problem, and a cause for many of the problems we've been having. DeviceRGB + an OutputIntent is not the same thing as what you had with 10.3 and earlier. It is not uncalibrated. And I'm not suggesting most applications would have such PDF spool files. Just the ones that explicitly call a particular "calibration API". Presently, it is possible for PDF spool files to appear with an OutputIntent of None, which I find equally baffling to the lack of DeviceRGB. In my view the PDF spool file is formed exactly backwards. OutputIntent should be required, as it is in all PDF/X. That is the implicit source for device data, enabling the soft proofing of even application prematched data - or even retargeting to a different output device, if necessary. Chris Murphy ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gimp-print-devel mailing list Gimp-print-devel@... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
| < Prev | 1 - 2 - 3 - 4 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
