Thumbnails Turn Pink


#1

Hi, I have this issue where thumbnails turn pinkish. The actual image is fine, only the thumbnail. This is noticeable when images have white areas like sky. This sometimes happen once I load the file and default profile is loaded with Auto Level on. Sometimes it occurs after I do select (Neutral) profile or another profile.

I only started using RT in Dec last year. And I believe this issue existed back on v4.2.1, but I’m not 100% sure. I started to use RT 100% recently, and I noticed these pink thumbnails occuring all the time.

This is a screen capture. The 1st thumbnail is the original file, that I haven’t loaded in RT. The 2nd thumbnail is the file that I loaded in RT and thumbnail turns pinkish.

I attached sample Canon RAW file and the pp3 file.
IMG_4746.CR2.pp3 (9.2 KB)
IMG_4746.CR2 (22.7 MB)


(Mica) #2

Have you tried the newest version, 5.0-r1? Or are you still on 4.2? I’d suggest you try the latest.


#3

I am on latest version 5.0-r1-gtk3.


#4

@Morgan_Hardwood What does your DisplayCAL tell you about this photo?
(Ref: Dealing with clipped highlights — using raw white point )

Have fun!
Claes in Lund, Sweden


(Morgan Hardwood) #5
  1. The raw file is supported by camconst.json, quality A.
  2. RawTherapee’s thumbnails do use camconst.json
  3. Measured max white levels on that specific raw file (ISO 100, f/3.5 = scale factor 1) are 15335 without black subtraction. Black levels are all 2047.
  4. camconst.json uses 15180, so it’s a safe value - there should be no magenta, as you see in the magenta-free main preview.
  5. All input profile options exhibit a magenta thumb.
  6. Metadata:```
    -MakerNotes:NormalWhiteLevel=14617
    -MakerNotes:SpecularWhiteLevel=15129

@ilias_giarimis do you have any ideas?

(Ilias Giarimis) #6

I do … but only guesses with small probability of success…
Guess 1 … Color management is not active in thumbnail rendering … although same happens with “A” panel at A/B comparisons where we have no pink highlights.
2 … a shift coming from not exact conversion to 8bit integers ?? …


#7

Hi guys, thanks for looking into this. I don’t understand the technical discussion. Let me know if there is any info I can provide to help troubleshoot.

I use Mac and my camera is Canon 6D. So I would think both my computer and camera models are quite common. Kind of surprised that I have this problem.


(Alberto) #8

There seems to be a mismatch between how black (and possibly white?) levels are taken into account between the generation of the thumbnail and the main preview.
For the camera WB, this patch seems to fix the problem. It makes the code in DCraw::scale_colors (used only by the thumbnail generation, I believe) behave similarly to what calculate_scale_mul does in rawimagesource.cc (which is what the main preview uses). But if you use auto WB, you still see two different results. If somebody knows that part of the code, it should be possible to nail down the source of the mismatch…

diff --git a/rtengine/dcraw.cc b/rtengine/dcraw.cc
--- a/rtengine/dcraw.cc
+++ b/rtengine/dcraw.cc
@@ -4591,7 +4591,7 @@
 	dmax = pre_mul[c];
   }
   if (!highlight) dmax = dmin;
-  FORC4 scale_mul[c] = (pre_mul[c] /= dmax) * 65535.0 / maximum;
+  FORC4 scale_mul[c] = (pre_mul[c] /= dmax) * 65535.0 / (maximum - cblack[c]);
   if (verbose) {
     fprintf (stderr,
       _("Scaling with darkness %d, saturation %d, and\nmultipliers"), dark, sat);

(Ilias Giarimis) #9

Alberto, normaly maximum should be already = white_Level - cblack ie 15180 - 2047 = 13133 … can you print and check this ?. Because I am affraid that subtracting cblack twice we take non magenta highlights just because we clipp lower …


(Alberto) #10

Nope, maximum is white_level - black, in this case 15180 - 0. The problem is that the “global” black is 0, whereas cblack[4] = {2047, 2047, 2047, 2047}.
I admit I’m not completely sure of what I’m doing, but I’m reasonably confident that the thumbnail code and the main preview code do slightly different things… the patch above “fixes” one such mismatch, but there might be others. For example, the thumbnail code seems to have some hardcoded magic values for estimating white levels, see the comment in rtthumbnail.cc, line 940:

    // apply white balance and raw white point (simulated)

EDIT Just to clarify, I’m not suggesting that you take the above patch and apply it “as is”; rather, that is meant as a sort of hint to show someone with better knowledge where to start the investigation…


(Ilias Giarimis) #11

Ahh OK … so the thumb code needs rework

BTW … black levels also need some rework because different things appear with the same variable name (black offset of Panasonic) . etc


(Alberto) #12

This seems to be a (somewhat) unrelated issue. Well, maybe not so unrelated, but the auto WB computation for thumbnails gives (again) slightly different results than that for the main preview, and this is particularly visible in the OP image. This patch “fixes” the problem, apparently without bad consequences. I didn’t test extensively though.

diff --git a/rtengine/rtthumbnail.cc b/rtengine/rtthumbnail.cc
--- a/rtengine/rtthumbnail.cc
+++ b/rtengine/rtthumbnail.cc
@@ -881,7 +881,7 @@
         double cam_b = colorMatrix[2][0] * camwbRed + colorMatrix[2][1] * camwbGreen + colorMatrix[2][2] * camwbBlue;
         currWB = ColorTemp (cam_r, cam_g, cam_b, params.wb.equal);
     } else if (params.wb.method == "Auto") {
-        currWB = ColorTemp (autoWBTemp, autoWBGreen, wbEqual, "Custom");
+        //currWB = ColorTemp (autoWBTemp, autoWBGreen, wbEqual, "Custom");
     }
 
     double r, g, b;

(Ingo Weyrich) #13

With this patch setting auto WB on thumb in file browser does not work anymore.
Btw: Shouldn’t we move that to a new Issue on Github?


(Alberto) #14

Ingo, yes, that’s a quick’n’dirty hack to show the problem. Basically, we would like to trust the values computed by the editor when they exist. However, note that setting the auto WB from the file browser should still result in the correct output image. It’s only the thumb that is not updated (becase when mode is Auto the values will be recomputed anyway later when processing the picture).

I agree though that this should all go in a Github issue… I just posted here so that the OP could see we are working on it :slight_smile:


(Ingo Weyrich) #15

Yes, that’s what I meant.


(Alberto) #16

github issue at https://github.com/Beep6581/RawTherapee/issues/3804


#17

According to my eyes, the original photo (as can be fetched above)
shows a histogram with severe over-exposure in all channels.
Would that be of any significance in this pink matter?

Have fun!
Claes in Lund, Sweden


#18

That is what I can see in the browser, edited raw (cr2) images with severe over-exposure in all channels get pinkish thumbnails.


#19

Hi, I see that in github thread this issue has being addressed. Thank you.