Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #5375 > unrolled thread

darkening colour

Back to article view | Back to comp.programming

Contents

  darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 01:12 -0700
    Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-06 10:52 +0200
      Re: darkening colour Bartc <bc@freeuk.com> - 2015-04-06 11:21 +0100
        Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-06 12:44 +0200
          Re: darkening colour Bartc <bc@freeuk.com> - 2015-04-06 12:54 +0100
            Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-06 14:27 +0200
            Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 05:51 -0700
      Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 04:38 -0700
        Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-06 14:52 +0200
          Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 06:25 -0700
            Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-06 17:02 +0200
              Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 09:36 -0700
                Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-07 10:52 +0200
                  Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-07 02:10 -0700
                    Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-07 11:30 +0200
                      Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-07 03:24 -0700
                        Re: darkening colour "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-04-07 13:00 +0200
        Re: darkening colour Bartc <bc@freeuk.com> - 2015-04-06 14:17 +0100
          Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 06:27 -0700
            Re: darkening colour Bartc <bc@freeuk.com> - 2015-04-06 14:39 +0100
              Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 06:48 -0700
                Re: darkening colour Bartc <bc@freeuk.com> - 2015-04-06 16:02 +0100
                  Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-06 09:44 -0700
                    Re: darkening colour Bartc <bc@freeuk.com> - 2015-04-06 21:05 +0100
                      Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-07 00:51 -0700
                        Re: darkening colour fir <profesor.fir@gmail.com> - 2015-04-07 01:12 -0700

Page 1 of 2  [1] 2  Next page →

#5375 — darkening colour

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? 

[toc] | [next] | [standalone]

#5376

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/NI-230.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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5377

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

[toc] | [prev] | [next] | [standalone]

#5378

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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5380

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

[toc] | [prev] | [next] | [standalone]

#5381

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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5382

W dniu poniedziałek, 6 kwietnia 2015 13:54:21 UTC+2 użytkownik Bart napisał:

> 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

[toc] | [prev] | [next] | [standalone]

#5379

W dniu poniedziałek, 6 kwietnia 2015 10:53:03 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> 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/NI-230.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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5383

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

> W dniu poniedziałek, 6 kwietnia 2015 10:53:03 UTC+2 użytkownik Dmitry A. Kazakov napisał:
>> 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/NI-230.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-kazakov.de/ada/gtkada_contributions.htm#8

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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5385

W dniu poniedziałek, 6 kwietnia 2015 14:52:10 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> On Mon, 6 Apr 2015 04:38:11 -0700 (PDT), fir wrote:
> 
> > W dniu poniedziałek, 6 kwietnia 2015 10:53:03 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> >> 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/NI-230.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-kazakov.de/ada/gtkada_contributions.htm#8
> 
> 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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5390

On Mon, 6 Apr 2015 06:25:03 -0700 (PDT), fir wrote:

> W dniu poniedziałek, 6 kwietnia 2015 14:52:10 UTC+2 użytkownik Dmitry A. Kazakov napisał:
>> On Mon, 6 Apr 2015 04:38:11 -0700 (PDT), fir wrote:
>> 
>>> W dniu poniedziałek, 6 kwietnia 2015 10:53:03 UTC+2 użytkownik Dmitry A. Kazakov napisał:
>>>> 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/NI-230.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-kazakov.de/ada/gtkada_contributions.htm#8
>> 
>> 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)

It is a floating-point type declared as:

   type Gdk_Stimulus is new Float;

In Ada we don't mix apples and oranges. In C one would do

   typdef Gdk_Stimulus float;

> 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?

It is quite straightforward. The code does not use any advanced features C
does not have. Cos and sin with two arguments mean

   cos (X, Cycle) = cos (2 * Pi * X / Cycle)

Basic functions are To_RGB and To_IHLS.

> ((i assume you allow that, as this is open source and more mathematical solution it is 
> not patented, or restricted etc i hope))

Sure. It is a lesser GPL (GM GPL). The algorithm is not mine, anyway.

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

[toc] | [prev] | [next] | [standalone]

#5391

W dniu poniedziałek, 6 kwietnia 2015 17:02:25 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> On Mon, 6 Apr 2015 06:25:03 -0700 (PDT), fir wrote:
> 
> > W dniu poniedziałek, 6 kwietnia 2015 14:52:10 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> >> On Mon, 6 Apr 2015 04:38:11 -0700 (PDT), fir wrote:
> >> 
> >>> W dniu poniedziałek, 6 kwietnia 2015 10:53:03 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> >>>> 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/NI-230.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-kazakov.de/ada/gtkada_contributions.htm#8
> >> 
> >> 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)
> 
> It is a floating-point type declared as:
> 
>    type Gdk_Stimulus is new Float;
> 
> In Ada we don't mix apples and oranges. In C one would do
> 
>    typdef Gdk_Stimulus float;
> 
> > 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?
> 
> It is quite straightforward. The code does not use any advanced features C
> does not have. Cos and sin with two arguments mean
> 
>    cos (X, Cycle) = cos (2 * Pi * X / Cycle)
> 
> Basic functions are To_RGB and To_IHLS.
> 
> > ((i assume you allow that, as this is open source and more mathematical solution it is 
> > not patented, or restricted etc i hope))
> 
> Sure. It is a lesser GPL (GM GPL). The algorithm is not mine, anyway.
> 

wouldnt you be maybe so kind to put me a c draft here? then i validate it and test etc.. 
if you wrote this you got a better understanding of this i think...


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

[toc] | [prev] | [next] | [standalone]

#5396

On Mon, 6 Apr 2015 09:36:46 -0700 (PDT), fir wrote:

> wouldnt you be maybe so kind to put me a c draft here?

I never touch C when I can.

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

[toc] | [prev] | [next] | [standalone]

#5397

W dniu wtorek, 7 kwietnia 2015 10:52:12 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> On Mon, 6 Apr 2015 09:36:46 -0700 (PDT), fir wrote:
> 
> > wouldnt you be maybe so kind to put me a c draft here?
> 
> I never touch C when I can.
> 
so maybe in pseudocode? or maybe you could just copy and paste the darkening (brightening?) routine here? i can revrite it to c here then,
and you could say if it seems ok

[toc] | [prev] | [next] | [standalone]

#5398

On Tue, 7 Apr 2015 02:10:05 -0700 (PDT), fir wrote:

> W dniu wtorek, 7 kwietnia 2015 10:52:12 UTC+2 użytkownik Dmitry A. Kazakov napisał:
>> On Mon, 6 Apr 2015 09:36:46 -0700 (PDT), fir wrote:
>> 
>>> wouldnt you be maybe so kind to put me a c draft here?
>> 
>> I never touch C when I can.
>> 
> so maybe in pseudocode? or maybe you could just copy and paste the
> darkening (brightening?) routine here? i can revrite it to c here then,

convert RGB to IHLS
change the luminance component in IHLS
convert IHLS to RGB

BTW, depending on the operations required, you could do everything in IHLS
and convert to RGB only when the image is transferred to the graphic
context.

> and you could say if it seems ok

You never know if C code is OK, it is like playing tennis on a minefield
using hand grenade for a ball.

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

[toc] | [prev] | [next] | [standalone]

#5399

W dniu wtorek, 7 kwietnia 2015 11:30:15 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> On Tue, 7 Apr 2015 02:10:05 -0700 (PDT), fir wrote:
> 
> > W dniu wtorek, 7 kwietnia 2015 10:52:12 UTC+2 użytkownik Dmitry A. Kazakov napisał:
> >> On Mon, 6 Apr 2015 09:36:46 -0700 (PDT), fir wrote:
> >> 
> >>> wouldnt you be maybe so kind to put me a c draft here?
> >> 
> >> I never touch C when I can.
> >> 
> > so maybe in pseudocode? or maybe you could just copy and paste the
> > darkening (brightening?) routine here? i can revrite it to c here then,
> 
> convert RGB to IHLS
> change the luminance component in IHLS
> convert IHLS to RGB
> 

those two function below ?? ->

  function To_IHLS (Color : Gdk_Color) return Gdk_IHLS_Color is      
      G  : constant GUInt16      := Green (Color);
      R  : constant GUInt16      := Red   (Color);
      B  : constant GUInt16      := Blue  (Color);
      FR : constant Gdk_Stimulus := Gdk_Stimulus (R);
      FG : constant Gdk_Stimulus := Gdk_Stimulus (G);
      FB : constant Gdk_Stimulus := Gdk_Stimulus (B);
      Result : Gdk_IHLS_Color;
   begin
      Result.Luminance :=
         To_Luminance (0.2126 * FR + 0.7152 * FG + 0.0722 * FB);
      Result.Hue := To_Hue (Get_Hue (FR, FG, FB));
      if B > G then
         Result.Saturation :=
            Gdk_Saturation (GUInt16'Max (R, B) - GUInt16'Min (R, G));
      else
         Result.Saturation :=
            Gdk_Saturation (GUInt16'Max (R, G) - GUInt16'Min (R, B));
      end if;
      return Result;
   end To_IHLS;





   procedure To_RGB
             (  Color : Gdk_IHLS_Color;
                Red   : out Gdk_Stimulus;
                Green : out Gdk_Stimulus;
                Blue  : out Gdk_Stimulus
             )  is
      Luminance : constant Gdk_Stimulus :=
                     Gdk_Stimulus (Color.Luminance);
      Hue : constant Gdk_Stimulus := Gdk_Stimulus (Color.Hue);
      C1  : Gdk_Stimulus := Hue;
      C2  : Gdk_Stimulus;
   begin
      if C1 >= Hue_Third then
         C1 := C1 - Hue_Third;
         if C1 >= Hue_Third then
            C1 := C1 - Hue_Third;
         end if;
      end if;
      if C1 >= Hue_Sixth then
         C1 := C1 - Hue_Sixth;
      end if;
      C2 := sin (Hue_Third - C1, Hue_Range);
      if C2 < S_Eps then
         Red   := Luminance;
         Green := Luminance;
         Blue  := Luminance;
      else
         declare
            C : constant Gdk_Stimulus :=
                   S_Factor * Gdk_Stimulus (Color.Saturation) / C2;
         begin
            C1 :=  C * cos (Hue, Hue_Range);
            C2 := -C * sin (Hue, Hue_Range);
            Red   := Luminance + 0.7875 * C1 + 0.3714 * C2;
            Green := Luminance - 0.2125 * C1 - 0.2059 * C2;
            Blue  := Luminance - 0.2125 * C1 + 0.9488 * C2;
         end;
      end if;
   end To_RGB;





> BTW, depending on the operations required, you could do everything in IHLS
> and convert to RGB only when the image is transferred to the graphic
> context.
> 
> > and you could say if it seems ok
> 
> You never know if C code is OK, it is like playing tennis on a minefield
> using hand grenade for a ball.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5400

On Tue, 7 Apr 2015 03:24:39 -0700 (PDT), fir wrote:

> W dniu wtorek, 7 kwietnia 2015 11:30:15 UTC+2 użytkownik Dmitry A. Kazakov napisał:
>> On Tue, 7 Apr 2015 02:10:05 -0700 (PDT), fir wrote:
>> 
>>> W dniu wtorek, 7 kwietnia 2015 10:52:12 UTC+2 użytkownik Dmitry A. Kazakov napisał:
>>>> On Mon, 6 Apr 2015 09:36:46 -0700 (PDT), fir wrote:
>>>> 
>>>>> wouldnt you be maybe so kind to put me a c draft here?
>>>> 
>>>> I never touch C when I can.
>>>> 
>>> so maybe in pseudocode? or maybe you could just copy and paste the
>>> darkening (brightening?) routine here? i can revrite it to c here then,
>> 
>> convert RGB to IHLS
>> change the luminance component in IHLS
>> convert IHLS to RGB
>> 
> 
> those two function below ?? ->
> 
>   function To_IHLS (Color : Gdk_Color) return Gdk_IHLS_Color is      
>       G  : constant GUInt16      := Green (Color);
>       R  : constant GUInt16      := Red   (Color);
>       B  : constant GUInt16      := Blue  (Color);
>       FR : constant Gdk_Stimulus := Gdk_Stimulus (R);
>       FG : constant Gdk_Stimulus := Gdk_Stimulus (G);
>       FB : constant Gdk_Stimulus := Gdk_Stimulus (B);
>       Result : Gdk_IHLS_Color;
>    begin
>       Result.Luminance :=
>          To_Luminance (0.2126 * FR + 0.7152 * FG + 0.0722 * FB);
>       Result.Hue := To_Hue (Get_Hue (FR, FG, FB));
>       if B > G then
>          Result.Saturation :=
>             Gdk_Saturation (GUInt16'Max (R, B) - GUInt16'Min (R, G));
>       else
>          Result.Saturation :=
>             Gdk_Saturation (GUInt16'Max (R, G) - GUInt16'Min (R, B));
>       end if;
>       return Result;
>    end To_IHLS;
> 
> 
> 
> 
> 
>    procedure To_RGB
>              (  Color : Gdk_IHLS_Color;
>                 Red   : out Gdk_Stimulus;
>                 Green : out Gdk_Stimulus;
>                 Blue  : out Gdk_Stimulus
>              )  is
>       Luminance : constant Gdk_Stimulus :=
>                      Gdk_Stimulus (Color.Luminance);
>       Hue : constant Gdk_Stimulus := Gdk_Stimulus (Color.Hue);
>       C1  : Gdk_Stimulus := Hue;
>       C2  : Gdk_Stimulus;
>    begin
>       if C1 >= Hue_Third then
>          C1 := C1 - Hue_Third;
>          if C1 >= Hue_Third then
>             C1 := C1 - Hue_Third;
>          end if;
>       end if;
>       if C1 >= Hue_Sixth then
>          C1 := C1 - Hue_Sixth;
>       end if;
>       C2 := sin (Hue_Third - C1, Hue_Range);
>       if C2 < S_Eps then
>          Red   := Luminance;
>          Green := Luminance;
>          Blue  := Luminance;
>       else
>          declare
>             C : constant Gdk_Stimulus :=
>                    S_Factor * Gdk_Stimulus (Color.Saturation) / C2;
>          begin
>             C1 :=  C * cos (Hue, Hue_Range);
>             C2 := -C * sin (Hue, Hue_Range);
>             Red   := Luminance + 0.7875 * C1 + 0.3714 * C2;
>             Green := Luminance - 0.2125 * C1 - 0.2059 * C2;
>             Blue  := Luminance - 0.2125 * C1 + 0.9488 * C2;
>          end;
>       end if;
>    end To_RGB;

Yes. And

   function Get_Hue (R, G, B : Gdk_Stimulus)
      return Gdk_Stimulus is
      pragma Inline (Get_Hue);
      Hue : Gdk_Stimulus := R - (G + B) / 2.0;
   begin
      if abs Hue < Hue_Eps then
         if G < B then
            Hue := -Hue_Quarter;
         else
            Hue := Hue_Quarter;
         end if;
      else
         Hue := arctan (S_Factor * (G - B), Hue, Hue_Range);
      end if;
      if Hue < 0.0 then
         return Hue_Range + Hue;
      else
         return Hue;
      end if;
   end Get_Hue;

called from To_IHLS.

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

[toc] | [prev] | [next] | [standalone]

#5384

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

[toc] | [prev] | [next] | [standalone]

#5386

W dniu poniedziałek, 6 kwietnia 2015 15:17:32 UTC+2 użytkownik Bart napisał:
> 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
> 

bnot sure uf you dont see that those two are the same (i found it as a random junk in google

http://alienryderflex.com/saturation.html

though it is working ok, though above it is mentioned that it should also up-saturate and is not, it only desaturates)

> to get luminance (those factors are approximate).
> 
> You can implement that using 3 256-byte lookup tables.
> 
> -- 
> Bartc

[toc] | [prev] | [next] | [standalone]

#5387

On 06/04/2015 14:27, fir wrote:
> W dniu poniedziałek, 6 kwietnia 2015 15:17:32 UTC+2 użytkownik Bart napisał:
>> On 06/04/2015 12:38, fir wrote:

>>> 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
>>
>
> bnot sure uf you dont see that those two are the same (i found it as a random junk in google

If the two formulae do the same thing, then you're going a long way 
about it! Working out squares and square roots...

> http://alienryderflex.com/saturation.html

That doesn't explain it either. Why don't you just try the simpler 
formula and see it if makes a visible difference? If not, then you can 
try and see if a table lookup is quicker.

(I would say that most people wouldn't be able to tell if the colour 
balance is not quite right on a partly desaturated image. Such an image 
is unnatural anyway.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web