opened
ikhaldeev
username_0
Hi,
I've faced some strange bug. If you try to load CMYK ICC profile from a properties file, first color space loaded with `ColorSpaces.getColorSpace(ColorSpaces.CS_GENERIC_CMYK)` will be different from subsequent. I've managed to trace the issue up to `ColorSpaces::getProfileHeaderWithProfileId` method, and it seems that ICC_Profile header can be changed during object lifetime.

I've created PR with a failing test. [https://github.com/username_1/TwelveMonkeys/pull/420](url)
CS_GENERIC_CMYK profile loaded from path has different headers during lifetime.
issue
created
ikhaldeev
username_0
I'm using current master. 

```
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
```

Under ubuntu 
```
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.4 LTS
Release:	16.04
Codename:	xenial

```
comment
created
haraldk
username_1
Interesting... It passes on Java 7, fails on Java 8. I can also make it pass on Java 8, using the following system property:

    -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider

If using an Oracle JRE, this may be a useful workaround.

This means there's difference between KCMS and LCMS color management implementations, and that LCMS does change the profile after loading.. :-/


-- 
Harald K
comment
created
ikhaldeev
username_0
Not really. The only reason I've found this - we explicitly set DestinationType in reader params for CMYK images, and because we use custom ICC profile it fails during image reading with an illegal imageType error.
comment
created
haraldk
username_1
Hi,

I just pushed a fix that I believe solves the problem. Please have a look, and report back if you still can reproduce the issue using the latest master.

-- 
Harald K
comment
created
ikhaldeev
username_0
Thank you so much!
Now it works correctly.
comment
closed
haraldk
username_1
issue