Random bright pixels appear when using CIECAM02 and a wide gamut color space

[Beep6581]

Originally reported on Google Code with ID 1838

Hot/Dead pixel doesnt work with CIECAM02 mode.

Pretty simple, when I use CIECAM02 Hot/Dead pixel detection doesnt work (its like if
there was automatic "switch off if CIECAM02 on"). Tested on KM-7D and Fuji S5 Pro.
Otherwise Im very happy with CIECAM02 mode. 
Screenshots provided. I can provide RAW if you wish, but its camera independent. On
100% view its like starfield.

Branch: default
Version: 4.0.10.36
Changeset: fe7d3e8bed3a
Compiler: gcc 4.7.1
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V2.22.0
Build type: RELEASE
Build flags:  -mtune=generic -fopenmp -O3 -DNDEBUG -funroll-loops -mstackrealign
Link flags: -mwindows -mtune=generic -s
OpenMP support: ON
MMAP support: ON

Win 7 x64 SP1

http://www.ulozisko.sk/obrazky/605178/CIECAM02_OFF.jpg
http://www.ulozisko.sk/obrazky/605179/CIECAM02_On.jpg

Reported by Mescalamba on 2013-04-13 00:50:55

[Beep6581]

It seems that, it does work, but only as long as you dont touch curves inside CIECAM02
(eg. if you touch lightness curve, hot pixels pops up).

Ive just tested it and when I only used CIECAM02 as output (regular curves only, without
touching pretty much anything inside CIECAM02) it does work, no hot pixels.

Reported by Mescalamba on 2013-04-13 03:02:34

[Beep6581]

Can you provide the raw and pp3 files.

It is known that CIECAM mistreats the whiteheads and blackheads, but it may be something
else !

Reported by jdesmis on 2013-04-14 05:18:46

[Beep6581]

http://www.ulozisko.sk/605584/DSCF0134.zip

Zipped RAW+PP3+JPEG (fullsize directly from RT)

Fill captcha and hit "stiahni subor" (means download file in Slovakia). Hope its ok.

Reported by Mescalamba on 2013-04-14 18:06:22

[Beep6581]

Does not work in Chromium.
Please use www.filebin.net

Reported by entertheyoni on 2013-04-14 18:12:40

• Labels added: Component-Quality, OpSys-Windows

[Beep6581]

off-topic, FYI, I could not get full dynamic range from Fuji S3 RAF files with RT. Does
it work well with S5 RAFs?

Reported by michaelezra000 on 2013-04-14 21:55:08

[Beep6581]

I think Im getting all real DR that is there with S5 and 4.0.1 RT. You can get slightly
more with latest LR/ACR but its probably more due some really good highlight reconstruction
than actually having real DR where are still original data.

S7RAW works well too, its just very inconsistent in output (well about as consistent
as S5 itself :D).

My main reason for using RT is right now colors and resolution. Getting sharp output
from S5 isnt possible without things like AMaZE or DCB.

Fuji files are unfortunately very problematic and support for them is pretty poor on
almost every RAW developer. Only RT works pretty well. And since that issue is just
CIECAM02 mode (and only if you touch lightness curve), then I think I could recommand
it to anyone for S5 files. Best results so far.

Reported by Mescalamba on 2013-04-14 22:05:32

[Beep6581]

Can you reproduce issue 715 with S5? If yes, let's discuss there

Reported by michaelezra000 on 2013-04-14 22:44:05

[Beep6581]

Cant reproduce that issue. Only thing I noticed is that LightRoom has better (or more
agressive) highlight reconstruction with S5. RT is about same level as S7RAW (which
is better than native converter from Fuji). So if there is some recovery issue, its
most likely limited somehow only to S3.

Reported by Mescalamba on 2013-04-15 00:52:49

[Beep6581]

http://www.filebin.net/x9k1gy8hqu

Sigh, re-uploaded there that package. You are killing my aDSL..

Reported by Mescalamba on 2013-04-15 01:03:25

[Beep6581]

The new issue template does say "ALWAYS provide a link to it for us to download. (...)
Use (...) www.filebin.net (...)" so I hardly see how I can be blamed for killing your
ADSL.

This has nothing to do with hot pixels. The apparently randomly distributed bright
pixels appear when using CIECAM02 and a wide gamut working color space such as ProPhoto.
Everything else can be as in Neutral.

Reported by entertheyoni on 2013-04-15 01:36:54

• Status changed: Accepted
• Labels added: Priority-Medium, OpSys-All
• Labels removed: Priority-Low, OpSys-Windows

---

• _Attachment: neutral_ciecam02_prophoto.pp3_

[Beep6581]

I'll be away for 3 days and I'm not going to discuss in detail.

but:
1) look at the "Raw histogram"  some data are"out", try "raw black level"==> 30 to
reduce artifacts

2) as I said "CIECAM02" acts as an amplifier for these defects. So by choosing a smaller
space than Prophoto (sRGB, Adobe ... BetaRGB) will reduce artifacts

3) Why check "noise reduction" with luminance = 0 ?... Try "impluse noise reduction"

:)

Reported by jdesmis on 2013-04-15 06:08:23

[Beep6581]

1) Black level works, but it doesnt make photo exactly look better, tho I guess its
usable workaround now and then.

2) Yep, sRGB helps, but again only workaround.

3) Luminace is indeed = 0, but chrominance isnt. Im not using impulse noise reduction
cause it produce some artifacts. Since 4.0.1 Im using LAB denoise and Im very happy
with results. Maybe its bit slower but as good as any other commercial NR (maybe except
Neat Image with good profiling).

About using www.filebin.net, you should probably state that "it must be used" and dont
pretend there is some choice. Sorry I cant wrap my mind why ppl who develop RT are
not able to use different browser when one doesnt work. Its bordering with being hilarious.

I hope you realize that Im trying to help you and not the other way around. I found
a problem = I report problem = so you could improve your program. Im not dependant
on RT for work, cause there are dozens of others DCraw based (ofc RT is way more advanced
than most) and I can always use ACR/LR/Capture One/DxO if I want to.

Anyway, Jacques thank you for advice.

Reported by Mescalamba on 2013-04-15 11:05:17

[Beep6581]

@Mescalamba

I'm back tonight ...

Excuse me, I do not want to hurt you, and I respect your settings
I understand that you want to help.

But CIECAM02 has known bugs, as I wrote in the documentation
https://code.google.com/p/rawtherapee/downloads/detail?name=CIECAM02-RT_en.odt#makechanges

"Limitations of CIECAM02:
This model is not perfect, and the following limitations are identified. They can lead
for certain images to process them correctly :
*we have already seen this for the Yb settings ;
*CIECAM02 is not a workspace as sRGB or Prophoto, or even Lab. So it is difficult to
control the gamut. CIECAM is even known for its problems of narrow gamut, that's why
unexpected results may occur to the limits if you're pushing up too much  the sliders
(J, C, s …) ; this may lead in critical situations (highlights, ...) to black or white
spots in these areas. Do not hesitate to use RT's tools (highlight recovery, highlight
reconstruction, impulse noise reduction, ...), or burned or black areas (raw white
and black points, avoid color shift, ...)
*large workspaces (widegamut, Prophoto, ...) can lead, in some cases, to black areas
while they won't appear in sRGB (narrowness of CIECAM's gamut).
*The noisy images will influence CIECAM, which will think that the colored dots are
realities; that's why I placed CIECAM after “denoise”
*the CIECAM model favors "cones" and takes sparsely into account the "sticks", which
means that peripheral vision is sparsely taken into account.
*So, with CIECAM, do not expect to find a cure for "difficult" pictures (overexposure,
sensor's saturation, etc...). But for "normal" images (which is the majority), advances
that seem more than significant.
*Etc...
Maybe we'll see one day CIECAMxx appearing that could overcome the lacks of CIECAM02 ?"

What is at stake is the code CIECAM02 which was developed by researchers. There are
gaps !
I could return the problem in all directions, CIECAM has limits. For example, the values
of J or Q (equivalent of L in Lab)can not be negative, the opposite of RGB or Lab data.

In the case of "DSCF0134.RAF", the raw data are "bad" and give negative values. They
will be misinterpreted by CIECAM.

But we can take into account this "raw" file with "bad" data (with settings of your
PP3)

1) we can choose another "demosaicing" "IGV" produces fewer artifacts (in this case,
with these settings) than "AMAZE"

2) we can act on the black level, try playing only "black level: blue"
  * With IGV: black level: blue=4.0 made artifacts disappear
  * with Amaze ==> 9.0 or 10.0

3)   You can also act on the workspace  (sRGB, AdobeRGB...)

4) ...

But change the native code CIECAM seems not impossible, but very difficult, it is a
work of researchers in the world (M.Fairchild, Changjun Li, Esther Perales, M Ronnier
Luo , Francisco Martínez-Verdú, M.H.Brill,  S.Susstrunk, ...) and I feel quite unable
to provide reliable changes

Thank you for your help
 :)

Reported by jdesmis on 2013-04-17 19:59:14

[Beep6581]

Hm, what about simply using hotpixel tool on "final" photo? Simply add another hotpixel
removal after CIECAM02? Im quite positive that on finished photo, hot pixel algorithm
should find and remove/replace them?

I hope I explained it in understandable way, not my native language, sorry. :D

Otherwise I understand that, thank you very much for explanation and help.

Reported by Mescalamba on 2013-04-17 21:05:44

[Beep6581]

Jacques I appreciate your thorough understanding of CIECAM02, would you please consider
the following?
1- The colored pixels appear (and disappear) random, which I would not expect if the
issue was actually related to the real image data. Would it be possible that there
is a memory leak or something similar causing this (and not necessarily in the CIECAM02
code but maybe in the input it gets)?
2- If not a bug, in other words if this is a limitation of CIECAM02, could a function
run over the code, identify these pixels and interpolate them with their neighboring
pixels to prevent the dots?

If not 1 or 2, then I suppose you can close this as INVALID/WONTFIX.

Reported by entertheyoni on 2013-04-18 00:19:05

[Beep6581]

Here is a patch:
1)fits "impulse noise reduction" to CIECAM02 (less artifacts)

2)trying to remove artifacts CIECAM02 in the case of images with "bad" rawdata

I chose to assemble "2)" with "hot/dead pixel filter", even if the algorithms are completely
different and do not act on the same data
* Hot / dead pixels ==> rawdata before demosaicing
* Bad pixels ==> Data CIECAM==> end of treatment

Of course we can add a checkbox in CIECAM ...but it's a checkbox more !

Reported by jdesmis on 2013-04-18 17:54:14

---

• Attachment: badpixelcam1.patch

[Beep6581]

I love checkboxes. :D

Patch will be part of next version?

Reported by Mescalamba on 2013-04-18 19:38:09

[Beep6581]

@Mescalamba
Must be at least one person checks if the patch works. You can check ?

Here is the same patch with
1) "sleef.c" to accelerate 
2) some detail improvements

Reported by jdesmis on 2013-04-19 06:22:51

---

• Attachment: badpixelscam2.patch

[Beep6581]

I have zero idea how it works?

Reported by Mescalamba on 2013-04-19 10:14:42

[Beep6581]

I'll check it!

Reported by heckflosse@i-weyrich.de on 2013-04-19 10:28:50

[Beep6581]

Compiles and works fine.

Reported by heckflosse@i-weyrich.de on 2013-04-19 10:52:06

[Beep6581]

Ingo

Thank you :)

Reported by jdesmis on 2013-04-19 10:55:06

[Beep6581]

Hi Jacques, I tried the patch #2. The Hot/Dead/Bad pixel filter for CIECAM seems to
be also acting as a noise reduction - it is blurring colors. Do you think there may
be a way to reduce this blurring effect, while still clean the color dots?

Reported by michaelezra000 on 2013-04-19 12:58:35

[Beep6581]

Yes we can..but in this case, there are still artifacts. 

I chose the settings (sigma) in order to remove artifacts in the "Mescalamba image"
(a little less ==> artifacts).

But with the settings "DrSlony pp3" (far from reality), there are still artifacts

The algorithm which contains a Gaussian function acts as a denoiser (light)

We can not have everything and its opposite  :)

Reported by jdesmis on 2013-04-19 13:09:53

[Beep6581]

I have slighty reduce "sigma"...So there is a "very little" less blurring effect

I also made ​​the change to CIECAM "double"

:)

Reported by jdesmis on 2013-04-19 13:59:52

---

• Attachment: badpixelcam3.patch

[Beep6581]

badpixelcam3.patch worked best on the 3 images I tested, it made the least changes to
areas that it should not have touched.

Please wait till I tag 4.0.11 before committing. I'm not convinced that this patch
is needed, or if it is needed whether it should be enabled by default or unified with
the Dead Pixels button, so committing after 4.0.11 will give up much more time to test.

Reported by entertheyoni on 2013-04-20 00:36:56

• Status changed: PatchSubmitted

[Beep6581]

+TP_PREPROCESS_HOTDEADPIXFILT;Hot/Dead/Bad pixel filter (Raw/CIECAM02)
+TP_PREPROCESS_HOTDEADPIXFILT_TOOLTIP;Try to suppress hot and dead pixels.\nIf CIECAM02
is enabled try to suppress bad pixels (brightly colored pixels).

"(CIECAM02) if the artifacts still try "raw black points"
I might not understand this. Does it increase black point if Gaussian blurring fails
to remove them? If so, should the black point sliders show the change? If they should,
they did not on the 3 images I tested this on.

Reported by entertheyoni on 2013-04-20 00:47:57

[Beep6581]

I have slightly modified the settings again to make them less aggressive ...

DrSlony
Okay wait for 4.0.11

For the "label":
a) if the check box is "enabled" in all cases "Hot/Dead pixel filter" rawdata is executed
b) if CIECAM02 is "enabled" it adds a specific "badpixels" treatment at the end of
treatment CIECAM

Of course this treatment (especially b)) acts on colored pixels and when there is some
noise (which are colored pixels) the treatment acts over and causes a little blurring
colors.

Raw black point acts differently in treating the problem at the source, but the values
​​are unpredictable because they depend on the values ​​"erroneous" before initial
interpolation. Look at the "raw histogram" of the "DSCF0134.RAF image" and you will
see that (in this case) it is impossible to suppress "erroneous" data.

However, I think this approach to be simpler, but should not be "enabled" by default.

:)

Reported by jdesmis on 2013-04-20 05:13:58

---

• Attachment: badpixelcam4.patch

[Beep6581]

Works very well, but it also seems to have an effect that is very similar to RT's automatic
CA correction! It affects some quite large colored areas, such as the vertical blue
stripe under the Indian's left arm gets desaturated. Is this effect on larger areas
intentional?

http://imgur.com/a/aqK5O

Actually I like the way it removed some unwanted colors. Look at the reflection on
the Indian's left cheek: CA correction made it bluish, but this makes it the same color
as his face.

The image is dobbiaco_bar.pef with Neutral + CIECAM02 enabled but everything in CIECAM02
set to 0:
http://rawtherapee.com/shared/test_images/dobbiaco_bar.pef

Reported by entertheyoni on 2013-04-20 21:35:51

[Beep6581]

Jacques, sorry I could not participate in further testing.. I am working on a production
outage at work for the past 50 hours and not really sure when will get some free time...

Reported by michaelezra000 on 2013-04-20 22:23:09

[Beep6581]

DrSlony

The algorithm used is near (for color component "chroma C") of "defringe". It uses
a Gaussian transformed.

I created an option:
[Color Management]
Ciebadpixgauss=false

If the variable is "false" the algorithm used for the color component, a 3x3 median
 (default)
If the variable is "true" algorithm uses a Gaussian transformed.

The processing time is almost the same - a little less with the median.
There are some rare colored pixels with "median", but there is less blurring effect.

I kept "Gauss" for luminance (Q).

What do you think of where to enable this feature:
1) as now (Raw tab) associated with hot/dead pixels
2) with a more checbox in "CIECAM tab"

Reported by jdesmis on 2013-04-21 09:36:03

---

• Attachment: badpixelcam5.patch

[Beep6581]

The same with code optimization, including not allowing division by zero

Reported by jdesmis on 2013-04-22 05:13:32

---

• Attachment: badpixelcam6.patch

[Beep6581]

Hi Jacques, badpixelcam6.patch works great!

Reported by michaelezra000 on 2013-04-22 23:21:54

[Beep6581]

Thank you for these further tweaks Jacques. I'll be able to test tomorrow or Wednesday.
From what I read here, would this option not belong better under the "Gamut control"
checkbox?

Reported by entertheyoni on 2013-04-22 23:33:13

[Beep6581]

I add a checkbox (under "gamut control") in CIECAM.

:)

Reported by jdesmis on 2013-04-23 06:54:18

---

• Attachment: badpixelcam7.patch

[Beep6581]

Great. Cant wait to test it (which means I will hope that guy which bakes RT for Win
7 will do that).

Reported by Mescalamba on 2013-04-23 13:39:26

[Beep6581]

I added this patch, automatic calculation of "adaptation scene luminosity" according
to the exif data : "shutter speed - ISO speed - F number - exposure correction".  (see
issue1827)

Reported by jdesmis on 2013-04-23 15:47:50

---

• _Attachment: badpixelcam_autoscen8.patch_

[Beep6581]

Hi Jacques, I find the new checkbox placement much more intuitive here, especially that
it its CIECAM-related.

Suggestions on the language file changes:

COLORAPP_ADAP_AUTO_TOOLTIP;If the check-box is checked (recommended) RT calculates
an optimum value from exif data.\nTo set the value manually, uncheck the check-box
first

TP_COLORAPP_BADPIX_TOOLTIP;Suppression of hot/bad (brightly colored pixels) pixels.

May be we could add explanation, if you agree that it is accurate: "\n\nThese artifacts
are due to limitations of CIECAM. alternatively, adjust image to avoid very dark shadows."

About the new auto-tool, I am curious, what should one expect if raw image capture
was underexposed? Does the Auto-calculation assume that image was exposed correctly?

Reported by michaelezra000 on 2013-04-24 02:55:32

[Beep6581]

Here the patch with new labels (your suggestions)

If image is over/under exposed, the auto-calculation use these values "exif" (over/under),but
if you want to see the impact:
+1 EV => adaptation scene luminosity (cd/m2) ==> * 2
-1 EV => adaptation scene luminosity (cd/m2) ==> / 2

Reported by jdesmis on 2013-04-24 05:06:27

---

• _Attachment: badpixelcam_autoscen9.patch_

[Beep6581]

But do not worry, "La" varies within wide limits, I bounded to 0.001 and 16384 that
match (in my view) to extreme conditions (-7EV ==> 17 EV). What is important is a good
relative position. For example at noon under a tropical sky, "La" can reach 9000cd/m2,
or a photo of a night sky with stars, led to about "La"=0.005
I also introduced (from the beginning) a "Yb" automatic correction that takes into
account the average luminance of the image.

Reported by jdesmis on 2013-04-24 06:37:59

[Beep6581]

TP_COLORAPP_ADAP_AUTO_TOOLTIP;If the checkbox is checked (recommended) RT calculates
an optimum value from Exif data.\nTo set the value manually, uncheck the checkbox first
TP_COLORAPP_ADAPTSCENE_TOOLTIP;Absolute luminance of the scene environement.\nCalculated
from the Exif data:\nShutter speed - ISO speed - F number - exposure correction)
TP_COLORAPP_BADPIX_TOOLTIP;Suppression of hot/bad (brightly colored) pixels.\n\nThese
artifacts are due to limitations of CIECAM02. Alternatively, adjust the image to avoid
very dark shadows.

Reported by entertheyoni on 2013-04-24 14:27:06

[Beep6581]

we may need to clarify "exposure correction" - to be specific, whether it is in-camera
exposure correction of RT's correction with exposure compensation parameter.

Reported by michaelezra000 on 2013-04-24 14:46:41

[Beep6581]

Here with the changes above.
I have write "camera exposure correction"

Reported by jdesmis on 2013-04-24 14:57:36

---

• _Attachment: badpixelcam_autoscen10.patch_

[Beep6581]

I added to the calculation of "La", "raw white point" and "RT Exposure compensation"

Reported by jdesmis on 2013-04-25 11:35:59

---

• _Attachment: badpixelcam_autoscen11.patch_

[Beep6581]

Great! I will try this evening:)

Reported by michaelezra000 on 2013-04-25 11:49:55

[Beep6581]

The patch increases the right panel minimum width quite a lot:
http://imgur.com/a/BxljO#0

Reported by entertheyoni on 2013-04-25 15:28:56

[Beep6581]

I made two small changes:
1) move the text "(cd/m2)" ==> the tooltip, which reduces the width of the window
2) introduce two constants, to avoid division by zero, because for some photos (rare
?), some exif data (ISO..) are absent !

Reported by jdesmis on 2013-04-25 16:21:39

---

• _Attachment: badpixelcam_autoscen12.patch_

[Beep6581]

patch12 works great!
Just an idea - would it make sense to use a hot/bad pixel slider on a scale 0-2
0- no effect
1 - median
2 - gaussian?
I don't think majority of users will ever alter the options file:)

Reported by michaelezra000 on 2013-04-26 11:51:49

[Beep6581]

Hello

2 changes:
1)for "adaptation scene luminosity", I prefer to detect if there is no exif data, or
false data, in which case I put the default value=2000 which seems preferable to 16384
(if there are exif values=​​0)

2) I changed the "checkbox" with a slider with 3 positions with your labels

:)

Reported by jdesmis on 2013-04-26 15:04:56

---

• _Attachment: badpixelcam_autoscen13.patch_

[Beep6581]

This feature is receiving sufficient testing, will be great to have it in 4.0.11 :]
Has anyone updated the manual with this feature yet?

Reported by entertheyoni on 2013-04-26 22:12:56