Newsgroup: it.comp.programmare.win32
Titolo: CMYK macro using GDI

 
Hi there,
was wondering if there is a way to use the CMYK macro from GDI correctly.  
If i used the RGB one, everything is Ok. But as soon as i try to use the 
CMYK one, all my colors are wrong.
Can someone please, help me on that matter.

Charles Tremblay wrote in message ...

    I wasn't aware of this macro. I have no idea how or where
    it is used though. I did a "grep -d" on my whole ...\include
    tree and didn't find a single reference to it, other than the
    definition of CMYK & LCS_DEVICE_CMYK in <wingdi.h>
    The RGB macro stores the values in [0,b,g,r] order of the
    COLORREF. The CMYK macro stores the values in [k,y,m,c]
    order. The main difference is the presence of "k" in the top byte
    of the COLORREF. That surprises me too, because I thought
    the top byte was being used for alpha. There's really no way for
    Windows to know whether a COLORREF contains (r,g,b) or
    (c,m,y,k). Testing for k!=0 (top byte) won't do it, because you can
    have legitimate (c,m,y) with k=0.
    So you can't put CMYK values in a COLORREF and expect
    Windows to know that they are CMYK - it will just interpret
    it as RGB, as usual.
    The only reference I could find is in the help topic "Image
    Color Matching". The CreateColorSpace() function allows
    you to specify a colour model - the LOGCOLORSPACE
    struct uses either LCS_DEVICE_RGB, LCS_DEVICE_CMYK
    or LCS_CALIBRATED_RGB. Further reading in that area
    would be a good idea. I guess if you select LCS_DEVICE_CMYK,
    then your CMYK() values will be interpreted ok.
    RGB and simple cmy are related as follows:
        R + c = 255
        G + m = 255
        B + y = 255
    (I used lowercase c,m,y to distinguish them from the values in CMYK)
    If you want to convert CMYK to RGB, do it this way:
        R=255 - (C + K)
        G=255 - (M + K)
        B=255 - (Y + K)
    To convert RGB to CMYK:
        K=min(min(R,G),B)
        C=(255 - R) - K
        M=(255 - G) - K
        Y=(255 - B) - K
--
John A. Grant  * I speak only for myself *  (remove 'z' to reply)
Radiation Geophysics, Geological Survey of Canada, Ottawa
If you followup, please do NOT e-mail me a copy: I will read it here

, 
zjag...@znrcanz.gcz.ca
 
says...
Thank's for the Tip. Here is a reference
MSDN document, like always very restrictive...
Application Support
The ICM API is designed to be controlled and used at the application
level. With ICM 2.0, there are now two levels of color management
support available at the application level: inside the DC and outside
the DC. This means application vendors can choose the level of support
necessary for themselves and their users. It is neither necessary nor
appropriate for an application to support both versions of the ICM API.
ICM inside the DC functions: These color management functions are
designed to be very straightforward to integrate into your application.
However, this ease of integration has a price, and these functions are
not appropriate for everyone. Since all of the color management is done
inside a device context in GDI, RGB is the only supported color space.
(Available in Windows 95, and the upcoming Windows NT 5.0 and Windows
releases.)
ICM outside the DC functions: These color management functions are new
with ICM 2.0. They are designed to be very flexible for applications
that need to have very broad control of color and broad support for
color spaces. (Available in the upcoming Windows NT 5.0 and Windows
releases.)


CMYK one, all my colors are wrong.
Windows does not directly support CMYK.  The CMYK macro is only useful when
communicating directly with a device which supports CMYK, such as a
Postscript printer, or when using Image Color Matching.
Otherwise, you'll have to write your own code to convert CMYK to RGB for
display.
--
- Tim Roberts, 
ti...@probo.com
  Providenza & Boekelheide, Inc.