On 11/20/2016 12:09 AM, clipka wrote:
> Am 20.11.2016 um 04:47 schrieb Mike Horvath:
>> I'm having a problem converting between units. Here is the code I'm
>> trying to adapt to POV-Ray:
>>
>>    
https://github.com/THEjoezack/ColorMine/blob/master/ColorMine/ColorSpaces/Conversions/LchConverter.cs
>>
>>
>>         internal static IRgb ToColor(ILch item)
>>         {
>>             var hRadians = item.H * Math.PI / 180.0;
>>             var lab = new Lab
>>                 {
>>                     L = item.L,
>>                     A = Math.Cos(hRadians) * item.C,
>>                     B = Math.Sin(hRadians) * item.C
>>                 };
>>             return lab.To<Rgb>();
>>         }
> ...
>
>>
>> Here is the POV-Ray version I created:
>>
>>     // input L = between 0 and 100
>>     // input C = between 0 and 100
>>     // input H = between 0 and 360
>>     // output L = between 0 and 100
>>     // output A = between -128 and +128
>>     // output B = between -128 and +128
>>     #macro CLCH2LAB(Color)
>>         #local LCHFT = color Color;
>>         #local L = LCHFT.red;
>>         #local C = LCHFT.green;
>>         #local H = LCHFT.blue;
>>         #local hRadians = radians(H);
>>         #local A = cos(hRadians) * C;
>>         #local B = sin(hRadians) * C;
>>         <L,A,B>
>>     #end
>>
>> When I plug the vector <50,50,180> into this function I get
>> <50.00000,-50.00000,0.00000> as a result. However, the Web converter
>> (http://colormine.org/convert/lch-to-lab) says it should be
>> <51.622535970468874,-37.18943330724933,2.558221480506817>
>>
>> It's a simple function. I don't see anything obvious that is wrong with
>> it. Do you?
>
> I see something obviously wrong with the web converter: the "CIE-L*ab"
> (whatever colour space that even is supposed to be; L*a*b, maybe?)
> result it computes cannot possibly be the same as the "lab" interim
> result computed by the `ToColor` function you've posted, as that leaves
> the "L" component entirely untouched, so it should evaluate to 50.
>
> Judging from the results the web converter computes for Lch to XYZ,
> which gives out-of-range values for an obviously within-range Lch value
> of <50,50,180>, that web converter can't be trusted.
>
> The first other web converter I've tested does convert "Lch" <50,50,180>
> to "Lab" <50,-50,0>, matching your implementation.
>


THANK YOU!!

Which other converter did you use, BTW? I need to do the same for 
LAB>XYZ and XYZ>RGB as well.

Mike

Post a reply to this message

I posted my work in p.t.s-f. I used cylindrical cells, and the result is 
rather chunky. Next up is to see if I can achieve the same using 
functions only.

Mike

Post a reply to this message

On 11/19/2016 9:26 PM, clipka wrote:
> Am 20.11.2016 um 03:04 schrieb Mike Horvath:
>> On 11/19/2016 8:48 PM, clipka wrote:
>>> Am 20.11.2016 um 02:33 schrieb Mike Horvath:
>>>> On 11/18/2016 2:22 AM, Mike Horvath wrote:
>>>>> I would like to create a three-dimensional representation of the
>>>>> L*C*h(uv) color space in the form of a cylinder.
>>>>>
>>>>> How would I do that?
>>>>>
>>>>> I may limit myself to colors that also exist in the sRGB color space.
>>>>>
>>>>> Mike
>>>>
>>>> I guess my only option is to use individually painted voxels, as I don't
>>>> see how you can enter conditional statements into a function
>>>> declaration.
>>>
>>> Did you try the `select` function?
>>>
>>
>> No I didn't!
>>
>> Can I create and store local variables too?
>
> Nope; the virtual machine currently used by POV-Ray to execute
> user-defined functions was designed solely for genuine functions; it
> doesn't do anything remotely resembling programming.
>

Do you think I could make the shape using lots of little functions?

Mike

Post a reply to this message

Am 20.11.2016 um 06:51 schrieb Mike Horvath:

> Which other converter did you use, BTW? I need to do the same for
> LAB>XYZ and XYZ>RGB as well.

Actually it was a colour picker that auto-converted upon changing the
colour model:

http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker


For the most common conversion needs I found this one earlier:

http://davengrace.com/dave/cspace/

Post a reply to this message

So, I created a bunch of functions. Now how do I turn them into pigments?

(See p.t.s-f)

Mike

Post a reply to this message

On 11/21/2016 12:31 PM, Mike Horvath wrote:
> So, I created a bunch of functions. Now how do I turn them into pigments?
>
> (See p.t.s-f)
>
> Mike

Disregard. I already know how to create an approixmation of the pigment. 
Sorry.


Mike

Post a reply to this message

On 11/19/2016 3:25 PM, Le_Forgeron wrote:
> Le 19/11/2016 à 19:19, Mike Horvath a écrit :
>> On 11/19/2016 12:59 PM, Le_Forgeron wrote:
>>> Le 19/11/2016 à 18:47, Mike Horvath a écrit :
>>>>
>>>> I think it would be pretty easy to produce a macro that does all of the
>>>> above. But how do I turn that into a POV-Ray function? The function
>>>> needs to work as a color as well as an isosurface I think.
>>>
>>>
>>> Basic of povray: the shape is not bound to the texture (excepted for
>>> uv_mapping).
>>>
>>> Make the work for the shape, and separately the work to map 3D
>>> coordinates to colour.
>>>
>>
>> Okay. But how?
>
> Within the attached include file, you could replace uv_vertex with your
> computed position.
>
> The top macro is UVMeshable, first parameter is an object, just
> ignore/remove it
> The two others are the resolutions... you can simplify too for your
> usage (getting ride of uv_min & uv_max).
>
> mesh{
> UVMeshable...
>
> then you insert the uv_mapped texture (and I already provided some code
> for that part in this thread)
>
> et voila.
>

I don't understand how to use these macros. Do you have examples I can 
look at?

Mike

Post a reply to this message

On 11/18/2016 8:37 AM, Christian Froeschlin wrote:
> 1. Define three separate float functions yielding R, G, B separately
>
> f_R(x,y,z)
> f_B(x,y,z)
> f_G(x,y,z)
>
> 2. Create red / green / blue pigments from that using function
> pattern and red / green / blue color_maps
>
> 3. Join the 3 pigments into RGB pigment via "average" pattern.

With these three functions, do I fade them from a pure color to black, 
or a pure color to transparent?

Mike

Post a reply to this message

On 11/18/2016 8:37 AM, Christian Froeschlin wrote:
> Still it would probably be useful to implement the coordinate
> transformation (including appropriate scaling of intervals) in
> a separate set of functions f_L, f_u, f_v since you need them
> multiple times in the definition of f_R, f_G, f_B.
>

Are you suggesting I use a parametric instead of an isosurface?

Mike

Post a reply to this message

On 11/23/2016 4:05 AM, Mike Horvath wrote:
> On 11/18/2016 8:37 AM, Christian Froeschlin wrote:
>> Still it would probably be useful to implement the coordinate
>> transformation (including appropriate scaling of intervals) in
>> a separate set of functions f_L, f_u, f_v since you need them
>> multiple times in the definition of f_R, f_G, f_B.
>>
>
> Are you suggesting I use a parametric instead of an isosurface?
>
> Mike

I think I would need a third parameter in addition to u and v to make it 
work.


Mike

Post a reply to this message