Thomas de Groot wrote:
> Ah... yes...? I had not really/consciously thought of that... This means 
> that picking a color from a RGB/HSL color chart in any paint application 
> will show this problem?
> 

Yes. Unless it does not explicit state that the working color space is a 
linear one like e.g. scRGB (note the 'c'). You can use the histogram 
window of IC and move the mouse across the viewing window to get the 
color value of images in scRGB that could be used directly within 
POV-Ray. Press CTRL + left mouse button to 'lock' any value. This makes 
it easier when you move the mouse to the POV editor for writing the 
value down ;)
Should I add the possibility to copy the color value directly to the 
clipboard?

-Ive

Post a reply to this message

"Ive" <"ive### [at] lilysoftorg"> schreef in bericht 
news:4aa4fcf0@news.povray.org...
>
> Yes. Unless it does not explicit state that the working color space is a 
> linear one like e.g. scRGB (note the 'c'). You can use the histogram 
> window of IC and move the mouse across the viewing window to get the color 
> value of images in scRGB that could be used directly within POV-Ray. Press 
> CTRL + left mouse button to 'lock' any value. This makes it easier when 
> you move the mouse to the POV editor for writing the value down ;)

I had not yet found that in IC (shame on me)

> Should I add the possibility to copy the color value directly to the 
> clipboard?

Yes, that would be excellent.

Thomas

Post a reply to this message

By the way, there is a "palette" option in IC, but it is greyed out. How can 
we use it? That would be the correct color picker...

Thomas

Post a reply to this message

Thomas de Groot schrieb:
> By the way, there is a "palette" option in IC, but it is greyed out. How can 
> we use it? That would be the correct color picker...

I guess that's for GIF files and such, so maybe not what you seem to 
expect ;-)

Post a reply to this message

"clipka" <ano### [at] anonymousorg> schreef in bericht 
news:4aa60e3b$1@news.povray.org...
> I guess that's for GIF files and such, so maybe not what you seem to 
> expect ;-)

Oh pity.... I had high hopes..... :-)

I would like a *correct* palette as a color picker...

Thomas

Post a reply to this message

Ive wrote:

> Are you aware that this tool (like most others) will not apply the 
> required inverse gamma correction and will result in the usual washed 
> out colors similar to jpeg image maps when used with 3.7 or 
> assumed_gamma 1.0 ?
> And to mention it again: wrong gamma correction does not only give wrong 
> brightness intensities, it changes also the hue.


Proper gamma handling on input images is definitely needed, especially 
for formats that do not carry information, there needs to be a way of 
specifying the intended gamma for that image.

I can deal with adjusting the colors I use easily, but adjusting images 
could get tiresome.

I've found in images where I started with 3.7 or assumed_gamma of 1.0, I 
get the right saturation in the final image.
-- 
~Mike

Post a reply to this message

clipka wrote:
> Warp schrieb:
>>> Likewise, how to pre-gamma-correct color values from
>>> other programs (such as color pickers).
>> 
>>   About that... I wonder if POV-Ray should offer some kind of function to
>> do that, for convenience. In the same way as eg. degrees() and radians()
>> exist for convenience, even though they don't really save a whole lot of
>> work compared to if they didn't exist.
> 
> I think that definitely yes, POV-Ray should have such a feature.

In addition, a built-in gamma_correct() could use an internal lookup table
shared with the internal image-loading and image-saving functionality.
A macro couldn't do that.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >> Likewise, how to pre-gamma-correct color values from
> >> other programs (such as color pickers).
> > 
> >   About that... I wonder if POV-Ray should offer some kind of function to
> > do that, for convenience. In the same way as eg. degrees() and radians()
> > exist for convenience, even though they don't really save a whole lot of
> > work compared to if they didn't exist.

> I think that definitely yes, POV-Ray should have such a feature.

  One problem I see with a gamma-precorrection function is that it can be
tedious to use if tons of colors have to be specified. For example, imagine
specifying a large color_map with tens of colors, each one of which would
have to be enclosed with some function call.

  Another option I can think of is to have some #-command which turns on
gamma pre-correction for all colors from that point forward. It would be
local to the current file, so #included files wouldn't be affected. That
way you could do something like:

#assume_gamma 2.2

color_map
{ [0 rgb <whatever>]
  [.1 rgb <whatever>]
  etc...
}

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>   Another option I can think of is to have some #-command which turns on
> gamma pre-correction for all colors from that point forward. It would be
> local to the current file, so #included files wouldn't be affected. That
> way you could do something like:
> 
> #assume_gamma 2.2
> 
> color_map
> { [0 rgb <whatever>]
>   [.1 rgb <whatever>]
>   etc...
> }

One problem with this is POV-Ray's way of handling colors very much the 
same as vectors. So you may have 3rd-party macros expecting and/or 
returning vectors instead of colors, which will pretty much mess up the 
whole thing:

- You can't gamma-correct vectors.
- At the moment where the vectors are turned into colors, the 
information about which file they were defined will be long forgotten.
- Some vectors intended to become colors may be subject to math (e.g. to 
tune the brightness of a light) before being explicitly turned into 
colors, but gamma-correction will normally have to be applied before the 
math.

I agree that this would be beneficial, but with the current SDL 
structure it would open up a can of worms, and probably cause more 
confusion than ease of use. (One more reason why I do advocate a 
dedicated syntax for color literals in a POV 4 SDL)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>I'm pretty sure that I am not, and will not be, the only one who gets
>confused about the new (I suppose better) approach at gamma correction in
>POV-Ray 3.7,

I add my voice to those who are sufficiently confused and frustrated already
to state that you are definitely already not the only one.

Here's my 2 cents on your list:

>  1) A simple and clear explanation behind the reasoning and motivation behind
> the new gamma correction approach, why it makes sense and why it's better
> than what POV-Ray 3.6 did.

That's good information to have but it should definitely not be number 1) on the
list. I would put this into some appendix somewhere ("If you were
wondering ... see section ...").

For me as a user of POVray, what is important is "how do I make the program
do this" and "what did I do wrong when the output looks like X rather than like
Y".

The precise reasoning behind any part of the behaviour is mostly secondary.
Interesting, for sure, but not what I would fire up the documentation for.

>  2) Why "Display_Gamma" and "File_Gamma" should always have the correct
>values for the user's system (ie. usually 2.2, or in some Macs 1.8) and
>why they shouldn't be abused for visual effects (because that's not their
>purpose).

I still don't understand this, to be honest. If PCs "usually" have a gamma
of 2.2, why do I still have to tell the PC version of POVray these things? Why
can the *default* behaviour on a PC not be the one that the majority of
users will expect?

Why do I have to futz around with ini files (and make the same change every
single time a new beta comes out because the old ini files get replaced with
the new ones every time) just to get the behaviour that one would expect for
a run-of-the-mill PC?

>  4) How to render an old 3.6 scene using POV-Ray 3.7 [...]

Definitely.

>  5) How to pre-gamma-correct input images [...]

Kinda specialized.

>  Might not be the proper place for this, but perhaps also:

>  6) If the user needs to do it, how to create an image which has no gamma
> correction at all, only non-corrected raw pixels. The example of rendering
> an image to be used for creating a heightfield could be mentioned.

Quite frankly I'd put this very high on the list. If I cannot get POVray to
do what I want, I want it to do nothing. Just keep your hands off gamma and
similar things. If I want gamma correction, I'll do it myself in a paint program
after the fact.

That's a lot easier for me than reading up online for every minor revision how
gamma is supposed to work this week and doing render after render to get to
something that actually looks the way I wanted it (because this week the preview
doesn't actually show what I get in my file).

I can think of a hundred possible scenarios where an image gets rendered on a
different computer than where it is viewed and what not, but I'd be willing
to bet dollars to donuts that the vast majority of POVray users render and view
on the same machine and have no real need for for anything beyond "I want this
to look as it does in the preview".

Notably absent from your list is what I would put on the list as number one.

You need to acknowledge that most users will read documentation NOT preemptively
to understand the subtleties of the programming, but because they're trying to
do something and it doesn't work. Number 1 on the list would be

1) My image looks (over- / under-) exposed. What should I do to make
it (darker/brighter)?

Just sayin ...


  -- S

Post a reply to this message