We've had a couple of folks tripped-up over this issue, so I figure it's worth a blog posting. Early versions of the WCS documentation indicate that none of the ICM APIs that deal with specific ICC profile structures will work with WCS device model profiles (DMPs). This information is correct for all of the following APIs:

GetCountColorProfileElements
GetColorProfileElementTag
IsColorProfileTagPresent
GetColorProfileElement
SetColorProfileHeader
SetColorProfileElementSize
SetColorProfileElement
SetColorProfileElementReference
GetNamedProfileInfo
ConvertColorNameToIndex
ConvertIndexToColorName
GetPS2ColorSpaceArray
GetPS2ColorRenderingIntent
GetPS2ColorRenderingDictionary

Any of these ICM APIs will fail (return FALSE) if called using a WCS profile rather than an ICC profile.

However, this is not the case with GetColorProfileHeader. In order to enable GDI+ to utilize WCS profiles it was necessary to modify GetColorProfileHeader to accept WCS device model profiles (DMPs, extension '.cdmp'). GDI+ uses the profile header to determine the color space of the profile.

GetColorProfileHeader will create a "synthetic" ICC profile header from the WCS DMP. Such synthetic headers can be readily distinguished from headers for actual ICC profiles by examining the "signature" field in bytes 36 through 39 of the 128 byte profile header. The header for a real ICC profile will always contain 'acsp' (big endian) in the "signature" field. A header synthesized from a WCS profile will contain 'cdmp' (big endian) in the signature field, and the CMMType field in such a header will contain 'wcs1' (big endian).

So: it is not safe to assume because GetColorProfileHeader succeeded (returned TRUE) that one is dealing with an ICC profile. You should check the signature field in the header to determine that, before going on to try to parse or modify the profile as though it were an ICC profile.