![]() ![]() The image must be defined with the device gray color space. However, some Quartz routines expect images with a device color space.įor example, if you call CGImageCreateWithMask and specify an image as the mask, In most cases, a Mac OS X application should use a genericĬolor space instead of creating a device color space. To cut it short, the profile retrieved with CGColorSpaceCreateDeviceRGB() DOES NOT HAVE any associated ICC data, while the one retrieved with CGColorSpaceCreateWithName(kCGColorSpaceSRGB) corresponds to a standard sRGB ICC profile.Īlso, quoting the Apple documentation: Device color spaces are primarily used by iOS applications because other optionsĪre not available. SRGB profile: ICC name = sRGB IEC61966-2.1 The terminal output from the above code is quite interesting: Display profile: kCGColorSpaceDeviceRGBĭisplay profile: cannot get CGColorSpaceCopyICCProfile() ![]() Std::cout<<"sRGB profile: ICC name = "<<tstr<<std::endl Std::cout<<"Cannot get CGColorSpaceCopyICCProfile()"<<std::endl Std::cout<<"sRGB profile: "<<CFStringGetCStringPtr(CGColorSpaceCopyName(colorSpace),kCFStringEncodingASCII)<<std::endl Std::cout<<"Cannot get CGColorSpaceCreateWithName(kCGColorSpaceSRGB)"<<std::endl Std::cout<<"Display profile: "<<tstr<<std::endl ĬolorSpace = CGColorSpaceCreateWithName(kCGColorSpaceSRGB) Std::cout<<"Display profile: cannot get CGColorSpaceCopyICCProfile()"<<std::endl ĬFIndex icc_length = CFDataGetLength(data) Ĭonst UInt8* icc_data = CFDataGetBytePtr(data) ĬmsHPROFILE icc_profile = cmsOpenProfileFromMem( icc_data, icc_length ) ĬmsGetProfileInfoASCII(icc_profile, cmsInfoDescription, "en", "US", tstr, 1024) Std::cout<<"Display profile: "<<CFStringGetCStringPtr(CGColorSpaceCopyName(colorSpace),kCFStringEncodingASCII)<<std::endl ĬFDataRef data = CGColorSpaceCopyICCProfile(colorSpace) Std::cout<<"Cannot get CGColorSpaceCreateDeviceRGB()"<<std::endl This is exactly the thing I was setting up yesterday… I have run the following code snippet, with the display profile set to some wide-gamut colorspace in the preferences:ĬGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB() (I wouldn’t have thought that was the case though, since in general you can’t rely on a back end supporting such a thing.)Īs a first step, could you try using CGColorSpaceCreateDeviceRGB() and then copyICCData() on the result and share the ICC profile with us? This would be an issue if OS X allows rendering elements across multiple displays with a single call, and Gtk/Cairo is relying on such behavior rather than breaking up the rendering into separate calls for each display. (1) Would seem the most trivial to implement, but it could be that it’s not easy because Gtk/Cairo is hiding what display various things are on, and it is necessary to know which display is which when the application is doing color management or the null transform trick is used. Wide gamut displays are then fully supported. That would mean implementing color management for the X back end, and using the MS CMM machinery to manage color for the MSWindows back end. ![]() Gtk/Cairo support color managed back ends properly, by supplying the API’s to let the application tag all the color elements. For the former it could use sRGB as the tag, and for the latter the application is expected to do the color management and Gtk/Cairo use the null transform tag with OS X for those elements. Gtk/Cairo needs to distinguish between UI elements it is rendering and values that the application is handling. Down side is that all the UI elements will be garish on wide gamut displays. You need to use the null transform trick to do this with recent OS X releases. Make Gtk/Cairo render everything in native device space, which (I gather) would make it behave the same as the MSWindows and X back ends. My conclusion is that there are three ways this could be dealt with in increasing level of difficulty: This bug report says “something” was fixed (the bug was closed as fixed), I wonder what that “something” was, as it apparently didn’t actually fix the real problem: Bug 681784 – colorspaces used in gtk+ and cairo quartz backends do not matchįrom skimming through the bug report, it appears that Gtk/Cairo is pretty ignorant of Color Management, and on dealing with OS X has stumbled into problems. But it does seem sad that for years now this problem has been known, and no-one other than seems to have come up with any solution, and that solution is a not an actual solution but a workaround. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |