The code is here.


-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

Attachments:
Download 'courbesdepoursuite.pov.txt' (9 KB)

Le 2023-10-31 à 06:07, kurtz le pirate a écrit :
> 
> 
> 
> The code is here.
> 
> 
Thank you

Post a reply to this message

On 10/31/23 06:07, kurtz le pirate wrote:
> The code is here.

Thank you!

FWIW. Because my yuqk fork playpen doesn't ship with a color.inc file, I 
first tried using the macro you included, hsb2rgb(), over CHSV2RGB(). I 
had to change the bottom part some for it to run.

...
          #elseif ( _Hue>=300 & _Hue<=360) // Was ( ... _Hue<360) ?
                 #local RED = C;
                 #local GREEN = 0;
                 #local BLUE = X; // 'x' is a vector ?
         #else
                 #debug concat("_Hue is ",str(_Hue,9,3),"\n")
                 #error "_Hue out of range in convertion ! "
         #end

         <(RED+m), (GREEN+m), (BLUE+m), 0, _Transmit>
#end

I ended up grabbing the older color.inc macros and using those because 
the colors looked better - like what you had posted - than did the 
hsb2rgb() results.

I'm not going to dig into why the difference at the moment as I have 
many other fires burning low. I need to return to those before I forget 
too much! :-)

Bill P.

Post a reply to this message

On 01/11/2023 12:08, William F Pokorny wrote:
> On 10/31/23 06:07, kurtz le pirate wrote:
>> The code is here.
> 
> Thank you!
> 
> FWIW. Because my yuqk fork playpen doesn't ship with a color.inc file, I 
> first tried using the macro you included, hsb2rgb(), over CHSV2RGB(). I 
> had to change the bottom part some for it to run.
> 
> ...
>           #elseif ( _Hue>=300 & _Hue<=360) // Was ( ... _Hue<360) ?
>                  #local RED = C;
>                  #local GREEN = 0;
>                  #local BLUE = X; // 'x' is a vector ?
>          #else
>                  #debug concat("_Hue is ",str(_Hue,9,3),"\n")
>                  #error "_Hue out of range in convertion ! "
>          #end
> 
>          <(RED+m), (GREEN+m), (BLUE+m), 0, _Transmit>
> #end
> 
> I ended up grabbing the older color.inc macros and using those because 
> the colors looked better - like what you had posted - than did the 
> hsb2rgb() results.
> 
> I'm not going to dig into why the difference at the moment as I have 
> many other fires burning low. I need to return to those before I forget 
> too much! :-)
> 
> Bill P.
> 


Thank Bill you for your very pertinent comments !


First of all, this "hsb2rgb()" macro was not supposed to be in the code.
It's not used because i'm using the "CHSV2RGB()" in the Draw() macro.


Then, there's my mistake "x" vs "X". I'm ashamed. Apologies.


Now for another point. The correction "less than or equal to 360"
instead of "strictly lower to 360". I don't agree with that.

Let's say the hue is equal to 390°. With your modification, everything
above 360 becomes red, whereas 390 (which equals 360 + 30) should be
orange.

Do you agree ?

In fact, the value of "_hue" must simply be reduced to the interval
[0..360[.

So at the beginning of the macro I added :
	#local HUE = mod2(_Hue,360);

and it's this variable that's used in everything else.


I made a little code that draws colored squares with both methods and
compared them in Photoshop. There's no difference in color.


And now the most important point. There's an error in the code. A big
error. (Yes, one more). The formula used for calculating X is wrong :
	#local X = C - (1 - abs(mod(HUE/60,2) - 1));

The good one is :
	#local X = C * (1 - abs(mod(HUE/60,2) - 1));

X = C **multiply by** ...



Last remark. To reduce the hue between 0 and 360, I use my "mod2"
function, which ALWAYS returns a positive value.

#declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }

Too many troubles with the standard mod() function ...





;)


-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

On 01/11/2023 12:08, William F Pokorny wrote:
> On 10/31/23 06:07, kurtz le pirate wrote:
>> The code is here.
> 
> Thank you!
> 
> FWIW. Because my yuqk fork playpen doesn't ship with a color.inc file, I 
> first tried using the macro you included, hsb2rgb(), over CHSV2RGB(). I 
> had to change the bottom part some for it to run.
> 
> ...
>           #elseif ( _Hue>=300 & _Hue<=360) // Was ( ... _Hue<360) ?
>                  #local RED = C;
>                  #local GREEN = 0;
>                  #local BLUE = X; // 'x' is a vector ?
>          #else
>                  #debug concat("_Hue is ",str(_Hue,9,3),"\n")
>                  #error "_Hue out of range in convertion ! "
>          #end
> 
>          <(RED+m), (GREEN+m), (BLUE+m), 0, _Transmit>
> #end
> 
> I ended up grabbing the older color.inc macros and using those because 
> the colors looked better - like what you had posted - than did the 
> hsb2rgb() results.
> 
> I'm not going to dig into why the difference at the moment as I have 
> many other fires burning low. I need to return to those before I forget 
> too much! :-)
> 
> Bill P.
> 


Thank Bill you for your very pertinent comments !


First of all, this "hsb2rgb()" macro was not supposed to be in the code.
It's not used because i'm using the "CHSV2RGB()" in the Draw() macro.


Then, there's my mistake "x" vs "X". I'm ashamed. Apologies.


In fact, the value of "_hue" must simply be reduced to the interval
[0..360[.

So at the beginning of the macro I added :
	#local HUE = mod2(_Hue,360);

and it's this variable that's used in everything else.


I made a little code that draws colored squares with both methods and
compared them in Photoshop. There's no difference in color.


And now the most important point. There's an error in the code. A big
error. (Yes, one more). The formula used for calculating X is wrong :
	#local X = C - (1 - abs(mod(HUE/60,2) - 1));

The good one is :
	#local X = C * (1 - abs(mod(HUE/60,2) - 1));

X = C **multiply by** ...



Last remark. To reduce the hue between 0 and 360, I use my "mod2"
function, which ALWAYS returns a positive value.

#declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }

Too many troubles with the standard mod() function ...





;)


-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

On 11/2/23 02:40, kurtz le pirate wrote:
> Last remark. To reduce the hue between 0 and 360, I use my "mod2"
> function, which ALWAYS returns a positive value.
> 
> #declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }
> 
> Too many troubles with the standard mod() function ...

Thanks! I've made your updates and done a couple, hsb2rgb vs CHSV2RGB, 
image compares. I too see the results matching perfectly.

Your mod2 function is a good candidate to make an inbuilt parser 
function. I've already implemented an inbuilt function in my fork called 
f_npmod which matches the internal pattern mechanism's version of:

[0, n] = {x | 0 <= x <= n}  (n == 1 always inside the pattern mechanism)

rather than mod's usual:

[0, n) = {x | 0 <= x < n}

and there is perhaps a place for a fourth form I suppose which would 
functionally be a combination of both mod2 and f_npmod.

The color manipulation macros like hsb2rgb() - traditionally in 
colors.inc - I see as better existing in an include called 
color_manipulations.inc (or similar) apart from any general color 
definitions.

The color_manipulations.inc then being a part of a separately maintained 
'extended includes' package for my yuqk fork. Who knows though, if I'll 
ever get around to maintaining and shipping such a package.

Still, I've been capturing SDL code I think would be good as part of 
such a package though - and your implementation of hsb2rgb saved aside 
for that eventual purpose.

Bill P.

Post a reply to this message

On 02/11/2023 12:33, William F Pokorny wrote:
> On 11/2/23 02:40, kurtz le pirate wrote:
>> Last remark. To reduce the hue between 0 and 360, I use my "mod2"
>> function, which ALWAYS returns a positive value.
>>
>> #declare mod2 = function (x,y) { select(mod(x,y),mod(x,y)+y,mod(x,y)) }
>>
>> Too many troubles with the standard mod() function ...
> 
> Thanks! I've made your updates and done a couple, hsb2rgb vs CHSV2RGB, 
> image compares. I too see the results matching perfectly.
> 
> Your mod2 function is a good candidate to make an inbuilt parser 
> function. I've already implemented an inbuilt function in my fork called 
> f_npmod which matches the internal pattern mechanism's version of:
> 
> [0, n] = {x | 0 <= x <= n}  (n == 1 always inside the pattern mechanism)
> 
> rather than mod's usual:
> 
> [0, n) = {x | 0 <= x < n}
> 
> and there is perhaps a place for a fourth form I suppose which would 
> functionally be a combination of both mod2 and f_npmod.
> 
> The color manipulation macros like hsb2rgb() - traditionally in 
> colors.inc - I see as better existing in an include called 
> color_manipulations.inc (or similar) apart from any general color 
> definitions.
> 
> The color_manipulations.inc then being a part of a separately maintained 
> 'extended includes' package for my yuqk fork. Who knows though, if I'll 
> ever get around to maintaining and shipping such a package.
> 
> Still, I've been capturing SDL code I think would be good as part of 
> such a package though - and your implementation of hsb2rgb saved aside 
> for that eventual purpose.
> 
> Bill P.
> 

Yes, a "color_manipulations.inc" is a very good idea.
You can use my code as you like.

I can code other colors conversion method found on
<https://www.rapidtables.com/convert/color/index.html>
Tell me if it's worth it...




-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

On 11/2/23 11:40, kurtz le pirate wrote:
> I can code other colors conversion method found on
> <https://www.rapidtables.com/convert/color/index.html>
> Tell me if it's worth it...

Thanks for the offer, but my up front answer is hold off for now - 
unless doing it for your own interests.

I'm unsure of the overall worth without diving into what is there. My 
todo list is effectively infinite - and the extended include file work 
will likely not see much attention for a while.

That said. When we do get to a color manipulation include, we'd want to 
look in more detail at the code we have long had versus any new. What we 
have I believe works. However, the immediately attractive aspect of your 
hsb2rgb() code is it's cleaner than CHSV2RGB(). No pointless conversions 
of individual parameters into a vector only to peel the vector apart 
again inside the CHSV2RGB() macro for a start.

Are the other conversion methods on that site also cleaner than what 
we've long had coded? Some like the hex color inputs would be useful 
just to have, but the end code there should probably be a parser inbuilt 
- maybe some extension of the 'srgb*' specification methods?

Bill P.

Post a reply to this message

On 03/11/2023 12:59, William F Pokorny wrote:
> On 11/2/23 11:40, kurtz le pirate wrote:
>> I can code other colors conversion method found on
>> <https://www.rapidtables.com/convert/color/index.html>
>> Tell me if it's worth it...
> 
> Thanks for the offer, but my up front answer is hold off for now - 
> unless doing it for your own interests.
> 
> I'm unsure of the overall worth without diving into what is there. My 
> todo list is effectively infinite - and the extended include file work 
> will likely not see much attention for a while.
> 
> That said. When we do get to a color manipulation include, we'd want to 
> look in more detail at the code we have long had versus any new. What we 
> have I believe works. However, the immediately attractive aspect of your 
> hsb2rgb() code is it's cleaner than CHSV2RGB(). No pointless conversions 
> of individual parameters into a vector only to peel the vector apart 
> again inside the CHSV2RGB() macro for a start.
> 
> Are the other conversion methods on that site also cleaner than what 
> we've long had coded? Some like the hex color inputs would be useful 
> just to have, but the end code there should probably be a parser inbuilt 
> - maybe some extension of the 'srgb*' specification methods?
> 
> Bill P.
> 
> 

ok. if one day you need something, don't hesitate ;)



-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

On 11/4/23 04:19, kurtz le pirate wrote:
> ok. if one day you need something, don't hesitate 😉

Thank you for the offer! :-)

Bill P.

Post a reply to this message