"yesbird" <nomail@nomail> wrote:
> > Apparently it was a lot easier than I thought.
> > Here's a plot of the color map as it gets interpolated through HSV space.
> > The graph is one of the more successful (and simplest) of several functions I've
> > been inventing to look for "nodes" in the color_map definition.
>
> Colormap reverse engineering... Really non-standard question, interesting, what
> practical aspect can be here ?
> Could you please provide little more details about this graph and idea behind
> this method ? Is it works already ?
> --
> YB

Sure Sergey,

The out-of-range color_map that you started with led me experiment some more
with a color-pigment-texture map idea that I have had for a long time, and
explored further when working with Thomas deGroot on the Granite21 macro project
- something to guide the user seeing how the individual components of any map
contribute to the whole, and helping to fine-tune the finished texture.

Now, POV-Ray doesn't have very good read/write capability, and can only work
with comma separated value files (CSV), and we don't have a way to determine
what sort of data type is being read from a file.

So I had the idea of looking at an existing color map that could be incorporated
in the usual way "#include MyColorMap.inc" and then using some sort of algorithm
to extract the color_map entries.  Then I could create an array, sort it, and do
any further processing that might be needed.

And yes, the analysis part is working - it just needs to be completely
automated, and then I can get on with the processing/editing/exporting parts.

I'm currently trying to write an algorithm to count the changes in slope on my
interpolation graph, and I really wish there was a way to either access
out-of-range color_map values, or to easily process an include file to scale the
index values to between 0 and 1.


Here's a preview of the current state of the project:

Post a reply to this message

Attachments:
Download 'colormapeditor.png' (538 KB)

Preview of image 'colormapeditor.png'