[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

darkening colour

kenobi

4/6/2015 8:13:00 AM

s really simple metgod of multiplying
each r,g,b component by some scalar v
like

r*=f;
g*=f;
b*=f;

the appropriate way of darkening or brightening
a color? (/whole image)

or there is something better maybe?
25 Answers

Dmitry A. Kazakov

4/6/2015 8:53:00 AM

0

On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:

> s really simple metgod of multiplying
> each r,g,b component by some scalar v
> like
>
> r*=f;
> g*=f;
> b*=f;
>
> the appropriate way of darkening or brightening
> a color? (/whole image)

No, it isn't, because RGB stimuli are not proportional to the luminance.

> or there is something better maybe?

Convert RGB to the L*a*b color space change luminance, convert back. A less
computation intensive model than L*a*b, but better than awful HLS, is
described here:

http://cmm.ensmp.fr/~serra/notes_internes_pdf/...

P.S. Brightening is not always possible, because RGB color space does not
represent all visible colors. There are various techniques to approximate
lightening while keeping luminance, e.g. by compromising the color purity.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Bartc

4/6/2015 10:22:00 AM

0

On 06/04/2015 09:52, Dmitry A. Kazakov wrote:
> On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:
>
>> s really simple metgod of multiplying
>> each r,g,b component by some scalar v
>> like
>>
>> r*=f;
>> g*=f;
>> b*=f;
>>
>> the appropriate way of darkening or brightening
>> a color? (/whole image)
>
> No, it isn't, because RGB stimuli are not proportional to the luminance.
>
>> or there is something better maybe?
>
> Convert RGB to the L*a*b color space change luminance, convert back. > A less computation intensive model...

Is that what happens when I adjust the brightness control on my HD TV? I
wonder they use to do these computations at 50M pixels per second.

--
Bartc

Dmitry A. Kazakov

4/6/2015 10:45:00 AM

0

On Mon, 06 Apr 2015 11:21:57 +0100, Bartc wrote:

> On 06/04/2015 09:52, Dmitry A. Kazakov wrote:
>> On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:
>>
>>> s really simple metgod of multiplying
>>> each r,g,b component by some scalar v
>>> like
>>>
>>> r*=f;
>>> g*=f;
>>> b*=f;
>>>
>>> the appropriate way of darkening or brightening
>>> a color? (/whole image)
>>
>> No, it isn't, because RGB stimuli are not proportional to the luminance.
>>
>>> or there is something better maybe?
>>
>> Convert RGB to the L*a*b color space change luminance, convert back.
>> A less computation intensive model...
>
> Is that what happens when I adjust the brightness control on my HD TV? I
> wonder they use to do these computations at 50M pixels per second.

No idea. Is it digital all the way?

I guess you could determine what exactly goes on by feeding it with images
with standard colors, if you have a decent digital camera.

BTW, there exist color calibration software to make your display, scanner
and printer dealing with true colors. It is not cheap, though.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

kenobi

4/6/2015 11:38:00 AM

0

W dniu poniedzialek, 6 kwietnia 2015 10:53:03 UTC+2 uzytkownik Dmitry A. Kazakov napisal:
> On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:
>
> > s really simple metgod of multiplying
> > each r,g,b component by some scalar v
> > like
> >
> > r*=f;
> > g*=f;
> > b*=f;
> >
> > the appropriate way of darkening or brightening
> > a color? (/whole image)
>
> No, it isn't, because RGB stimuli are not proportional to the luminance.
>
> > or there is something better maybe?
>
> Convert RGB to the L*a*b color space change luminance, convert back. A less
> computation intensive model than L*a*b, but better than awful HLS, is
> described here:
>
> http://cmm.ensmp.fr/~serra/notes_internes_pdf/...
>
> P.S. Brightening is not always possible, because RGB color space does not
> represent all visible colors. There are various techniques to approximate
> lightening while keeping luminance, e.g. by compromising the color purity.
>

tnx for answer, is there maybe some simple c code recipe (procedure) for inc/dec of
this more correct brightness? this paper seems
hard to read

ps for desaturation i use such code

float r = color.r;
float g = color.g;
float b = color.b;

float p = sqrt( r*r*.299 + g*g*.587 + b*b*.114 ) ;

r = p + (r-p) * adjust;
g = p + (g-p) * adjust;
b = p + (b-p) * adjust;

//where adjust 0.0 o BlackWhite, 1.0 no change

and it is working fine though it didnt work when i try up-saturate

I need something like that for brightness and hue shift



> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-...

Bartc

4/6/2015 11:54:00 AM

0

On 06/04/2015 11:44, Dmitry A. Kazakov wrote:
> On Mon, 06 Apr 2015 11:21:57 +0100, Bartc wrote:
>
>> On 06/04/2015 09:52, Dmitry A. Kazakov wrote:
>>> On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:

>>>> r*=f;
>>>> g*=f;
>>>> b*=f;

>>>> or there is something better maybe?
>>>
>>> Convert RGB to the L*a*b color space change luminance, convert back.
>>> A less computation intensive model...
>>
>> Is that what happens when I adjust the brightness control on my HD TV? I
>> wonder they use to do these computations at 50M pixels per second.
>
> No idea. Is it digital all the way?

Digital until it gets to the ADC I expect (unless the LCD elements are
digitally modulated). I don't think the brightness is adjusted by
varying the back-lighting.

My point is that it might not be feasible to perform expensive per-pixel
computations in the way you suggest (although it would likely work in
YUV not RGB, which might be a little easier.).

Maybe there is a easier way even if the colour is not exact - the OP is
creating some sort of video game not trying to get a perfect colour
rendition of an Old Master.

For example, if I look at a (halftone) printed colour image under a lamp
(I won't go into the colour cast that that will give), then change the
40W bulb for a 60W one, the picture will look brighter. But surely all
I'm looking at is the 50% (or whatever) brighter reflection from C,M,K
dot? Each dot will reflect light independently of its neighbours. That
sounds like what the OP is proposing.

--
Bartc

Dmitry A. Kazakov

4/6/2015 12:28:00 PM

0

On Mon, 06 Apr 2015 12:54:18 +0100, Bartc wrote:

> On 06/04/2015 11:44, Dmitry A. Kazakov wrote:
>> On Mon, 06 Apr 2015 11:21:57 +0100, Bartc wrote:
>>
>>> On 06/04/2015 09:52, Dmitry A. Kazakov wrote:
>>>> On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:
>
>>>>> r*=f;
>>>>> g*=f;
>>>>> b*=f;
>
>>>>> or there is something better maybe?
>>>>
>>>> Convert RGB to the L*a*b color space change luminance, convert back.
>>>> A less computation intensive model...
>>>
>>> Is that what happens when I adjust the brightness control on my HD TV? I
>>> wonder they use to do these computations at 50M pixels per second.
>>
>> No idea. Is it digital all the way?
>
> Digital until it gets to the ADC I expect (unless the LCD elements are
> digitally modulated). I don't think the brightness is adjusted by
> varying the back-lighting.
>
> My point is that it might not be feasible to perform expensive per-pixel
> computations in the way you suggest (although it would likely work in
> YUV not RGB, which might be a little easier.).
>
> Maybe there is a easier way even if the colour is not exact - the OP is
> creating some sort of video game not trying to get a perfect colour
> rendition of an Old Master.

OpenGL and DirectX have color shading models already, AFAIK.

> For example, if I look at a (halftone) printed colour image under a lamp
> (I won't go into the colour cast that that will give), then change the
> 40W bulb for a 60W one, the picture will look brighter. But surely all
> I'm looking at is the 50% (or whatever) brighter reflection from C,M,K
> dot? Each dot will reflect light independently of its neighbours. That
> sounds like what the OP is proposing.

Yes, but this would change color balance. My answer was from the
colorimetric POV. Color perception which is yet another thing.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

kenobi

4/6/2015 12:52:00 PM

0

W dniu poniedzialek, 6 kwietnia 2015 13:54:21 UTC+2 uzytkownik Bart napisal:

> Maybe there is a easier way even if the colour is not exact - the OP is
> creating some sort of video game not trying to get a perfect colour
> rendition of an Old Master.
>
not quite and why no - if something could look nicer (more clear color) i would preffer to use it.. trouble is a time i need to spend to study tomes of color theory

Dmitry A. Kazakov

4/6/2015 12:52:00 PM

0

On Mon, 6 Apr 2015 04:38:11 -0700 (PDT), fir wrote:

> W dniu poniedzia3ek, 6 kwietnia 2015 10:53:03 UTC+2 u?ytkownik Dmitry A. Kazakov napisa3:
>> On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:
>>
>>> s really simple metgod of multiplying
>>> each r,g,b component by some scalar v
>>> like
>>>
>>> r*=f;
>>> g*=f;
>>> b*=f;
>>>
>>> the appropriate way of darkening or brightening
>>> a color? (/whole image)
>>
>> No, it isn't, because RGB stimuli are not proportional to the luminance.
>>
>>> or there is something better maybe?
>>
>> Convert RGB to the L*a*b color space change luminance, convert back. A less
>> computation intensive model than L*a*b, but better than awful HLS, is
>> described here:
>>
>> http://cmm.ensmp.fr/~serra/notes_internes_pdf/...
>>
>> P.S. Brightening is not always possible, because RGB color space does not
>> represent all visible colors. There are various techniques to approximate
>> lightening while keeping luminance, e.g. by compromising the color purity.
>
> tnx for answer, is there maybe some simple c code recipe (procedure) for inc/dec of
> this more correct brightness? this paper seems
> hard to read
>
> ps for desaturation i use such code
>
> float r = color.r;
> float g = color.g;
> float b = color.b;
>
> float p = sqrt( r*r*.299 + g*g*.587 + b*b*.114 ) ;

Luminance is

L = 0.2126 * r + 0.7152 * g + 0.0722 * b

> r = p + (r-p) * adjust;
> g = p + (g-p) * adjust;
> b = p + (b-p) * adjust;
>
> //where adjust 0.0 o BlackWhite, 1.0 no change
>
> and it is working fine though it didnt work when i try up-saturate

Because it is not that simple, RGB stimuli do not add up.

> I need something like that for brightness and hue shift

The method with improved HLS requires cos and sin. I don't think it should
be much slower than what you do. Here is an implementation for GTK:

http://www.dmitry-.../ada/gtkada_contribut...

If you look at the code, it is like

r = L + 0.7875 * C1 + 0.3714 * C2;
g = L - 0.2125 * C1 - 0.2059 * C2;
b = L - 0.2125 * C1 + 0.9488 * C2;

C1 and C2 are calculated from hue and saturation.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Bartc

4/6/2015 1:17:00 PM

0

On 06/04/2015 12:38, fir wrote:
> W dniu poniedziaÅ?ek, 6 kwietnia 2015 10:53:03 UTC+2 użytkownik Dmitry A. Kazakov napisaÅ?:

>> P.S. Brightening is not always possible, because RGB color space does not
>> represent all visible colors. There are various techniques to approximate
>> lightening while keeping luminance, e.g. by compromising the color purity.
>>
>
> tnx for answer, is there maybe some simple c code recipe (procedure) for inc/dec of
> this more correct brightness? this paper seems
> hard to read
>
> ps for desaturation i use such code
>
> float r = color.r;
> float g = color.g;
> float b = color.b;
>
> float p = sqrt( r*r*.299 + g*g*.587 + b*b*.114 ) ;

Where is that formula from? Colour TV used to use:

Y = r*0.3 + g*0.6 +b*0.1

to get luminance (those factors are approximate).

You can implement that using 3 256-byte lookup tables.

--
Bartc

kenobi

4/6/2015 1:25:00 PM

0

W dniu poniedzialek, 6 kwietnia 2015 14:52:10 UTC+2 uzytkownik Dmitry A. Kazakov napisal:
> On Mon, 6 Apr 2015 04:38:11 -0700 (PDT), fir wrote:
>
> > W dniu poniedzialek, 6 kwietnia 2015 10:53:03 UTC+2 uzytkownik Dmitry A. Kazakov napisal:
> >> On Mon, 6 Apr 2015 01:12:42 -0700 (PDT), fir wrote:
> >>
> >>> s really simple metgod of multiplying
> >>> each r,g,b component by some scalar v
> >>> like
> >>>
> >>> r*=f;
> >>> g*=f;
> >>> b*=f;
> >>>
> >>> the appropriate way of darkening or brightening
> >>> a color? (/whole image)
> >>
> >> No, it isn't, because RGB stimuli are not proportional to the luminance.
> >>
> >>> or there is something better maybe?
> >>
> >> Convert RGB to the L*a*b color space change luminance, convert back. A less
> >> computation intensive model than L*a*b, but better than awful HLS, is
> >> described here:
> >>
> >> http://cmm.ensmp.fr/~serra/notes_internes_pdf/...
> >>
> >> P.S. Brightening is not always possible, because RGB color space does not
> >> represent all visible colors. There are various techniques to approximate
> >> lightening while keeping luminance, e.g. by compromising the color purity.
> >
> > tnx for answer, is there maybe some simple c code recipe (procedure) for inc/dec of
> > this more correct brightness? this paper seems
> > hard to read
> >
> > ps for desaturation i use such code
> >
> > float r = color.r;
> > float g = color.g;
> > float b = color.b;
> >
> > float p = sqrt( r*r*.299 + g*g*.587 + b*b*.114 ) ;
>
> Luminance is
>
> L = 0.2126 * r + 0.7152 * g + 0.0722 * b
>
> > r = p + (r-p) * adjust;
> > g = p + (g-p) * adjust;
> > b = p + (b-p) * adjust;
> >
> > //where adjust 0.0 o BlackWhite, 1.0 no change
> >
> > and it is working fine though it didnt work when i try up-saturate
>
> Because it is not that simple, RGB stimuli do not add up.
>
> > I need something like that for brightness and hue shift
>
> The method with improved HLS requires cos and sin. I don't think it should
> be much slower than what you do. Here is an implementation for GTK:
>
> http://www.dmitry-.../ada/gtkada_contribut...
>
> If you look at the code, it is like
>
> r = L + 0.7875 * C1 + 0.3714 * C2;
> g = L - 0.2125 * C1 - 0.2059 * C2;
> b = L - 0.2125 * C1 + 0.9488 * C2;
>
> C1 and C2 are calculated from hue and saturation.
>

I see gdk-color-ihls.adb file there but im getting lost in ada code (whats Gdk_Stimulus)
Would have probably some trouble when trying to temprarily report it to c and test how it look.. Could you mabe hint a bit what is a
crusial piece and how could i re-port it?
((i assume you allow that, as this is open source and more mathematical solution it is
not patented, or restricted etc i hope))


> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-...