Color profile from Tiff file

Software RawTherapee
10

Hello Guillaume

I will speak in French, the subject is sufficiently complex, not to add a language that I do not master well.
But I will do a translation so that the forum can follow.

==========
Sujet oh combien complexe. En temps normal, pour élaborer un profil ICC on part d’un fichier raw “étalonné” . A la fin avec le TIF produit par “Save Reference Image” (onglet Color). Avec ce TIF et les données de la mire (ici la colorchecker24) on élabore un profil ICC qu’on applique ensuite à toutes les images que l’on souhaite “traiter”. Ce profil est appliqué très en amont dans le processus. Tout ce traitement se fait en mode linéaire, sans gamma.

Ici pas de Raw, mais un TIF, d’où des difficultés qui apparaissent. Car une fois l’image obtenue et un profil créé …où le mettre ?

1ere solution:
Examinons le processus que tu décris. Tu as choisi a priori la sortie en TIF gamma=2.2, pourquoi pas, mais le linéaire devrait être (probablement ?) meilleur.
Mais quel est l’illuminant (l’éclairage du microscope), point important car selon celui-ci le CRI (Color Rendering Index) sera plus ou moins bon…et pas moyen de corriger.

Ensuite la balance des blancs, en TIF, les moyens de contrôle sont (très) limités. Mais tu peux utiliser dans “White Balance” - Pick - sur une des cellules grises de la Corchecker24. Regardes les caractéristiques et choisis celle qui les valeurs “a” et “b” en mode Lab les plus petites. La cellule 22 semble “la moins mauvaise”.

A priori ne pas mettre de correction d’exposition, car elle intervient “après” dans le pipe-line.
Si tu n’as pas moyen de changer à la prise de vue…difficile…

Ensuite, pas de conversion vers Adobe ou autre chose, pas d’utilisation de “Abstract profile” (au moins dans cette hypothèse). Mais utilise “Save Reference Image” (onglet Color).

2ème solution qui est complètement différente de celle-ci. Ceci suppose que tu te serves de Rawtherapee pour regarder, traiter tes images.
Utilise le processus que je propose dans Rawpedia en se servant de “Abstract Profiles” et Ciecam (Color Appearance & Lighting)
https://rawpedia.rawtherapee.com/Color_Management#Possible_example_of_use_to_modify/improve_the_behavior_of_the_Input_profile
ou le même en français
https://rawpedia.rawtherapee.com/Color_Management/fr#Exemple_possible_d’utilisation_pour_modifier_/_am%C3%A9liorer_l’action_du_profil_d’entr%C3%A9e

Je pense que la deuxième solution, et l’utilisation de “Paste partial” “Color management”, devrait répondre (peut être ? ) à tes attentes.

Je vais te passer un message perso pour que tu aies mes coordonnées.
Jacques

=====
Oh so complex subject. Normally, to develop an ICC profile we start from a “calibrated” raw file. At the end with the TIF produced by “Save Reference Image” (Color tab). With this TIF and the data from the target (here the colorchecker24) we develop an ICC profile which we then apply to all the images that we wish to “process”. This profile is applied very early in the process. All this processing is done in linear mode, without gamma.

Here no Raw, but a TIF, hence the difficulties which appear. Because once the image is obtained and a profile created…where to put it?

1st solution:
Let’s look at the process you describe. You chose a priori the TIF output gamma=2.2, why not, but the linear one should be (probably?) better.
But what is the illuminant (the lighting of the microscope), an important point because depending on it the CRI (Color Rendering Index) will be more or less good…and there is no way to correct it.

Then the white balance, in TIF, the means of control are (very) limited. But you can use “White Balance” - Pick - on one of the gray cells of the Corchecker24. Look at the characteristics and choose the one with the smallest values “a” and “b” in Lab mode. Cell 22 seems “the least bad”.

A priori, do not use exposure correction, because it occurs “after” in the pipeline.
If you don’t have a way to change when shooting…difficult…

Then, no conversion to Adobe or anything else, no use of “Abstract profile” (at least in this hypothesis). But use “Save Reference Image” (Color tab).

2nd solution which is completely different from this one. This assumes that you use Rawtherapee to view and process your images.
Use the process I propose in Rawpedia using “Abstract Profiles” and Ciecam (Color Appearance & Lighting)
https://rawpedia.rawtherapee.com/Color_Management#Possible_example_of_use_to_modify/improve_the_behavior_of_the_Input_profile

I think that the second solution, and the use of “Paste partial” “Color management”, should meet (maybe?) your expectations.

I will send you a personal message so that you have my contact details.

Jacques

1 Like
11

@Guillaume

J’ai oublié ta remarque sur la différence entre les 2 TIF - 5.9 et 5.10

Je ne vois qu’une raison possible, le changement de “Observer” qui sert en colorimétrie avec l’illuminant et les couleurs de base de l’image.

5.8 et avant Observer 2°
5.9 Observer 10° - c’est ce que recommande la CIE
5.10 - Observer 2° - car les anomalies trouvées ont été trop importantes… Normalement il y a “compatibilté”… Mais dans ton cas, puisque tu commences de rien, pas d’importance.

=========
I forgot your remark on the difference between the 2 TIFs - 5.9 and 5.10

I only see one possible reason, the change of “Observer” which is used in colorimetry with the illuminant and the basic colors of the image.

5.8 and before Observer 2°
5.9 Observer 10° - this is what the CIE recommends
5.10 - Observer 2° - because the anomalies found were too significant… Normally there is “compatibility”… But in your case, since you are starting from nothing, it doesn’t matter.

Jacques

12

Hello @jdc,
I am staying in English so other people can comment on our discussion. Thankfully, deepl is our friend :wink: .

I see, it makes sense. I suppose that the values provided by Xrite ColorChecker are using Observer 2°.

The default encoding gamma is 0.45, which corresponds to the invert of 2.2. I did quite a lot of tests with linear TIF. Results were bad with RT 5.9 but I can try again with RT 5.10.

The illuminant temperature is 6500 K with LED. White balance and exposure are adjusted before the picture shot, using a QPcard 101 black/gray/white target. All the set-up is warmed up for 15 minutes to avoid color shifts.

The idea is indeed to use RT to process an entire batch of photographs taken with the exact same parameters. However, I am not the only user of the optical microscope and the process has to be as simple as possible, typically using a saved preset.

Your solution is interesting. Will it be as precise as using an ICC or DCP profile?

Thank you so much, your answer is very helpful :+1: .

13

Hello Guillaume

Nothing prohibits combining the 2 approaches.

The first via an ICC or DCP profile seems more “rational” (which is completely false), it is simply more usual.

The instructions for sharing “partial paste” may be a little more complex, in that it will require an additional step (this is only a learning problem).

As far as precision is concerned, it is only a question of patience and doing it once, modifying the primaries and the TRC (Tone Response Curve) once, to obtain the desired results. I think (I believe) that the differences in terms of deltaE (maybe I am wrong), must be minimal.

Perhaps, not sure, to check that using the “Local adjustments” with the deltaE (we are not talking about the same thing as Colorchecker, but about the algorithm that I developed), should allow a better final rendering with the use of what is currently in the “lacam16n” branch. Indeed, with several RT-spots we must be able to target more precisely the adaptation of the primaries (and the TRC) to each color range. After more rethinking, I think I went too fast, it must not be able to work with.
Executables - Pull Request - lacam16n
https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions

I admit that “Abstract profiles” or its equivalent in LA are not conventional approaches (to put it mildly), but it works.

Jacques

14

5.10 fixed a long-standing bug in which the lockable color pickers and the navigator showed incorrect L*a*b* values (Issue #5408).

2 Likes
15

Hello Jacques, hello to all
It was a real pleasure to discuss with you by phone. Thank you for your advice. Here is an update on my work using RT 5.10, as this version corrects L* a* b* bug. Sorry for the delay, it’s not my only project.

ICC profile creation
1) Reference image with RT
Starting with BabelColor Macbeth chart, I saved it as a reference image. It’s identical to the original image, still a gamma-encoded one and not a linear one.

2) Linear with RT
input profile: AdobeRGB; abstract profile: linear; output profile: Prophoto. The resulting image was processed with DcamProf.

scanin.exe -v -p -dipn -F %corners% target.tif ColorChecker.cht cc24_ref-new.cie
dcamprof.exe make-profile -g cc24-layout.json target.ti3 target.json
dcamprof.exe make-icc -t linear -W -n target_dcam target.json target_dcam.icc

Here is the profile displayed with GamutVision, in dotted line. The plain line is the AdobeRGB profile. As you can see, they are strongly different.
gv_lin_RT

3) RT with linear Gimp
input profile: AdobeRGB; abstract profile: none (=sRGB); output profile: RTv4_medium. The image is then converted to linear using Gimp. There is almost perfect agreement between the two profiles.
gv_nometa_RT_lin

4) DcamProf options
Adobe RGB and its equivalent RTv4_medium use D65 as the illuminant. Adding this option to make-profile induces a shift of green vertex to the right (not shown).

dcamprof.exe make-profile -i D65 -g cc24-layout.json target.ti3 target.json

acr option is often suggested for make-icc. The result is shown below, clearly degrading the profile.

dcamprof.exe make-icc -t acr -W -n target_dcam target.json target_dcam.icc

gv_nometa_RT_lin_acr

ICC profile usage
Input profile: the one obtained in step 3 above; abstract profile: linear; output profile: RTv4_medium. L* a* b* values are as follows:

  • A1 dark skin: 37.2/13.6/13.5 (ΔE_2000 = 0.95), expected values are 37.54/14.37/14.92
  • F3 cyan: 46.8/-35.9/-31.0 (ΔE_2000 = 3.95), expected values are 49.57/-29.71/-28.32

Color accuracy is excellent on dark skin patch. Cyan patch is not as good but is expected to be difficult as it is outside of the sRGB color space. Next step is to check this protocol with a TIFF obtained from a flatbed scanner. Finally, I will be able to apply it on my microscope images which are very similar. I’ll keep you in touch.

1 Like
16

I neglected to mention that when profiling, turn off the abstract profile. It leverages the same tools used for color management, but is intended for applying creative effects.

1 Like
17

In french first :

Bonjour Guillaume

Je suis vraiment content que les échanges d’informations lors de la vidéo de la semaine dernière, t’ont permi d’arriver à obtenir un résultat acceptable. Comme je te l’ai dit, peu importe la manière (calibrer un TIF n’est pas courant), l’essentiel est que tu sois satisfait du résultat.

Les résultats de deltaE sont tout à fait acceptables, le cyan est un “poil” limite, mais c’est correct.
Tiens nous au courant des suites éventuelles.
Merci

And in english

I’m really pleased that the exchange of information in last week’s video enabled you to achieve an acceptable result. As I said, it doesn’t matter how you do it (calibrating a TIF is not common), the main thing is that you’re happy with the result.

The deltaE results are quite acceptable, the cyan is a “hair” borderline, but that’s okay.
Keep us posted on any further developments.
Thanks

Jacques

18

Hi @Lawrence37 ,

What do you mean by turning it off? Is it the linear value? I am surprised that the default is falling to sRGB. I understood the process like this, but correct me if I am wrong.

  • input profile: convert to linear,
  • abstract profile: apply gamma + creative effects,
  • output profile: define primaries,
  • rendering intent: dilatation/compression/clip to the output profile.

Thanks.

19

Something is weird - the default is “None”, or at least was for a while. I haven’t recompiled in a while, but it’s definitely “none” on my fairly old build.

You may find WIP: Bundled profile for reference image by Entropy512 · Pull Request #6646 · Beep6581/RawTherapee · GitHub somewhat useful - apologies for not finishing this one prior to 5.10, I was catastrophically burned out last year and I’m still recovering from the mental health issues a new supervisor at my old job caused.

I would strongly recommend working with linear tiffs if possible… Possibly the reason you might have had undesirable results is that these tiffs might not be properly tagged with an ICC profile, and RT/gimp might be interpreting them as gamma-encoded when they’re not. Can you give an example file of a linear TIFF export so we can check the color profile?

Also, you had your working profile and output profile differ - you either want to use RT’s reference image function (which won’t properly tag the output, but will disable almost all color management), or set the working profile to be the same as the output and input profiles so that all color management transforms are a no-op. (see my pull request)

Sorry for not fully reviewing everything so far - I’m traveling at the moment and just noticed this.

Edit: OK, after rereading the steps you had for RT were for a processing run after profile generation, not a profiling run. Makes more sense, but I agree that I would avoid using abstract profile. I still myself haven’t figured out what a valid use case is for it, and unfortunately, there have been frequent mistakes where people set it thinking it was necessary but it caused problems, such as Reference TIFFs are not tagged with an ICC profile that indicates linear data · Issue #5575 · Beep6581/RawTherapee · GitHub

Can you provide an example linear TIFF file from the microscope? It looks like the gamma-2.2 TIFF you posted has no ICC profile attached, if the linear ones lack a profile that’s gonna be a big problem unless you add an ICC profile using exiftool, or have software that lets you override the input profile to be linear. But in general linear is usually a better choice here. I suspect using gamma encoded images is part of your problem - especially if Zeiss used a plain 2.2 gamma, which isn’t actually what sRGB is - it’s a mix of a linear segment and gamma 2.4, which “averages out” to around 2.2 - sRGB - Wikipedia

1 Like
20

Hi @Entropy512,
You’re right, the default is none in RT 5.10 but the result is equivalent to sRGB, that’s why I was saying it was falling to it.

Thank you, I will have a look. Mental health is a real difficulty and I hope you are recovering well.

Here is one of the photographs in linear TIFF. This is a QPcard 101 chart. The expected L*a*b* values are 93/0/0, 47/0/0 and 34/0/0. As you can check, no color profile is embedded in the metadata. Here is below the output of exiftool.

exiftool 
PS > exiftool.exe .\20230929_01_ORG.tif
ExifTool Version Number         : 12.76
File Name                       : 20230929_01_ORG.tif
Directory                       : .
File Size                       : 30 MB
File Modification Date/Time     : 2023:09:29 17:04:56+02:00
File Access Date/Time           : 2024:02:26 17:31:38+01:00
File Creation Date/Time         : 2023:12:13 10:54:02+01:00
File Permissions                : -rw-rw-rw-
File Type                       : TIFF
File Type Extension             : tif
MIME Type                       : image/tiff
Exif Byte Order                 : Little-endian (Intel, II)
Subfile Type                    : Full-resolution image
Image Width                     : 2452
Image Height                    : 2056
Bits Per Sample                 : 16 16 16
Compression                     : Uncompressed
Photometric Interpretation      : RGB
Image Description               : 20230929_01
Strip Offsets                   : (Binary data 17744 bytes, use -b option to extract)
Samples Per Pixel               : 3
Rows Per Strip                  : 1
Strip Byte Counts               : (Binary data 12335 bytes, use -b option to extract)
X Resolution                    : 300
Y Resolution                    : 300
Planar Configuration            : Chunky
Resolution Unit                 : inches
Software                        : ZENcore
About                           : uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b
Creator Tool                    : ZENcore
Title                           : 20230929_01
Description                     : 20230929_01
Rating                          : 0
Date/Time Original              : 2023:09:29 12:58:24
Create Date                     : 2023:09:29 12:58:24
Sub Sec Time Original           : 00
Sub Sec Time Digitized          : 00
XP Title                        : 20230929_01
XP Comment                      :
XP Subject                      :
Image Size                      : 2452x2056
Megapixels                      : 5.0
Create Date                     : 2023:09:29 12:58:24.00
Date/Time Original              : 2023:09:29 12:58:24.00

I need both: as there is no embedded profile, I first need to generate a profile with a ColorChecker and second to process other pictures taken in the same conditions.

That’s why I am applying AdobeRGB as the input profile, which has a pure gamma of 2.2 without linear part, corresponding to the inverse of the encoding with 0.45.

Regards

21

Yup. Sometimes doing this requires having an “intermediary/interim” profile designed to make some software not make undesirable assumptions. That’s part of the rationale for the pull request I linked (and the issue referenced in it) - RT’s old “profiling” system saved out a linear TIFF with no ICC profile. This would cause some software (such as Hugin) to assume it had an sRGB transfer function. I needed to fix this to handle a camera (Mi Sphere 360) with a fixed fisheye lens, as I needed to defish in Hugin prior to feeding to dcamprof.

sRGB primaries with linear transfer function (gamma = 1.0) seems to be the “best” tradeoff as far as minimizing the chances of an undesired colorspace or gamma transform.

I admit, I use GIMP so rarely that I’m not sure what will happen if you try to roundtrip your data through it. You may find it necessary to generate your “complete” color patch image with ImageMagick or some Python scripts.

One thing I just noticed: Your gamma-encoded example file provided in your OP is 8 bits/sample. While gamma encoding compensates for this to some degree, 8 bits + sRGB is going to have quantization errors here. You really need a 16-bit linear workflow.

Something is a little strange here, although maybe you’ve got a better feeling for what is “real” and “not real”:

image
image1920×1080 368 KB

Left is your “linear” TIFF interpreted as sRGB, right is with it tagged as being linearly encoded - it looks really washed out in a manner consistent with sRGB data being misintepreted as linear to me.

22

Off means None.

The abstract profile reinterprets the colors with respect to sRGB. If you use the sRGB values, you get the identity transformation, i.e. no change in the colors.

23

@Entropy512
I don’t have the software right now with me but I believe that saving with 16 bits is only available with linear encoding. That means that the picture quality is more difficult to preview. In addition, some useful options are not available, like adding a scale or comments. But this can be overcome in post-processing. Moreover, it’s not true 16 bits as the sensor is only using 12 bits.

Concerning the result, how have you managed to convert to sRGB with Gimp? The right picture is closer to reality. I didn’t mention it to not add confusion, but there is a saturation slider during the picture shot. This specific one was taken with no increased saturation, giving a desaturated look. I should have sent you another one.

24

Well all of the things you shot are greyscale, so saturation wouldn’t make a difference, but if it is indeed that it should be brighter/more “washed out” looking, then it was as follows:

exiftool "-icc_profile<=RTv4_sRGB_Linear_g=1.0.icc" 20230929_01_ORG_icc.tif

(I copied your TIFF to a second file so I could do a comparison)

The ICC profile file above is part of that pull request I linked, or you can go into RawTherapee and use the ICC profile generator - sRGB primaries and linear transfer function (gamma=1.0), and save that wherever.

One thing I don’t know is whether dcamprof will assume all input is linear, or pay attention to the transfer function of any attached color profile. It will, obviously, ignore any color profile information (primaries, etc) since its whole purpose is to determine the color behavior. :slight_smile: I’ve only fed it linear data, with and without an attached ICC profile.

Interesting that there’s a saturation slider - so I’m guessing this is not raw sensor data, it’s already been “cooked” color-wise to some degree?

25

Guillaume

Just for info.
This “ICC profile Creator” allows you to do pretty much what you want (or almost) in terms of output ICC profile.

image

Jacques

26

@Entropy512 @jdc
Wonderful, these are the ICC profile and tools I was looking for :star_struck: !

The Macbeth chart was assembled using gimp starting from the individual patches. Don’t pay attention to the gray background, which is a mask coming from another picture.

First test
Applying RTv4_sRGB_linear using exiftool; calculating profile using dcamprof
→ before calibration deltaE avg 9.05, max 14.36
→ after calibration deltaE avg 6.15, max 9.89

Second test
Adjust exposure using RT by -0.40 EV, input profile = output profile = RTv4_sRGB_Linear_g=1.0.icc;
calculating profile using dcamprof
→ before calibration deltaE avg 8.23, max 12.05
→ after calibration deltaE avg 4.64, max 8.52
The average is below 5 which is not so bad

Here is the obtained profile, and the assembled chart before and after calibration. The result is not perfect but it is very promising. This dataset suffers from small light gradients visible on the white patch.
gv_Zeiss_508_sat0

Zeis_508_sat0_RT_lin

Zeis_508_sat0_RT_final

It seems. The raw data file is CZI, which is unkown to RT. The specifications can be found at CZI Image File Format . I need to reacquire a dataset with full saturation.

Additional question
The microscope is equipped with a light polarizer which has a strong impact on glare reflection. All the pictures above have been acquired with parallel polarization, corresponding to maximum glare. Do I need to use perpendicular polarization, which will avoid glare ? What will be the impact of glare on profiling ?

dcamprof make-profile -g 
Reading target...
Glare test before glare matching...
Warning: large dynamic range difference detected. Likely glare issue.
Camera G on darkest patch(es) is 136.9% lighter compared to observer Y.
  Y dynamic range is 4.82 stops, G dynamic range is 3.57 stops, difference
  1.24 stops. A small difference is normal, while a large indicates that there
  is glare.
Glare-matching target...
  Minimum Y changed from 0.034068 to 0.085042. Glare was modeled into the spectra.
Testing glare after adjusting reference values (camera G and observer Y should
  be close).
Camera G on darkest patch(es) is -5.1% lighter compared to observer Y.
  Y dynamic range is 3.50 stops, G dynamic range is 3.57 stops, difference
  -0.08 stops. A small difference is normal, while a large indicates that there
  is glare.

Regards,

27

@Guillaume

Too bad the Raw file is not documented and recognized by RT. This would (maybe) improve the result ?? :sweat_smile:

The problem of reflections and differences in brightness is one of the major problems when we want to calibrate…
But, by putting a polarization - which will of course reduce or cancel the reflections, what is the transformation that the illuminant undergoes?

If we want to obtain good results, but here I speak like a book, the illuminant should have a CRI of 100, like Daylight, or Tungsten stdA.

Look at these diagrams which represent illuminant versus wavelength in nm (blue to red), the ones with a CRI of 100, and the others like the LEDs at the bottom right.
As soon as the CRI is less than 100, “holes” are created which will lead to poorer reproduction – if at all – of these colors. Unfortunately there is no solution.
https://rawpedia.rawtherapee.com/Color_Management_addon/fr#Diagrammes_des_illuminants_et_Color_Rendering_Index_(CRI)

What is very comforting is that we sense the optimism and progress in your words. :+1:

Jacques

28

Yeah, definitely not currently supported, and probably something that is so niche that it would likely not be worth the effort to directly support it.

Niche applications like this are why I wrote a few conversion tools: GitHub - Entropy512/pyimageconvert: Various Python image conversion scripts - I’m a firm believer in the “Unix way” of doing things, instead of having huge monolithic tools that do everything, have an interoperable ecosystem of tools focused on a specific function. Right now I’m guessing neither libraw nor imagecodecs support CZI as it’s THAT niche, but with a few CZI samples I could probably whip up a CZI-to-DNG converter as a derivative of my existing tools. I’ve gotta give props to Zeiss - at least in theory they have a documented file format and open source libraries to support it. pylibCZIrw · PyPI should make this easy? Need to wake up to futz with it. I’ll check RPU ( https://raw.pixls.us/ ), if RPU doesn’t have them I’ll need a few examples.

As to glare - usually glare is known to cause issues. There are methods for attempting to detect/compensate for glare, but these only apply to “whole-card” shots.

29

Hi @Entropy512,
I agree, it’s really a niche application. I wouldn’t you to waste your time on it for a single person. But if you want some Zeiss CZI files for the challenge, I can provide you a few ones. However, it will probably not be representative of all the possibilities of the format. Just tell me what kind of photographs you need (chart, powder, object…). There is also another available library: czifile · PyPI. I will have a look with python.

More about saturation: I don’t know if it’s hardware or software related. My interpretation is that’s a sort of electric gain, which is then saved to RGB values without any calibration. When applying saturation, L*a*b* values move from 73.6/2.0/45.6 to 82.2/1.9/90.4 for yellow patch (D4), and from 64.9/-19.9/-2.3 to 72.4/-49.0/-4.7 for bluish green patch (F1). These 2 patches are along the a* or b* axes. One can observe roughly a doubling of a* or b* values and an increase of luminance.

I acquired a full set of ColorChecker patches on the stereo microscope with saturation. The individual gamma-2.2-encoded TIFF files were processed as follows:

  • RawTherapee preprocessing using input profile = output profile = RTv4_medium and shrinking to 500 pixels;
  • Gimp assembling and global shrinking to 1200 pixels;
  • RawTherapee conversion with input profile = RTv4_medium, output profile = RTv4_medium_linear, exposure -0.25 EV adjusted on neutral 5 patch (D4);
  • DcamProf profile creation;
  • RawTherapee input profile attribution and export to RTv4_sRGB;
  • Darktable color check using color calibration module.

Here are the results:
→ before calibration deltaE avg 5.05, max 11.52;
→ after calibration deltaE avg 3.81, max 7.44.
This is an improvement over the previous trial, but it’s still a bit high. This dataset has a homogeneous illumination but suffers from blue RGB values at 0 for yellowish colors, highlighting oversaturation. The next improvement could be reached using lacam16n.

Concerning the abstract profile, I just realized that I was improperly using it to compensate a mismatch between a linear profile and a gamma-encoded image, or the other way around.
EDIT: Is there a way to convert a linear profile to a gamma-encoded one?

Have a great weekend
Guillaume