| | [ Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #2411
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | ICC Colour management policy |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | kub |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| FLTK on osX SL uses Generic RGB, which is not sRGB at all.
The situation for writers of colour managed applications is quite fuzzy
[1].
As a suggestion. FLTK might add an API to expose the used colour space.
On WIN32 and Linux it might return sRGB. On osX SL it can return the used
colour space. Thus interested applications can query what to colour
correct to.
/* provide a malloced ICC profile block and its size */
int fl_color_space( void ** returned_profile_block,
size_t * returned_size );
The profile can on Linux be asked from the X11 server [2]. So
returning the first displays profile might be the right choice.
osX has surely functions to convert a CGColorSpaceRef to a ICC profile
data blob.
[1] http://oyranos-cms.blogspot.com/2010/09/cross-platform-toolkits-and-cm.html
[2] http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec | |
| |
| The most accurate ICC profile from fl_color_space() would be only what is really set by FLTK. On osX it is the ICC equivalent of CGColorSpaceCreateDeviceRGB. | |
| |
| #3 | mike
12:54 Sep 02, 2010 |
| IMHO we should start using sRGB explicitly for colors on OSX.
That said, since 10.6 Generic RGB *is* sRGB... | |
| |
| Generic RGB only through the API sRGB. In ColorSync utility
Generic RGB is the old gamma 1.8.
Mike, can you forward this to Apple? | |
| |
| generic RGB from ColorSync utility is not the same as
CGColorSpaceCreateDeviceRGB().
That add to the confusion to a missed CM policy.
So when FLTK sets an ICC profile to the system, that
would be welcome to be transparent.
With a ICC profile setter for fl_draw_image(), users would be allowed
to deploy as well wide gamut devices. Thats currently not possible
with FLTK widgets or at last not known how to. | |
| |
| #6 | mike
08:42 Sep 03, 2010 |
| There are two generic RGB color profiles - one is the "classic" generic RGB that is still around for compatibility.
The other is the Gamma 2.2 Generic RGB which is the one used by CoreGraphics for "device" RGB.
As for supporting wide-gamut color via FLTK, I'm personally -1 on the idea since a) only Mac OS X has support in its basic graphics interface (X11 is all device color and Windows GDI is sRGB) and b) it makes FLTK that much larger and less portable.
Better to focus on getting a single, standard colorspace working right for all applications (sRGB) and *maybe* look at alternate colorspace support in the future. | |
| |
| > Better to focus on getting a single, standard colorspace working right
> for all applications (sRGB) and *maybe* look at alternate colorspace
> support in the future.
Thats a good step toward a CM policy. Great. Some remaining questions:
How can a user programmatically see that wide gamut support is there or not?
Which widgets are going to be affected?
A function like the following could answer those questions in a upward compatible way:
int fl_color_space ( Fl_Widget * my_widget,
void ** returned_profile_block,
size_t * returned_size );
useful results:
* device RGB - return no profile (Win32, X11)
* sRGB - return a ICC profile blob (osX SL), that can be static
* wide gamut - return in the future the actual set profile
Maybe its more beautiful to have a Fl_Widget::color_space( .. ) . | |
| |
| #8 | matt
12:52 Nov 14, 2010 |
| Not essential for the 1.3.0 release. Temporarily moved to 1.4 . | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
