RAW White point slider does not have any effect on the dir browser's thumbnail [Branch_3.0]

[Beep6581]

Originally reported on Google Code with ID 755

Modifying the RAW White point does not modify the thumbnail of the directory browser.
The thumb may then be darker/lighter than the edited image. It seems to be the case
for all the sliders of the RAW tab.

It may be a consequence of the fact that they are not handled by the ADD/SET mechanism
(they are even not part of the ADD/SET list in the preference window).

In a general manner, slider's behavior is complicated to understand (if possible) when
used in the ADD mode.

Reported by natureh.510 on 2011-06-08 22:24:01

[Beep6581]

I recall Olli had a patch to *simulate* raw white point for thumbs.
I think consideration was that this is a slow operation to pass for thumbs generation.
I'd say we should have a checkbox in preferences - 100% accurate thumbs or faster and
not so accurate. Then render thumbs accordingly. This will remove all questions.

If then someone wants to regenerate thumbs to be more or less accurate - change preference,
select thumbs, clear cache (partial), refresh browser.

Reported by michaelezra000 on 2011-06-08 22:33:51

[Beep6581]

Do you have an issue number, or better, a changset to point me to ?

About the thumb accuracy, ... each option in the preference is work in front of the
developper, i.e. it need times and complicate the code a little bit more. I would prefer
this solution :
- if the image is currently edited, moving a slider in the editor or in the directory
browser modify the edited image, then a simple resizing will create the thumb, instead
of doing the work twice with different result
- if the image is not edited, moving a slider will create an as accurate as possible
thumbnail, with disabled option, like it is now

With this behaviour, you'll have at least fully accurate thumbnails for edited images.

But i think that a rewrite would be more efficient :p

We are a little bit off-topic here. ;)

Btw, does the standard Exposure slider works for you (positive and negative) ?

Reported by natureh.510 on 2011-06-08 22:59:24

[Beep6581]

standard exposure slider works correct, matching 3.1
Highlight recovery works a bit different. - this is probably OK.

what you are saying on thumbnail would also work great. it makes perfect sense to show
correct thumbnail is work was already done for rendering preview.

BTW, what format is RT thumbnail 16 bit. Can I open it with any other software?

Reported by michaelezra000 on 2011-06-09 00:22:23

[Beep6581]

I am still searching for raw white point simulation issue

Reported by michaelezra000 on 2011-06-09 00:23:00

[Beep6581]

BTW, brightness slider works differently in 3.0 and 3.1 - compare at -100 and +100

but so do many other things...

Reported by michaelezra000 on 2011-06-09 00:59:25

[Beep6581]

Eat that :)

This patch, to be applied over Branch3 (3.0B1.44, changset 392a6d9b9e02), changes the
way the batch editor's sliders behave:

- if only one file is selected, all sliders are in SET mode
- if more than one file is selected, the ADD/SET mode depend on the preference

The range of the slider in ADD mode is now twice the range of the same slider in SET
mode, so you'll be able to reach the total range for each image at each session. Overflows
are correctly handled.

I've added more sliders in the preference window (the one that are not listed behave
in SET mode, like before). It's also easier to code for the developper, as the Adjuster
class now handle the "add" booleans, instead of each tools. But it's still spreaded
all over the code :-/

Furthermore, when clicking on the reset button of a slider, it now reset to the system
default value ; resetting to the value of the loaded profil can still be done with
CTRL+click on the reset button. This behavior is available in the Editors and in the
Batch Editor if only one file is selected.

-----

The RAW white point still not reflect it's value to the thumbs, but i've seen that
some sliders launch a demosaicing even for the thumbs, so :
1. should i enable the real RWP for the thumbs
2. should you disable the use of demosaicing for the thumbs ?
3. leave everything as is and report back Odui's patch for RWP (time matters a lot
now)

... and what about this Brightness slider ? Why does it give a different result ? (still
not compared myself).

Reported by natureh.510 on 2011-06-13 01:31:37

---

• Attachment: batchEditorsSliders.patch

[Beep6581]

Hombre, this is interesting, I will need to compile lcms1 on 64 bit to give this a try!

We need to put together guidelines on how to edit the code when new tools are being
added, so that specific functionality, such as this, for example, is not overlooked.

Reported by michaelezra000 on 2011-06-13 02:55:15

[Beep6581]

"Furthermore, when clicking on the reset button of a slider, it now reset to the system
default value ; resetting to the value of the loaded profil can still be done with
CTRL+click on the reset button."
Could you please add a tooltip with this info, when hovering over the reset icons?

I applied your patch and recompled. I set exposure=1EV in a new profile, loaded a photo,
applied that profile, changed exposure to 2, clicked reset and it reset to 0. Good
so far. I changed it back to 2 and ctrl+clicked reset, still 0. Wasn't it supposed
to change to 1EV with ctrl+click?

Reported by entertheyoni on 2011-06-13 17:08:32

[Beep6581]

No, i think i didn't explained well : the memorized value is the one of the profile
when the image is loaded in the Editor, which create the very first entry in the History.
Loading a profile when the image is already in the Editor creates a new entry, so it
won't be used for the reset.

Reported by natureh.510 on 2011-06-13 17:19:53

[Beep6581]

I did not get a chance to test, but I think it will be more intuitive if 
a. Reset will return values to initial and 
b. Ctrl-Reset to the "default" values.

The "default" values, however, are those hardcoded, not from the RT's profile chosen
to be the default. This should be clearly explained to the users in the manual. 

May be it is more intuitive to use Ctrl-Reset to set params to 0/false?

Reported by michaelezra000 on 2011-06-13 18:02:48

[Beep6581]

That's your opinion ; i for one find this default behaviour very annoying, as i always
want to suppress an effect when clicking on reset...

Maybe someone else could share his point of view !?

Reported by natureh.510 on 2011-06-13 19:03:02

[Beep6581]

About point 4 : Oduis made a patch recently for the RAW White Point trick, and i reported
it back to 3.0.

About comment 5 : you're right Michael, the Brightness slider gives very different
result, but haven't it something to do with lcms2 eventually ?

Anyway, that's why i wished to separate the Cache directory between releases, as by
all evidence, we won't be able to ensure compatibility, and that users will need to
keep previous versions...

Reported by natureh.510 on 2011-06-13 19:17:08

[Beep6581]

Hombre, about Reset - it actually makes no difference as long as tool-tip has explanation;)

I don't think that lcms2 alone would be responsible for such difference in brightness.
Emil would likely know more in this area.

Reported by michaelezra000 on 2011-06-14 00:21:47

[Beep6581]

Was the raw white point behavior ported to the thumbs processing too?  If not, you are
catching a glimpse of what I find maddening about the current code base -- make a change
to rawimagesource.cc, and you knock the alignment of the imaging pipelines off unless
you make comparable changes to rtthumbnail.cc.

IIRC, thumbs don't use demosaicing but rather just a block average or subsampling of
raw values similar to halfsize, otherwise thumbs generation from raw would be excessively
slow.

Reported by ejm.60657 on 2011-06-14 01:34:28

[Beep6581]

Hombre, although I still could not compile the 3.0 on 64 bit to test, I looked at the
code changes. Curious, why no setAdjusterBehavior() in defringe.cc ?

Reported by michaelezra000 on 2011-06-14 02:46:45

[Beep6581]

@emil

Not in the uploaded patch, but it will be included in the commit.
There's a difference in the editor itself, not only in the thumbs.

@michael

3 C/A tool int the same software... isn't that a little bit too much ? Maybe i should
have created the mechanism for this tool too, or remove the ones for the 2 other C/A
tools as i guess that it will only be used in SET mode (relative adjustment doesn't
make much sens here).

Btw, there's plenty of sliders that are not handle because it will surly only work
in SET mode. Having this mechanism centralized somewhere would have been better!

Reported by natureh.510 on 2011-06-14 12:45:15

[Beep6581]

Two of the CA tools will be combined in a future revision of the interface; it's just
a low priority at the moment.  Each tool does something different.

Reported by ejm.60657 on 2011-06-14 13:32:45

[Beep6581]

I posted this in the wrong issue yesterday, here is my response:

What I really want is to be able to turn off (set to the neutral value) every slider,
filter, etc.

To be honest it doesn't make much difference to me whether just-clicking or ctrl+clicking
on reset changes the value to 0, but if I had to choose, I'd vote for having just clicking
on reset change it to 0 (or whatever the neutral value is).

Reported by entertheyoni on 2011-06-14 20:27:16

[Beep6581]

@hombre on comment 11: "Maybe someone else could share his point of view !?"

Yes me. Reset to default should mean Reset to 0 or neutral, not to the last saved state.
If I want to reset a slider/function, I want it to go to 0/neutral, instead of the
(eg.) +35 value in the contrast slider of the last session. This is annoying behavior
when one has batch processed some 200 raws with a my_default profile. 

Reset to default should reset to 0/neutral.

Reported by paul.matthijsse4 on 2011-06-15 21:46:28

[Beep6581]

Patch applied.

Reported by natureh.510 on 2011-06-20 23:15:23

• Status changed: Verified

[Beep6581]

Reported by rinni@gmx.net on 2013-01-28 14:25:02

• Status changed: Fixed