Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

mandelbrot colorization problem

53 views
Skip to first unread message

fir

unread,
Jan 5, 2018, 10:54:16 AM1/5/18
to
to relax from coding balls i scratched simple
mandelbrot viewer

http://minddetonator.htw.pl/man5.png

http://minddetonator.htw.pl/man5.zip
(win32, no malware)

the problem is hovever colorization,

mandelbrot algorith produces something like
'pixelheight' field or how to call it and there
is not much to do with it (at least i dont want to go into it) but there stays a problem of well colorisation

the subproblems are maybe even numerous (the more to mention the better as it helps well explore the problem)


note a problem is technically just to fill up a "unsigned palette[50000];"array with a strip of well-fitted to mandelbrot colors .. most mandelbrot images i could see are in scope of less than 50k
iterations, probably most are even less than 10k
(in some deeper zooms precision of double endsand
i dont go after that only taking about this normal double-obtainable part)

what i made is generate sinwaves on r,g,b with different periods and use it

const int palette_max = 50*1000+1;

unsigned palette[palette_max];


inline unsigned rgb(int red, int green, int blue)
{
return red*256*256 + green *256 + blue;
}

void InitPalette( double pal_r_coefficient,
double pal_g_coefficient,
double pal_b_coefficient )
{
double pi = 3.14159;

for(int i=0; i<palette_max; i++)
{
int r = int(0+ 125.*(1.0+ cos(double(i) * 2.*pi / pal_r_coefficient) ));
int g = int(0+ 125.*(1.0+ cos(double(i) * 2.*pi / pal_g_coefficient) ));
int b = int(0+ 125.*(1.0+ cos(double(i) * 2.*pi / pal_b_coefficient) ));

palette[i] = rgb( r,g,b );
}

palette[0] = 0x00000000;
}

the problems :

1. randomness

such palettes sometimes gives somewhat good results,

http://minddetonator.htw.pl/hq.png

http://minddetonator.htw.pl/hq4.png

http://minddetonator.htw.pl/man.png

http://minddetonator.htw.pl/hqqq.png

some problem may be sometimes, what most practical i could obtain was to make some palette generation
with those 3 pallette rgb coefficients being random,
if user presses that key that will generate palettes enough times he will probably obtain something good
looking

but i think the nicer would be to randomise from maybe some more shallow set to have a bigger chance to obtain something looking especially well

how to do that?

2. gradient

there may be a problem (i would need research it more) that when you draw manedlbrot pieces on biggers levels of zoom, the typical 'gradient'/distance betwean near pixels on the
image will be probably bigger then those that is common on more shallow zoom levels - as palette generated in a way above has constant period of changes (say 300 ) the color smoothnes can be lost
with bigger gradients (i could rerandomize it and wait foor bigger periods but im not sure is fuch constant period palette may not fail somewhat)

3. coloristic fullnes

im afraid that a palette generated in a way of above is onlya subset of all palettes and those that are generated are not thiose most fancy fairy -looking ones, but how to generate more elaborated ones?

some ideas?

Malcolm McLean

unread,
Jan 5, 2018, 11:34:16 AM1/5/18
to
On Friday, January 5, 2018 at 3:54:16 PM UTC, fir wrote:
> to relax from coding balls i scratched simple
>
> 3. coloristic fullnes
>
> im afraid that a palette generated in a way of above is onlya subset of all palettes and those that are generated are not thiose most fancy fairy -looking ones, but how to generate more elaborated ones?
>
> some ideas?
>

Take a look at my palettes for colourschemes.

https://github.com/MalcolmMcLean/babyx/blob/master/BabyPrograms/BabyPerlin/colourschemes.c

fir

unread,
Jan 5, 2018, 12:01:57 PM1/5/18
to
not quite see what they do, predefined palettes
'stretched' betwean color points by lerps?

for what you used it for?

i wonder if making some predefined palettes by hend is not to much work, though maybe the idea is ok, like i could put 5-10 predefined points and interpolate

fir

unread,
Jan 5, 2018, 3:15:03 PM1/5/18
to
yet one question

here

https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/Mandelbrot_set/mandelbrot#Bailout_test

there is a piece entitled "interior detection"
and a bit of code thet is not quite explained but seem interesting

esp
if(cabs(D)<eps) break; // interior
this line is not explained, what is eps and
what generally is goin on here

maybe someone could explain that

Malcolm McLean

unread,
Jan 5, 2018, 5:41:33 PM1/5/18
to
I find the colour palettes are useful in a range of applications.
Data visualisation, and procedural texture generation, and graphics
wash effects.

As you say, there are mostly just predefined colour points stretched to
the asked for palette size by lerps, nothing too complex.

fir

unread,
Jan 5, 2018, 5:47:00 PM1/5/18
to
well ok but im not sure if i would have a time to test it..im better serch for some understanding

btw, someone remembered me about HSV model, the idea is good but the functions i once found looks like terribly lame

i got no much belif in something looking like that



// r,g,b values are from 0 to 1
// h = [0,360], s = [0,1], v = [0,1]
// if s == 0, then h = -1 (undefined)
void RGBtoHSV( float r, float g, float b, float *h, float *s, float *v )
{
float min_, max_, delta;

min_ = min( min( r, g), b );
max_ = max( max(r, g), b );

*v = max_; // v
delta = max_ - min_;
if( max_ != 0 )
*s = delta / max_; // s
else {
// r = g = b = 0 // s = 0, v is undefined
*s = 0;
*h = -1;
return;
}
if( r == max_ )
*h = ( g - b ) / delta; // between yellow & magenta
else if( g == max_ )
*h = 2 + ( b - r ) / delta; // between cyan & yellow
else
*h = 4 + ( r - g ) / delta; // between magenta & cyan
*h *= 60; // degrees
if( *h < 0 )
*h += 360;
}
void HSVtoRGB( float *r, float *g, float *b, float h, float s, float v )
{
int i;
float f, p, q, t;
if( s == 0 ) {
// achromatic (grey)
*r = *g = *b = v;
return;
}
h /= 60; // sector 0 to 5
i = floor( h );
f = h - i; // factorial part of h
p = v * ( 1 - s );
q = v * ( 1 - s * f );
t = v * ( 1 - s * ( 1 - f ) );
switch( i ) {
case 0:
*r = v;
*g = t;
*b = p;
break;
case 1:
*r = q;
*g = v;
*b = p;
break;
case 2:
*r = p;
*g = v;
*b = t;
break;
case 3:
*r = p;
*g = q;
*b = v;
break;
case 4:
*r = t;
*g = p;
*b = v;
break;
default: // case 5:
*r = v;
*g = p;
*b = q;
break;
}
}



has maybe someone a bit better knowledge about HSV colors and can provide somethink better
or maybe some usable notes etc?

(better understanding would need maybe some studying a color theory and it seems a piece of
work and im not sure if i got time on that)


fir

unread,
Jan 5, 2018, 6:00:31 PM1/5/18
to
note besides
holding and pasing colors as unsigned char* confuses me, i always use unsigned (or int as i dont use alpha to often, 0x00ff0000 is red) and i always forget that this is so bad becouse this packing and unpacking rgb when needed

is someone able to answer hovever if treating color as char[] may be more efficien than

union Color
{
unsigned value;
struct { unsigned char b, g, r, a;};
};

?

efficiency is real important here, i cannot
decide if char bgra[4] has a chance to be faster

Malcolm McLean

unread,
Jan 5, 2018, 6:02:23 PM1/5/18
to
On Friday, January 5, 2018 at 10:47:00 PM UTC, fir wrote:
>
> btw, someone remembered me about HSV model, the idea is good but
> the functions i once found looks like terribly lame
>
You can make colour theory terribly complex, with all sorts of spaces.
HSV is useful because "hue" is something we intuitively understand.
There's also HSL, which is subtly different.

You've got two systems to consider; your display system, which usually
can display a limited range of RGB colours or inks, and the human eye,
which has black and white as well as colour cones, and has a "shark's
fin" range of sensitivity in RGB space.

However there's only a point in being rigorous if you understand
the device on which the colours will finally be displayed. If it's
just "a computer monitor" used by a non-expert user, then there's
little point in trying to make all the corrections.

fir

unread,
Jan 8, 2018, 1:34:18 PM1/8/18
to
i could say i checked some simple program made by some others (fractalxtreme) and they just seem did just what i also did, for this palette they made it on predefined points though they also made some 'widget' or how to call it allowing those points to be just dragged and moved by mouse)

this borders by the way with some topic i already heard that if some different people code
programs on something they will end in doing the same things - there is also some correlated efect imo, for example some problems to code enforce some tehnologies (on its writers) and those enforced tehnologies are also usually well done,(at least to me it seems that thise enforced are usually more better than thse not enforced ;c)
0 new messages