Ecco un esempio di come cattive prestazioni di un sistema di gestione colore possano dipendere da un profilo realizzato con poca cura. Il problema degli scum dots (punti sporchi) riguarda i profili delle stampanti CMYK.

Il problema si può illustrare con l'aiuto di Photoshop.

1. Creare un nuovo file RGB (qualunque profilo) o Lab totalmente bianco.
2. Convertire in qualunque CMYK con intento colorimetrico relativo o percettivo (non colorimetrico assoluto) e motore non Adobe (perchè il motore Adobe corregge questo inconveniente).

Infatti, a parte il rendering colorimetrico assoluto (che fa corrispondere il bianco di origine con lo stesso colore di destinazione), tutti gli altri rendering (percettivo, colorimetrico relativo e saturazione) dovrebbero effettuare la compensazione del punto bianco (anche se ciò non è standardizzato dalle specifiche ICC).

Se controllate il risultato con il contagocce vedrete che probabilmente non è così nel vostro caso (nell'immagine qui sopra il pixel selezionato è 1C 1M 1Y 0K).

Se invece nel vostro caso tutto funziona correttamente (cioè RGB 255 viene convertito in CMYK 0) significa che o (1) il vostro profilo CMYK è corretto oppure (2) il motore di colore ha compensato l'errore. Provate con un altro profilo e/o con una altro motore.

Per evidenziare l'effetto, in Phottoshop aprire Immagine > Regola > Livelli e spostare il triangolo nero di input tutto a destra. Se l'immagine appare come qui sotto significa che con i profili e con il motore di colore utilizzati il problema si verifica. I punti non sono tutti uguali come dovrebbe essere, ma vengono a crearsi anche dei punti "sporchi" (scum dots).

Whitepoint problems are well known in two fields:

• separation from RGB- or Lab-Files
• proofing with the relative colorimetric intent (no paperwhite)

In fin dei conti il responsabile è dunque il programma che ha costruito il profilo (oppure l'errore può derivare da un editing del profilo).

Per esempio se il numero di griglia delle tabelle da Lab a CMYK è pari, il bianco non è presente nella tabella, e quindi il motore di colore deve interpolare. Tra l'altro, diversi motori di colore possono portare a risultyati diversi.

Whitepoint-problems are always resulting from the combination of the icc-profiles and CMMs. There is no clear declaration in the ICC-specs to proof an ICC-profile or an CMM for correct handling of the whitepoint !!!!
It is not only important which CMM is combined with which ICC-profile, it is also very important wich version of the CMM is used and which version was the software for profile generation. Also it is important, if an ICC-profile has been edited with another software. (Jan-Peter Homann)

Chris Murphy ha trovato che in MacOS il problema è più grave con KodakCMM, meno grave con AppleCMM e ancor meno grave con AdobeCMM. In particolare i profili fatti da ProfileMaker 3.1.2 hanno questo problema con tutti i CMM (ma meno con AdobeCMM), mentre i profili fatti con ProfileMaker 3.1.4 continuano ad avere questo problema con tutti i CMM escluso AdobeCMM.

Usare un profilo costruito correttamente (o modificare il profilo non corretto)

I wrote a quick routine to fix up the PCS whitepoint definition that is (possibly) miss-specified in the GretagMacbeth profiles. Even with this fixed white point they still create "scum dots" sometimes in Photoshop.
Should I write an additional tool in the Profile Medic part of ColorThink that cleans up scum dots? I have noticed that the curves in the Photoshop-bundled profiles are "pegged" at the ends to avoid this problem. (Steve Upton)

Well I don't know what the effect of doing this is on say the 1% through 5% dot sizes and if it would alter them. Unless you're really sure that the profiles *OUGHT* to have this modification from the get go (i.e. the vendors are doing something wrong), then I would like to see this idea subject to more scrutiny before proceeding with that feature. (Chris Murphy)

I downloaded the "SWOP TR001 CHROMix ltGCR320.icc" profile run it though an internal Adobe profile testing program. It has scumdot problems in the Lab->CMYK direction.
For example, in the Lab->CMYK direction, it convert pure PCS white to:
CMYK 0.3417% 0.2607% 0.1264% 0.0000% for the perceptual intent.
CMYK 0.3873% 0.2974% 0.3240% 0.0000% for the relative colorimetric intent.
CMYK 0.3572% 0.2668% 0.1290% 0.0000% for the saturation intent.
The problem is with ProfileMaker itself. It does not appear to be using the correct PCS white point encoding. Details of the PCS white point encoding can be found at www.color.org. (Thomas Knoll)

Usare un motore che corregge l'errore del profilo

L'inconveniente potrebbe essere risolto dal CMM, se convertisse il bianco di origine direttamente nel bianco di destinazione, senza consultare le tabelle degli intenti di rendering (a meno che non sia richiesto un rendering assoluto).

Classifica dei migliori motori di colore (relativamente agli scum dots):

1. Apple CMM (migliore)
2. Adobe ACE
3. Kodak CMM
4. Heidelberg CMM (peggiore)

Now maybe one can effectively "blame" this on improperly built ICC profiles, but I blame the CMM's (all of them) more than the profile. The CMM should be smarter than the profile and not allow the profile (which is just a text file afterall) to mandate a non-zero result with perceptual, relative colorimetric, and saturation rendering.

At this point there are so many screwed up profiles floating around, even embedded in images and archived, that even if you fix the problem in ICC profiles themselves it is NOT ENOUGH. The CMM needs to take control of this situation. It's the fastest way to do it, it ensures the same results regardless of who made the profile, and it's the only way to deal with legacy profiles and prevent this cockamamie problem from happening.

I don't care if the profile doesn't contain correct data regarding white or not. White should NEVER be interpolated. The PCS should be irrelevant. White point adaptation should be irrelevant. 255r,255g,255b should always, always, always, always convert to non-image/non-ink values (255,255,255 for RGB and 0,0,0,0 for CMYK). CMM's should know this and do an end run around the profile -i.e. IGNORE the profiles themselves whenever a pixel with a value of 255,255,255 or 0,0,0,0 is encountered while using the relative colorimetric, perceptual or saturation rendering intents. Any kind of effort on interpolating white should only occur with absolute colorimetric. (Chris Murphy)