Bernhard, the usual way to use monitor profiles is to take them as correction glass for the discrepancy of physical and ideal colour behaviour of devices like monitors.
I expect the goal of your profiles would be to simulate the protan and deutan seeing for designers to aim to better give orientation for the non standard colours seeing people. Designers have various monitors available these days. Each designer will see an other simulation. Maybe this is not that important? Anyway abstract profiles are usable at Linux/osX within CinePaint <www.cinepaint.org>. Thats about pixel manipualtion. A screenshot how to do can be found here: <http://www.behrmann.name/look_profiles.png> Photoshop and similiar applications should be able to do the same. An other problem may be that some OSs dont accept LUT based pofiles as display profiles. Even if LUT profiles are ok for the abtract type. Simply copying the original primary and gamma tags could mislead the underlying CMM, to use these display profile tags instead of the intented LUT you created. The effect would be none. regards Kai-Uwe Behrmann + development for color management + imaging / panoramas + email: [EMAIL PROTECTED] + http://www.behrmann.name Am 07.09.05, 15:36 +0200 schrieb Bernhard Jenny: > Thank you for your comments and help. > > I need a display profile to allow users to temporarily switch between the > default display profile and the custom profile simulating color blindness. > This would affect the whole monitor. > > The reason why I tried to directly generate a display profile was that I could > not find any way to combine an abstract profile with a display profile to > generate another display profile. > > The following code tries to combine the currently used display profile (read > with cmsOpenProfileFromFile) and a dynamically generated abstract profile. > Both seem to be OK. The result is not a valid display profile: > > cmsHPROFILE combineDisplayAndAbstract(cmsHPROFILE displayProfile, cmsHPROFILE > abstractProfile) { > cmsHPROFILE inProfiles[2] = {displayProfile, abstractProfile}; > > DWORD dwFlags = 0; > dwFlags |= cmsFLAGS_GRIDPOINTS(LUTRESOLUTION); > > DWORD InputFormat = TYPE_XYZ_DBL; > DWORD OutputFormat = TYPE_RGB_DBL; > cmsHTRANSFORM hTransform = cmsCreateMultiprofileTransform > (inProfiles, 2, InputFormat, OutputFormat, INTENT_PERCEPTUAL, dwFlags); > if (hTransform == NULL) > return NULL; > > cmsHPROFILE combinedProfile = cmsTransform2DeviceLink(hTransform, 0); > cmsSetDeviceClass(combinedProfile, icSigDisplayClass); > > return combinedProfile; > } > > The rXYZ, gXYZ, bXYZ and rTRC, gTRC and bTRC tags are missing in the returned > device link profile, which are mandatory in a display profile, as far as I > know. > Should I copy these tags (and possibly others too) from the original display > profile? > > Another question concerning the size of the LUT in the abstract profile: > > > Please note since the matrix is a linear transform, 8 nodes would be > > enough to model it on the CLUT. So, you end with the same profile size. > > Should I call cmsAlloc3DGrid with 8? i.e. cmsAlloc3DGrid(AToB0Lut, 8, 3, 3); > > Thank you for your help! > > Bernhard Jenny > > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
