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

Groups > comp.graphics.algorithms > #902 > unrolled thread

decorative random colors algorithm

Back to article view | Back to comp.graphics.algorithms

Contents

  decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-01 12:15 +0000
    Re: decorative random colors algorithm gernot.hoffmann@hs-emden-leer.de - 2012-07-01 07:59 -0700
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-02 07:58 +0000
        Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-02 12:29 +0000
    Re: decorative random colors algorithm Nobody <nobody@nowhere.com> - 2012-07-01 16:25 +0100
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-02 08:28 +0000
    Re: decorative random colors algorithm gernot.hoffmann@hs-emden-leer.de - 2012-07-03 01:17 -0700
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-03 10:27 +0000
    Re: decorative random colors algorithm gernot.hoffmann@hs-emden-leer.de - 2012-07-03 21:50 -0700
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-04 05:15 +0000
        Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-04 08:01 +0000
    Re: decorative random colors algorithm gernot.hoffmann@hs-emden-leer.de - 2012-07-04 02:20 -0700
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-04 09:51 +0000
        Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-04 10:59 +0000
          Re: decorative random colors algorithm Wally W. <ww84wa@aim.com> - 2012-07-04 09:03 -0400
            Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-04 13:46 +0000
              Re: decorative random colors algorithm Wally W. <ww84wa@aim.com> - 2012-07-04 12:39 -0400
    Re: decorative random colors algorithm gernot.hoffmann@hs-emden-leer.de - 2012-07-04 07:10 -0700
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-04 15:05 +0000
    Re: decorative random colors algorithm gernot.hoffmann@hs-emden-leer.de - 2012-07-04 09:12 -0700
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-05 03:18 +0000
        Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-05 05:54 +0000
          Re: decorative random colors algorithm John Forkosh <forkosh@panix.com> - 2012-07-05 12:23 +0000
    Re: decorative random colors algorithm "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2012-07-05 07:48 +0200
      Re: decorative random colors algorithm JohnF <john@please.see.sig.for.email.com> - 2012-07-05 06:14 +0000
      Re: decorative random colors algorithm Wally W. <ww84wa@aim.com> - 2012-07-05 07:30 -0400

Page 1 of 2  [1] 2  Next page →

#902 — decorative random colors algorithm

I'm writing a toy program to generate some decorative string art
(a better waste of time than playing computer games, anyway:).
Sample output is at http://www.forkosh.com/decorative.ps

Every line (in that sample) starts with constant r,g,b=95,0,95
out of 255 (or .37 0 .37 if you view that ps file) at one end point,
and varies linearly to randomly selected r,g,b values at the other end.
(There's a thread in comp.programming.postscript about this,
where Gernot Hoffmann provided the ps code that does this.)

Originally, I just used the C function drand48() to select three
random numbers for r,g,b values. But that looked pretty "washed out",
probably because the uniform distribution is likely to give similar
enough values so the composite color is pretty often grayish.
(I didn't "do the math" to figure that out; I just looked at it.)

After failing to google much of anything about this kind of topic,
or even figuring out what search terms might be relevant, I played
around a bit, and settled on the following C code snippet...

   /* --- constant rgb0 initial color supplied by user --- */
   red0   = ((double)fgred0)/255.;    /* in the example case */
   green0 = ((double)fggreen0)/255.;  /* fgr,g,b0 are 95,0,95 */
   blue0  = ((double)fgblue0)/255.;   /* as stated above */
   /* --- randomize rgb1 end color --- */
   red1   = pow(drand48(),1.0);       /* exponent 1.0 does nothing */
   green1 = pow(drand48(),1.0);       /* now, may be changed later */
   blue1  = pow(drand48(),1.0);
   /* --- enhance largest, diminish other two --- */
   if ( red1 >= green1 && red1 >= blue1 ) { /* red is largest */
     red1 = pow(red1,0.333);
     green1 = pow(green1,2.0); blue1 = pow(blue1,2.0); }
   else if ( green1 >= blue1 ) {            /* green is largest */
     green1 = pow(green1,0.333);
     red1 = pow(red1,2.0); blue1 = pow(blue1,2.0); }
   else {                                   /* blue is largest */
     blue1 = pow(blue1,0.333);
     red1 = pow(red1,2.0); green1 = pow(green1,2.0); }
   /* --- emit postscript instruction --- */
   fprintf(fp,"%.2f %.2f %.2f %.2f %.2f %.2f setrgb01\n",
   red0,green0,blue0,red1,green1,blue1);

...which sets the initial constant color, chooses final random
colors with drand48(), and then:
  (a) replaces the largest of the three random r,g,b numbers
      with its cube root (makes it even larger, closer to 1),
  (b) and squares the other two (makes them smaller, closer to 0).
However, it still looks a bit "washed out" to my eye. But pushing the
exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
So maybe my whole idea is just no good. Is there some standard,
or not-so-standard, way to choose random rgb numbers that both
(a) remain pretty much random, and that also (b) make the resulting
image more "vibrant" to the eye (whatever that quantitatively means;
I can tell what it subjectively means just by looking)?
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [next] | [standalone]

#904

Am Sonntag, 1. Juli 2012 14:15:11 UTC+2 schrieb JohnF:
> I'm writing a toy program to generate some decorative string art
> (a better waste of time than playing computer games, anyway:).
> Sample output is at http://www.forkosh.com/decorative.ps
> 
> Every line (in that sample) starts with constant r,g,b=95,0,95
> out of 255 (or .37 0 .37 if you view that ps file) at one end point,
> and varies linearly to randomly selected r,g,b values at the other end.
> (There's a thread in comp.programming.postscript about this,
> where Gernot Hoffmann provided the ps code that does this.)
> 
> Originally, I just used the C function drand48() to select three
> random numbers for r,g,b values. But that looked pretty "washed out",
> probably because the uniform distribution is likely to give similar
> enough values so the composite color is pretty often grayish.
> (I didn't "do the math" to figure that out; I just looked at it.)
> 
> After failing to google much of anything about this kind of topic,
> or even figuring out what search terms might be relevant, I played
> around a bit, and settled on the following C code snippet...
> 
>    /* --- constant rgb0 initial color supplied by user --- */
>    red0   = ((double)fgred0)/255.;    /* in the example case */
>    green0 = ((double)fggreen0)/255.;  /* fgr,g,b0 are 95,0,95 */
>    blue0  = ((double)fgblue0)/255.;   /* as stated above */
>    /* --- randomize rgb1 end color --- */
>    red1   = pow(drand48(),1.0);       /* exponent 1.0 does nothing */
>    green1 = pow(drand48(),1.0);       /* now, may be changed later */
>    blue1  = pow(drand48(),1.0);
>    /* --- enhance largest, diminish other two --- */
>    if ( red1 >= green1 && red1 >= blue1 ) { /* red is largest */
>      red1 = pow(red1,0.333);
>      green1 = pow(green1,2.0); blue1 = pow(blue1,2.0); }
>    else if ( green1 >= blue1 ) {            /* green is largest */
>      green1 = pow(green1,0.333);
>      red1 = pow(red1,2.0); blue1 = pow(blue1,2.0); }
>    else {                                   /* blue is largest */
>      blue1 = pow(blue1,0.333);
>      red1 = pow(red1,2.0); green1 = pow(green1,2.0); }
>    /* --- emit postscript instruction --- */
>    fprintf(fp,"%.2f %.2f %.2f %.2f %.2f %.2f setrgb01\n",
>    red0,green0,blue0,red1,green1,blue1);
> 
> ...which sets the initial constant color, chooses final random
> colors with drand48(), and then:
>   (a) replaces the largest of the three random r,g,b numbers
>       with its cube root (makes it even larger, closer to 1),
>   (b) and squares the other two (makes them smaller, closer to 0).
> However, it still looks a bit "washed out" to my eye. But pushing the
> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
> So maybe my whole idea is just no good. Is there some standard,
> or not-so-standard, way to choose random rgb numbers that both
> (a) remain pretty much random, and that also (b) make the resulting
> image more "vibrant" to the eye (whatever that quantitatively means;
> I can tell what it subjectively means just by looking)?
> -- 
> John Forkosh

Hello John, 

you'll get better control over your colors if you use 
basically the HLS-model (and convert to RGB). 
For instance, you may map your pseudo-random-numbers to 
a limited Hue-range, Lightness-range and Saturation-range,
for instance S=0.5...1.0 in order to avoid littele satu-
rated or washed-out colors.
(1)
http://www.fho-emden.de/~hoffmann/hlscone03052001.pdf
The doc contains procedures for the conversions HLS<-->RGB
in Pascal and PostScript.

Pseudo-Random-Number-Generators in PostScript can deliver 
different number sequences, depending on the implementation. 
(2)
http://www.fho-emden.de/~hoffmann/ranpoint14032004.pdf
This doc contains a directly programmed PostScript generator
including spectra y distributions. There is as well some 
advice, how to convert an Equal distribution into a Gaussian.
[Dealing with real number sequences, the distributions are 
never truly Equal or Gaussian.]    

Hope this helps, especially (1). 

Best regards --Gernot Hoffmann

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

#906

gernot.hoffmann@hs-emden-leer.de wrote:
> Am Sonntag, 1. Juli 2012 14:15:11 UTC+2 schrieb JohnF:
>> I'm writing a toy program to generate some decorative string art
>> (a better waste of time than playing computer games, anyway:).
>> Sample output is at http://www.forkosh.com/decorative.ps
>> 
>> Every line (in that sample) starts with constant r,g,b=95,0,95
>> out of 255 (or .37 0 .37 if you view that ps file) at one end point,
>> and varies linearly to randomly selected r,g,b values at the other end.
>> (There's a thread in comp.programming.postscript about this,
>> where Gernot Hoffmann provided the ps code that does this.)
>> 
>> Originally, I just used the C function drand48() to select three
>> random numbers for r,g,b values. But that looked pretty "washed out",
>> probably because the uniform distribution is likely to give similar
>> enough values so the composite color is pretty often grayish.
>> (I didn't "do the math" to figure that out; I just looked at it.)
>> 
>> After failing to google much of anything about this kind of topic,
>> or even figuring out what search terms might be relevant, I played
>> around a bit, and settled on the following C code snippet...
>> 
>>    /* --- constant rgb0 initial color supplied by user --- */
>>    red0   = ((double)fgred0)/255.;    /* in the example case */
>>    green0 = ((double)fggreen0)/255.;  /* fgr,g,b0 are 95,0,95 */
>>    blue0  = ((double)fgblue0)/255.;   /* as stated above */
>>    /* --- randomize rgb1 end color --- */
>>    red1   = pow(drand48(),1.0);       /* exponent 1.0 does nothing */
>>    green1 = pow(drand48(),1.0);       /* now, may be changed later */
>>    blue1  = pow(drand48(),1.0);
>>    /* --- enhance largest, diminish other two --- */
>>    if ( red1 >= green1 && red1 >= blue1 ) { /* red is largest */
>>      red1 = pow(red1,0.333);
>>      green1 = pow(green1,2.0); blue1 = pow(blue1,2.0); }
>>    else if ( green1 >= blue1 ) {            /* green is largest */
>>      green1 = pow(green1,0.333);
>>      red1 = pow(red1,2.0); blue1 = pow(blue1,2.0); }
>>    else {                                   /* blue is largest */
>>      blue1 = pow(blue1,0.333);
>>      red1 = pow(red1,2.0); green1 = pow(green1,2.0); }
>>    /* --- emit postscript instruction --- */
>>    fprintf(fp,"%.2f %.2f %.2f %.2f %.2f %.2f setrgb01\n",
>>    red0,green0,blue0,red1,green1,blue1);
>> 
>> ...which sets the initial constant color, chooses final random
>> colors with drand48(), and then:
>>   (a) replaces the largest of the three random r,g,b numbers
>>       with its cube root (makes it even larger, closer to 1),
>>   (b) and squares the other two (makes them smaller, closer to 0).
>> However, it still looks a bit "washed out" to my eye. But pushing the
>> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
>> So maybe my whole idea is just no good. Is there some standard,
>> or not-so-standard, way to choose random rgb numbers that both
>> (a) remain pretty much random, and that also (b) make the resulting
>> image more "vibrant" to the eye (whatever that quantitatively means;
>> I can tell what it subjectively means just by looking)?
>> -- 
>> John Forkosh
> 
> Hello John, 
> 
> you'll get better control over your colors if you use 
> basically the HLS-model (and convert to RGB). 
> For instance, you may map your pseudo-random-numbers to 
> a limited Hue-range, Lightness-range and Saturation-range,
> for instance S=0.5...1.0 in order to avoid little satu-
> rated or washed-out colors.
> (1)
> http://www.fho-emden.de/~hoffmann/hlscone03052001.pdf
> The doc contains procedures for the conversions HLS<-->RGB
> in Pascal and PostScript.

Thanks so much, yet again, Prof. Hoffmann, for the detailed
explanation. I'd browsed through pretty much every one of
your documents at http://www.fho-emden.de/~hoffmann/howww41a.html
previously, but apparently too casually. Minimally, I usually
try to at least remember what documents are about, so if the
subject ever comes up I can go back and actually learn something
about it. But I failed to remember your hlscone.
   You're clearly right that the hls paramterization is the correct
way to address and solve my problem (whereas rgb doesn't really
address it and therefore can't possibly solve it). I'll rewrite
your Section 7 and 8 Pascal HLS<-->RGB algorithms in C
(when first seeing your Section 1 illustration, I immediately
wondered how to easily constrain hls values within the rgb cube
subspace).
   I already tried "nobody"'s suggestion, since it only took
about five minutes. The followup to him discusses that, and
how to download both examples (original and same design using
"nobody"'s suggestion). Not much eyeball difference.

> Pseudo-Random-Number-Generators in PostScript can deliver 
> different number sequences, depending on the implementation. 
> (2)
> http://www.fho-emden.de/~hoffmann/ranpoint14032004.pdf
> This doc contains a directly programmed PostScript generator
> including spectra y distributions. There is as well some 
> advice, how to convert an Equal distribution into a Gaussian.
> [Dealing with real number sequences, the distributions are 
> never truly Equal or Gaussian.]    

I'll probably write that in C, too, replacing drand48(),
based on your Section 2 discussion (as you say, the short
8192 period is okay "for the intended applications").
The C program independently generates both gif and ps
renderings of the decorative designs, so I'm trying to keep
all algorithms implemented at that level, rather than writing
them out twice.

> Hope this helps, especially (1). 
Absolutely (1), and also (2). And, of course, your
earlier comp.programming.postscript code.
   I'll eventually write your ps Bezier code in C, too,
replacing my current three-control-point version, which
doesn't exactly reproduce ps's curveto. I removed, but
appreciatively noticed, your original black outline curveto,
to validate that your Bezier exactly reoproduces ps's.

> Best regards --Gernot Hoffmann
Ditto, and thanks again.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#909

JohnF <john@please.see.sig.for.email.com> wrote:
> gernot.hoffmann@hs-emden-leer.de wrote:
>> 
>> you'll get better control over your colors if you use 
>> basically the HLS-model (and convert to RGB). 
>> For instance, you may map your pseudo-random-numbers to 
>> a limited Hue-range, Lightness-range and Saturation-range,
>> for instance S=0.5...1.0 in order to avoid little satu-
>> rated or washed-out colors.
>> (1)
>> http://www.fho-emden.de/~hoffmann/hlscone03052001.pdf
>> The doc contains procedures for the conversions HLS<-->RGB
>> in Pascal and PostScript.
>
> I already tried "nobody"'s suggestion, since it only took
> about five minutes.

And a first cut of yours is at forkosh.com/decorative3.ps
That uses random h,l (still using drand48()) and s=1.0 fixed.
But the C code below, mechanically taken (without a whole
lot of understanding beforehand -- I need to add some meaningful
comments) from your Section 7, accepts any args. I'll have
to try more intelligently restricting the h,l,s ranges as
you suggested above. Thanks again,

/* ==========================================================================
 * Function:    hlstorgb ( h,l,s, rgbswitch )
 * Purpose:     convert h,l,s color model cylindrical coordinates
 *              to equivalent cartesian r,g,b coordinates
 * --------------------------------------------------------------------------
 * Arguments:   h (I)           double containing hue "angle" in degrees,
 *                              0.0<=h<360.0
 *              l (I)           double containing lightness "vertical axis",
 *                              0.0<=l<=1.0
 *              s (I)           double containing saturation "radius",
 *                              0.0<=s<=1.0
 *              rgbswitch (I)   int containing 1 to return r(ed) coord,
 *                              2 for g(reen) coord, or 3 for b(lue) coord.
 *                              Alternatively, 0 returns ((256*r+g)*256)+b,
 *                              i.e., 24-bit composite with b in the low-order
 *                              eight bits, g in the next eight bits,
 *                              and r in the high-order (of 24) eight bits.
 * --------------------------------------------------------------------------
 * Returns:     ( int )         r or g or b, if rgb=1 or 2 or 3, respectively,
 *                              or ((256*r+g)*256)+b composite if rgb=0,
 *                              or 0 for any error.
 * --------------------------------------------------------------------------
 * Notes:     o
 * ======================================================================= */
/* --- entry point --- */
int     hlstorgb ( double h, double l, double s, int rgbswitch )
{
/* -------------------------------------------------------------------------
allocations and declarations
-------------------------------------------------------------------------- */
int     rgbcolor = 0,                   /* color returned to caller */
        rgb[3]={0,0,0}, irgb=0;         /* r=rgb[0], g=rgb[1], b=rgb[2] */
double  hlsmax=0.0, hlsmin=0.0, hlsmmm=0.0; /* hls param max,min,max-min */
double  hlshue=0.0, hlscolor=0.0;       /* hls hue and color */
/* -------------------------------------------------------------------------
check input arguments
-------------------------------------------------------------------------- */
if ( h<0.0 || h>=360.0 ) {              /* restrict 0<=h<360 */
  h = fmod(h,360.0);                    /* now -360<h<+360 */
  if ( h < 0.0 ) h += 360.0; }          /* now 0<=360<h, as needed below */
if (l<0.0) l=0.0;  if (l>1.0) l=1.0;    /* restrict 0<=l<=1 */
if (s<0.0) s=0.0;  if (s>1.0) s=1.0;    /* restrict 0<=s<=1 */
if ( rgbswitch < 0 ) rgbswitch = 0;     /* interpret as 0 */
if ( rgbswitch > 3 ) rgbswitch = (rgbswitch%4); /* interpret mod 4 */
/* -------------------------------------------------------------------------
hls parameterization
-------------------------------------------------------------------------- */
hlsmax = ((l<=0.5)? l*(1.0+s) : (l+s)-(l*s));
hlsmin = 2.0*l - hlsmax;
hlsmmm = (hlsmax - hlsmin)/60.0;
/* -------------------------------------------------------------------------
loop over red, green, blue
-------------------------------------------------------------------------- */
for ( irgb=0; irgb<=2; irgb++ ) {       /* for each rgb component */
  if ( rgbswitch!=0 && rgbswitch!=irgb+1 ) continue; /*don't need this one*/
  hlshue = h + 120.0*((double)(1-irgb)); /* h+120, h, h-120 */
  if ( irgb==0 ) { if ( hlshue > 360.0 ) hlshue -= 360.0; }
  if ( irgb==2 ) { if ( hlshue < 0.0 )   hlshue += 360.0; }
  if ( hlshue < 60.0 )
    hlscolor = hlsmin + hlsmmm*hlshue;
  else if ( hlshue < 180.0 )
    hlscolor = hlsmax;
  else if ( hlshue < 240.0 )
    hlscolor = hlsmin + hlsmmm*(240.0-hlshue);
  else
    hlscolor = hlsmin;
  rgb[irgb] = (int)(0.5+(hlscolor*255.0));
  } /* --- end-of-for(irgb) --- */
/* -------------------------------------------------------------------------
end-of-job
-------------------------------------------------------------------------- */
/*end_of_job:*/
switch ( rgbswitch ) {
  default: rgbcolor = 0;  break;        /* error */
  case 0: rgbcolor  = rgb[2] + 256*(rgb[1] + 256*rgb[0]); break; /*composite*/
  case 1: rgbcolor  = rgb[0];  break;   /* red   requested */
  case 2: rgbcolor  = rgb[1];  break;   /* green requested */
  case 3: rgbcolor  = rgb[2];  break; } /* blue  requested */
return ( rgbcolor );                    /* back to caller with r,g,b or rgb */
} /* --- end-of-function hlstorgb() --- */

-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#905

On Sun, 01 Jul 2012 12:15:11 +0000, JohnF wrote:

> However, it still looks a bit "washed out" to my eye. But pushing the
> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
> So maybe my whole idea is just no good. Is there some standard,
> or not-so-standard, way to choose random rgb numbers that both
> (a) remain pretty much random, and that also (b) make the resulting
> image more "vibrant" to the eye (whatever that quantitatively means;
> I can tell what it subjectively means just by looking)?

IOW, you want more saturation. Using an HSL or HSV colour space is one
solution.

	http://en.wikipedia.org/wiki/HSL_and_HSV

If you just want maximum saturation, an alternative is to modify your
original approach. Set the largest to 1, the smallest to 0, and leave the
middle one alone. That will give you a uniformly-distributed point on the
path:

	Red - Yellow - Green - Cyan - Blue - Magenta - Red

i.e. all of the edges of the RGB colour cube which don't have black or
white as an endpoint.

The original approach doesn't have quite as much saturation (the highest
and lowest are moved closer to 1.0 and 0.0 rather than all the way),
while moving the middle one closer to zero results in a bias toward
red, green and blue.

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

#907

Nobody <nobody@nowhere.com> wrote:
> On Sun, 01 Jul 2012 12:15:11 +0000, JohnF wrote:
> 
>> However, it still looks a bit "washed out" to my eye. But pushing the
>> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
>> So maybe my whole idea is just no good. Is there some standard,
>> or not-so-standard, way to choose random rgb numbers that both
>> (a) remain pretty much random, and that also (b) make the resulting
>> image more "vibrant" to the eye (whatever that quantitatively means;
>> I can tell what it subjectively means just by looking)?
> 
> IOW, you want more saturation. Using an HSL or HSV colour space is one
> solution.
> 
>        http://en.wikipedia.org/wiki/HSL_and_HSV

Thanks so much for the useful reference (and the keywords,
which probably would have induced google to cough up more useful
info than I was able to wring out of it myself). Along with
Prof. Hoffmann's http://www.fho-emden.de/~hoffmann/hlscone03052001.pdf
from the preceding followup, that pretty much explains the situation
in terms I can understand.

> If you just want maximum saturation, an alternative is to modify your
> original approach. Set the largest to 1, the smallest to 0, and leave the
> middle one alone. That will give you a uniformly-distributed point on the
> path:
> 
>        Red - Yellow - Green - Cyan - Blue - Magenta - Red
> 
> i.e. all of the edges of the RGB colour cube which don't have black or
> white as an endpoint.
> 
> The original approach doesn't have quite as much saturation (the highest
> and lowest are moved closer to 1.0 and 0.0 rather than all the way),
> while moving the middle one closer to zero results in a bias toward
> red, green and blue.

That sounds perfect and easy, so I tried it out (but it was hard
to write a comment crediting you for the suggestion -- I was tempted
to thank Emily Dickinson:). You can see the results at
  http://www.forkosh.com/decorative.ps   [original]
  http://www.forkosh.com/decorative2.ps  [your suggestion]
(Note: if you already downloaded the original, re-download it,
as one line is now placed slightly differently -- the %%title
is supposed to contain all parameters to reproduce exactly
the same design, but I slightly goofed.)
   Doesn't seem to have much effect on the visual outcome
(though you can diff the two files and easily validate
everything's working as advertised). On the other hand, the
illustrations in Prof. Hoffmann's hlscone section 5 don't show
much visual difference either, so perhaps I'm just expecting
too much improvement. Thanks so much for your help,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#910

Am Sonntag, 1. Juli 2012 14:15:11 UTC+2 schrieb JohnF:
> I'm writing a toy program to generate some decorative string art
> (a better waste of time than playing computer games, anyway:).
> Sample output is at http://www.forkosh.com/decorative.ps
> 
> Every line (in that sample) starts with constant r,g,b=95,0,95
> out of 255 (or .37 0 .37 if you view that ps file) at one end point,
> and varies linearly to randomly selected r,g,b values at the other end.
> (There's a thread in comp.programming.postscript about this,
> where Gernot Hoffmann provided the ps code that does this.)
> 
> Originally, I just used the C function drand48() to select three
> random numbers for r,g,b values. But that looked pretty "washed out",
> probably because the uniform distribution is likely to give similar
> enough values so the composite color is pretty often grayish.
> (I didn't "do the math" to figure that out; I just looked at it.)
> 
> After failing to google much of anything about this kind of topic,
> or even figuring out what search terms might be relevant, I played
> around a bit, and settled on the following C code snippet...
> 
>    /* --- constant rgb0 initial color supplied by user --- */
>    red0   = ((double)fgred0)/255.;    /* in the example case */
>    green0 = ((double)fggreen0)/255.;  /* fgr,g,b0 are 95,0,95 */
>    blue0  = ((double)fgblue0)/255.;   /* as stated above */
>    /* --- randomize rgb1 end color --- */
>    red1   = pow(drand48(),1.0);       /* exponent 1.0 does nothing */
>    green1 = pow(drand48(),1.0);       /* now, may be changed later */
>    blue1  = pow(drand48(),1.0);
>    /* --- enhance largest, diminish other two --- */
>    if ( red1 >= green1 && red1 >= blue1 ) { /* red is largest */
>      red1 = pow(red1,0.333);
>      green1 = pow(green1,2.0); blue1 = pow(blue1,2.0); }
>    else if ( green1 >= blue1 ) {            /* green is largest */
>      green1 = pow(green1,0.333);
>      red1 = pow(red1,2.0); blue1 = pow(blue1,2.0); }
>    else {                                   /* blue is largest */
>      blue1 = pow(blue1,0.333);
>      red1 = pow(red1,2.0); green1 = pow(green1,2.0); }
>    /* --- emit postscript instruction --- */
>    fprintf(fp,"%.2f %.2f %.2f %.2f %.2f %.2f setrgb01\n",
>    red0,green0,blue0,red1,green1,blue1);
> 
> ...which sets the initial constant color, chooses final random
> colors with drand48(), and then:
>   (a) replaces the largest of the three random r,g,b numbers
>       with its cube root (makes it even larger, closer to 1),
>   (b) and squares the other two (makes them smaller, closer to 0).
> However, it still looks a bit "washed out" to my eye. But pushing the
> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
> So maybe my whole idea is just no good. Is there some standard,
> or not-so-standard, way to choose random rgb numbers that both
> (a) remain pretty much random, and that also (b) make the resulting
> image more "vibrant" to the eye (whatever that quantitatively means;
> I can tell what it subjectively means just by looking)?
> -- 
> John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

John, 

thanks for the feedback. Sorry I've lost the overview.
Also, too many questions!

Perhaps this Swatch Book can give you an impression about
the relation between numbers and appearance, here - for RGB -
only the last(!) page:
http://www.fho-emden.de/~hoffmann/swatch22112002.pdf

Best regards --Gernot Hoffmann

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

#912

gernot.hoffmann@hs-emden-leer.de wrote:
> John, thanks for the feedback.
No problem at all. Thanks so very much for
the information and advice to feedback on.

> Sorry I've lost the overview.
Also no problem.
The internet will keep it forever,
whether it's worth keeping or not.

> Also, too many questions!

Sorry about that. Since the last post,
I've settled by trial-and-error on what
seems to my eye like the best-looking ranges,
  0<=h<360,  0.1<=l<=0.5,  0.6<=s<=1.0
with values selected randomly by drand48()
within those ranges (I haven't tried your
prng algorithm yet).
Anyway, that's what looks best to me so far
(your kiolmeterage may vary).

You (and similarly "nobody@nowhere") were
right that the hls color model (about which
I knew nothing when first posting) is what's
needed to do this properly. And your hlstorgb
code in hlscone...pdf was by far the simplest
implementation of any I subsequently googled.
I'm surprised your algorithm doesn't seem to
have become the standard way to do it.

> Perhaps this Swatch Book can give you an impression about
> the relation between numbers and appearance, here - for RGB -
> only the last(!) page:
> http://www.fho-emden.de/~hoffmann/swatch22112002.pdf

Thanks, that looks great! And rather than the original
decorative.ps design I was looking at, I ran hls-parameter-range
tests against the design at http://www.forkosh.com/decorative0.ps
which displays the individual color lines better.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#914

Am Sonntag, 1. Juli 2012 14:15:11 UTC+2 schrieb JohnF:
> I'm writing a toy program to generate some decorative string art
> (a better waste of time than playing computer games, anyway:).
> Sample output is at http://www.forkosh.com/decorative.ps
> 
> Every line (in that sample) starts with constant r,g,b=95,0,95
> out of 255 (or .37 0 .37 if you view that ps file) at one end point,
> and varies linearly to randomly selected r,g,b values at the other end.
> (There's a thread in comp.programming.postscript about this,
> where Gernot Hoffmann provided the ps code that does this.)
> 
> Originally, I just used the C function drand48() to select three
> random numbers for r,g,b values. But that looked pretty "washed out",
> probably because the uniform distribution is likely to give similar
> enough values so the composite color is pretty often grayish.
> (I didn't "do the math" to figure that out; I just looked at it.)
> 
> After failing to google much of anything about this kind of topic,
> or even figuring out what search terms might be relevant, I played
> around a bit, and settled on the following C code snippet...
> 
>    /* --- constant rgb0 initial color supplied by user --- */
>    red0   = ((double)fgred0)/255.;    /* in the example case */
>    green0 = ((double)fggreen0)/255.;  /* fgr,g,b0 are 95,0,95 */
>    blue0  = ((double)fgblue0)/255.;   /* as stated above */
>    /* --- randomize rgb1 end color --- */
>    red1   = pow(drand48(),1.0);       /* exponent 1.0 does nothing */
>    green1 = pow(drand48(),1.0);       /* now, may be changed later */
>    blue1  = pow(drand48(),1.0);
>    /* --- enhance largest, diminish other two --- */
>    if ( red1 >= green1 && red1 >= blue1 ) { /* red is largest */
>      red1 = pow(red1,0.333);
>      green1 = pow(green1,2.0); blue1 = pow(blue1,2.0); }
>    else if ( green1 >= blue1 ) {            /* green is largest */
>      green1 = pow(green1,0.333);
>      red1 = pow(red1,2.0); blue1 = pow(blue1,2.0); }
>    else {                                   /* blue is largest */
>      blue1 = pow(blue1,0.333);
>      red1 = pow(red1,2.0); green1 = pow(green1,2.0); }
>    /* --- emit postscript instruction --- */
>    fprintf(fp,"%.2f %.2f %.2f %.2f %.2f %.2f setrgb01\n",
>    red0,green0,blue0,red1,green1,blue1);
> 
> ...which sets the initial constant color, chooses final random
> colors with drand48(), and then:
>   (a) replaces the largest of the three random r,g,b numbers
>       with its cube root (makes it even larger, closer to 1),
>   (b) and squares the other two (makes them smaller, closer to 0).
> However, it still looks a bit "washed out" to my eye. But pushing the
> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
> So maybe my whole idea is just no good. Is there some standard,
> or not-so-standard, way to choose random rgb numbers that both
> (a) remain pretty much random, and that also (b) make the resulting
> image more "vibrant" to the eye (whatever that quantitatively means;
> I can tell what it subjectively means just by looking)?
> -- 
> John Forkosh 

John,

I've added a HLS-page to the doc:
http://www.fho-emden.de/~hoffmann/swatch22112002.pdf

It shows RGB-color in HLS coordinates. One graphic per Hue
0° to 330° step 30°. Horizontally the Saturation and vertically
the Lightness. These are cylinder coordinates.
In order to get the double cone appearance, it would be necessary
to distort the lower half and the upper half linearly so that
the lines L=0 and L=1 shrink to points.
The purpose is not to show the double cone, but simply the colors
which belong to each parameter set H,L,S.

Best regards --Gernot Hoffmann

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

#915

gernot.hoffmann@hs-emden-leer.de wrote:
> John,
> 
> I've added a HLS-page to the doc:
> http://www.fho-emden.de/~hoffmann/swatch22112002.pdf
> 
> It shows RGB-color in HLS coordinates. One graphic per Hue
> 0 to 330 step 30. Horizontally the Saturation and vertically
> the Lightness. These are cylinder coordinates.
> In order to get the double cone appearance, it would be necessary
> to distort the lower half and the upper half linearly so that
> the lines L=0 and L=1 shrink to points.
> The purpose is not to show the double cone, but simply the colors
> which belong to each parameter set H,L,S.
> 
> Best regards --Gernot Hoffmann

Thanks, that's nice. After seeing some of those pages, I'm going
to add a "rainbow" ("random" with an "i", and with the d<-->b
reflected about a vertical axis, and the m<-->w about a horizontal
one:) option, so that a sequence of lines will each start with a
fixed h,l,s at one endpoint, and then vary 0<h<360 at the other
endpoint. So each design will consist of several (the number of its
polygon sides) such rainbow fans. That'll take a while to get to.
   Meanwhile, since you mention cylindrical coords, I still have
to get around to taking a closer look at your hlstorgb algorithm,
and figuring out exactly how that trivial-looking arithmetic
projects h,l,s values onto the rotated r,g,b cube axes. Cute.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#916

JohnF <john@please.see.sig.for.email.com> wrote:
> gernot.hoffmann@hs-emden-leer.de wrote:
>> I've added a HLS-page to the doc:
>>   http://www.fho-emden.de/~hoffmann/swatch22112002.pdf
>> It shows RGB-color in HLS coordinates. One graphic per Hue
>> 0 to 330 step 30. Horizontally the Saturation and vertically
>> the Lightness. These are cylinder coordinates.
>> In order to get the double cone appearance, it would be necessary
>> to distort the lower half and the upper half linearly so that
>> the lines L=0 and L=1 shrink to points.
>> The purpose is not to show the double cone, but simply the colors
>> which belong to each parameter set H,L,S.
> 
> Thanks, that's nice. After seeing some of those pages, I'm going
> to add a "rainbow" ("random" with an "i", and with the d<-->b
> reflected about a vertical axis, and the m<-->w about a horizontal
> one:) option, so that a sequence of lines will each start with a
> fixed h,l,s at one endpoint, and then vary 0<h<360 at the other
> endpoint. So each design will consist of several (the number of its
> polygon sides) such rainbow fans.

Okay, a (very) preliminary first cut of that is done, with sample at
   http://www.forkosh.com/decorative4.ps
which is certainly not quantitative like your pages, but perhaps as
the filename suggests, decorative and maybe a little bit informative.
It shows only s=1 and l=1 for 36 h's, repeated three times to
form the design. The circle's center is always r,g,b=127,0,127,
interpolated out to the circumference at the appropriate h,l,s
using your ps code (i.e., anything wrong is entirely your fault:).

You can reproduce the design youself, varying the parameters
any way you like, as follows. The ps file's %%title is
  %%Title: ps&example=1&colorseed=999&bezier=0&linewidth1=6&linewidth0=0.5
  &fgstart=200&fggstart=0&ngon=3&nsteps=36&hlslmax=1.0&hlssmax=1.0&hue0=0
  &hue1=360
which is just the query submitted to the online cgi that anybody can use.
So just enter http://www.forkosh.com/cgi-bin/lineart.cgi?
into your browser's address window, following the ? with ps&example=1&etc.
And your browser should then prompt you to save the postscript file
(unless it's already handling postscript with some plugin, or something).

You can probably guess what's what: hlslmax and hlssmax from 0.0 to 1.0
are the l and s value, respectively; 0 <= hue0 < hue1 <=360, integers,
is the h-range, displayed in nsteps. The circle's fixed center color
is controlled by 0<=fgstart<=255, integer, which sets all
three r,g,b (grayscale), or fgrstart,fggstart,fgbstart sets them
individually (the sample sets fgstart=200&fggstart=0, turning off g).
Besides interpolating colors, each line is  linewidth0 setlinewidth
at the circle's center to  linewidth1 setlinewidth  at its circumference.
bezier and ngon are integers you can play with (they'll affect the
design, but not its colors). examples=1 thru 7 are defined, but
not all can deal with the new hue0 and hue1 attributes.
colorseed does nothing but is a temporary housekeeping necessity.
And please always include that leading ps&etc attribute.
   Thanks again for that ps code, and for all the subsequent
discussion,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#917

Reply for July 4, 2012:

John,

your decorative graphic looks really nice, congratulations!

Using stepwise rendering instead of smooth shading, which requires 
PostScript 3, has one disadvantage:
Do you observe in Acrobat thin white lines between the segments?
These are artefacts created by Acrobat, trying to interpolate a segment
boundary with respect to a white background. Two solutions:
1) Uncheck 'Smooth lineart' in Acrobat. But then the whole image looks 
   pixelated.
2) Render twice. First pass with e.g. 17 segments, second pass with 
   100 segments. The second pass interpolates as well, but with respect 
   to an almost correct background. 
   All my CIE-Diagrams are rendered twice. 

If you've nothing else to do, you may have a look here:
http://www.fho-emden.de/~hoffmann/casamunsell24062012.pdf

Best regards -- Gernot Hoffmann     

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

#918

gernot.hoffmann@hs-emden-leer.de wrote:
> Reply for July 4, 2012:
> 
> your decorative graphic looks really nice, congratulations!

I hope you looked (literally) just now, because the originally
uploaded version was mistakenly using different random l,s values
for each line (I'd flipped an if/then/else clause). It's now
fixed, and the sample's using constant l=0.5, s=1.0. And I've added
a %comment after each setrgb showing the corresponding h,l,s values,
just to be sure.

The correct sample graphic now replaces the original erroneous one,
at forkosh.com/decorative4.ps and now shows a nice color fan as expected.
And, of course, the online cgi is corrected and replaced, too.
Sorry about that.

> Using stepwise rendering instead of smooth shading, which requires 
> PostScript 3, has one disadvantage:
> Do you observe in Acrobat thin white lines between the segments?

Actually, I've just been using gv, which shows your stepwise rendering
quite nicely. I'll have to try acrobat when I get to a box that has it.

> These are artefacts created by Acrobat, trying to interpolate a segment
> boundary with respect to a white background. Two solutions:
> 1) Uncheck 'Smooth lineart' in Acrobat. But then the whole image looks 
>   pixelated.
> 2) Render twice. First pass with e.g. 17 segments, second pass with 
>   100 segments. The second pass interpolates as well, but with respect 
>   to an almost correct background. 
>   All my CIE-Diagrams are rendered twice. 

Okay, I'll put that on my to-do list. I think I can modify your code
myself to deal with an N1 and an N2. And I guess the constraint
is to pick them relatively prime, or something like that, so no two
boundaries coincide.

> If you've nothing else to do, you may have a look here:
> http://www.fho-emden.de/~hoffmann/casamunsell24062012.pdf

Excellent. You can never be too rich, or too thin,
or have too many pictures of public toilets.
Actually, your "rosetta stone" german/english page
gave me an opportunity to try to remember my one year
of college german (and three of french). I've spent
several months in france, so have whatever french I know
fairly permanently imprinted. But only a few days in
germany, so couldn't even remember how to ask
where to find ... the public toilet (now I can just
point to the picture).

> Best regards -- Gernot Hoffmann     
Ditto, thanks so much.

-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#919

JohnF <john@please.see.sig.for.email.com> wrote:
> gernot.hoffmann@hs-emden-leer.de wrote:
>> 2) Render twice. First pass with e.g. 17 segments, second pass with 
>>   100 segments. The second pass interpolates as well, but with respect 
>>   to an almost correct background. 
>>   All my CIE-Diagrams are rendered twice. 
> 
> Okay, I'll put that on my to-do list. I think I can modify your code
> myself to deal with an N1 and an N2. And I guess the constraint
> is to pick them relatively prime, or something like that, so no two
> boundaries coincide.

Okay, that's done.
The sample forkosh.com/decorative4.ps has been replaced, yet again,
and also the forkosh.com/cgi-bin/lineart.cgi program.
For the time being I've just set N2=N1+7, which will probably
have few, and usually no, coinciding boundaries. So that should
now look okay on acrobat (it looks identical on gv to me).
I'll eventually probably choose N2 = first prime number > N1,
or something like that (haven't really thought that through yet).
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#920

On Wed, 4 Jul 2012 10:59:28 +0000 (UTC), JohnF wrote:

>JohnF <john@please.see.sig.for.email.com> wrote:
>> gernot.hoffmann@hs-emden-leer.de wrote:
>>> 2) Render twice. First pass with e.g. 17 segments, second pass with 
>>>   100 segments. The second pass interpolates as well, but with respect 
>>>   to an almost correct background. 
>>>   All my CIE-Diagrams are rendered twice. 
>> 
>> Okay, I'll put that on my to-do list. I think I can modify your code
>> myself to deal with an N1 and an N2. And I guess the constraint
>> is to pick them relatively prime, or something like that, so no two
>> boundaries coincide.
>
>Okay, that's done.
>The sample forkosh.com/decorative4.ps has been replaced, yet again,
>and also the forkosh.com/cgi-bin/lineart.cgi program.
>For the time being I've just set N2=N1+7, which will probably
>have few, and usually no, coinciding boundaries. So that should
>now look okay on acrobat (it looks identical on gv to me).
>I'll eventually probably choose N2 = first prime number > N1,
>or something like that (haven't really thought that through yet).

Please also upload a screen capture.

I have no convenient way to view .ps files.

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

#921

Wally W. <ww84wa@aim.com> wrote:
>>JohnF <john@please.see.sig.for.email.com> wrote:
>>> gernot.hoffmann@hs-emden-leer.de wrote:
>>>> 2) Render twice. First pass with e.g. 17 segments, second pass with 
>>>>   100 segments. The second pass interpolates as well, but with respect 
>>>>   to an almost correct background. 
>>>>   All my CIE-Diagrams are rendered twice. 
>>> 
>>> Okay, I'll put that on my to-do list. I think I can modify your code
>>> myself to deal with an N1 and an N2. And I guess the constraint
>>> is to pick them relatively prime, or something like that, so no two
>>> boundaries coincide.
>>
>>Okay, that's done.
>>The sample forkosh.com/decorative4.ps has been replaced, yet again,
>>and also the forkosh.com/cgi-bin/lineart.cgi program.
>>For the time being I've just set N2=N1+7, which will probably
>>have few, and usually no, coinciding boundaries. So that should
>>now look okay on acrobat (it looks identical on gv to me).
>>I'll eventually probably choose N2 = first prime number > N1,
>>or something like that (haven't really thought that through yet).
> 
> Please also upload a screen capture.
> I have no convenient way to view .ps files.

Sorry, Wally, I don't have any such thing to upload.
Your browser should be letting you save the files
as lineart.ps (or as anything else you choose to name them),
Then googling  postscript viewer  gives me "About 3,550,000 results".
Probably at least one is for your OS (I'm using linux and would
guess the odds are you're using windows). ghostview (also called gv)
is maybe the most common free/opensource one. And I'm sure
there's a windows version. But I don't know whether it's a "one click"
install on windows, or has lots of dependencies (which would probably
be mostly fonts files) that would make installation a chore.
Maybe try a postscript ng for more info (or maybe somebody will
followup here).
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#925

On Wed, 4 Jul 2012 13:46:41 +0000 (UTC), JohnF wrote:

>Wally W. <ww84wa@aim.com> wrote:
>>>JohnF <john@please.see.sig.for.email.com> wrote:
>>>> gernot.hoffmann@hs-emden-leer.de wrote:
>>>>> 2) Render twice. First pass with e.g. 17 segments, second pass with 
>>>>>   100 segments. The second pass interpolates as well, but with respect 
>>>>>   to an almost correct background. 
>>>>>   All my CIE-Diagrams are rendered twice. 
>>>> 
>>>> Okay, I'll put that on my to-do list. I think I can modify your code
>>>> myself to deal with an N1 and an N2. And I guess the constraint
>>>> is to pick them relatively prime, or something like that, so no two
>>>> boundaries coincide.
>>>
>>>Okay, that's done.
>>>The sample forkosh.com/decorative4.ps has been replaced, yet again,
>>>and also the forkosh.com/cgi-bin/lineart.cgi program.
>>>For the time being I've just set N2=N1+7, which will probably
>>>have few, and usually no, coinciding boundaries. So that should
>>>now look okay on acrobat (it looks identical on gv to me).
>>>I'll eventually probably choose N2 = first prime number > N1,
>>>or something like that (haven't really thought that through yet).
>> 
>> Please also upload a screen capture.
>> I have no convenient way to view .ps files.
>
>Sorry, Wally, I don't have any such thing to upload.
>Your browser should be letting you save the files
>as lineart.ps (or as anything else you choose to name them),
>Then googling  postscript viewer  gives me "About 3,550,000 results".
>Probably at least one is for your OS (I'm using linux and would
>guess the odds are you're using windows). ghostview (also called gv)
>is maybe the most common free/opensource one. And I'm sure
>there's a windows version. But I don't know whether it's a "one click"
>install on windows, or has lots of dependencies (which would probably
>be mostly fonts files) that would make installation a chore.
>Maybe try a postscript ng for more info (or maybe somebody will
>followup here).

On-line converter here:
http://ps2pdf.com/convert.htm

Now I can see what you are talking about.

Interesting view.

You are right: installing ghostview is too much of a chore.

I did it on another machine. So far, I haven't been motivated to
endure the process again on this machine. Windows makes it too
inconvenient to retain functionality through an "upgrade" of the OS.

Which are reasons to upgrade the OS only as a last resort and under
great duress.

Customer-focused, and *personal* computer? Apparently so, if the
customer-person is a corporate IT control freak.

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

#922

Am Sonntag, 1. Juli 2012 14:15:11 UTC+2 schrieb JohnF:
> I'm writing a toy program to generate some decorative string art
> (a better waste of time than playing computer games, anyway:).
> Sample output is at http://www.forkosh.com/decorative.ps
> 
> Every line (in that sample) starts with constant r,g,b=95,0,95
> out of 255 (or .37 0 .37 if you view that ps file) at one end point,
> and varies linearly to randomly selected r,g,b values at the other end.
> (There's a thread in comp.programming.postscript about this,
> where Gernot Hoffmann provided the ps code that does this.)
> 
> Originally, I just used the C function drand48() to select three
> random numbers for r,g,b values. But that looked pretty "washed out",
> probably because the uniform distribution is likely to give similar
> enough values so the composite color is pretty often grayish.
> (I didn't "do the math" to figure that out; I just looked at it.)
> 
> After failing to google much of anything about this kind of topic,
> or even figuring out what search terms might be relevant, I played
> around a bit, and settled on the following C code snippet...
> 
>    /* --- constant rgb0 initial color supplied by user --- */
>    red0   = ((double)fgred0)/255.;    /* in the example case */
>    green0 = ((double)fggreen0)/255.;  /* fgr,g,b0 are 95,0,95 */
>    blue0  = ((double)fgblue0)/255.;   /* as stated above */
>    /* --- randomize rgb1 end color --- */
>    red1   = pow(drand48(),1.0);       /* exponent 1.0 does nothing */
>    green1 = pow(drand48(),1.0);       /* now, may be changed later */
>    blue1  = pow(drand48(),1.0);
>    /* --- enhance largest, diminish other two --- */
>    if ( red1 >= green1 && red1 >= blue1 ) { /* red is largest */
>      red1 = pow(red1,0.333);
>      green1 = pow(green1,2.0); blue1 = pow(blue1,2.0); }
>    else if ( green1 >= blue1 ) {            /* green is largest */
>      green1 = pow(green1,0.333);
>      red1 = pow(red1,2.0); blue1 = pow(blue1,2.0); }
>    else {                                   /* blue is largest */
>      blue1 = pow(blue1,0.333);
>      red1 = pow(red1,2.0); green1 = pow(green1,2.0); }
>    /* --- emit postscript instruction --- */
>    fprintf(fp,"%.2f %.2f %.2f %.2f %.2f %.2f setrgb01\n",
>    red0,green0,blue0,red1,green1,blue1);
> 
> ...which sets the initial constant color, chooses final random
> colors with drand48(), and then:
>   (a) replaces the largest of the three random r,g,b numbers
>       with its cube root (makes it even larger, closer to 1),
>   (b) and squares the other two (makes them smaller, closer to 0).
> However, it still looks a bit "washed out" to my eye. But pushing the
> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
> So maybe my whole idea is just no good. Is there some standard,
> or not-so-standard, way to choose random rgb numbers that both
> (a) remain pretty much random, and that also (b) make the resulting
> image more "vibrant" to the eye (whatever that quantitatively means;
> I can tell what it subjectively means just by looking)?
> -- 
> John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

John,

to be honest, the older version (kind of pastel) looked for me more
esthetical than the one between (didn't see the last one).

Here, *.PS files are automatically converted into PDF by Acrobat.
If you could send PDF, then everybody could use the free Adobe Reader
or Acrobat.

If you used *.EPS instead of *.PS, then we could view them immediately 
by other Adobe programs (Photoshop, InDesign, Illustrator).

Yes, this HLS<-->RGB conversion is really tricky. Maybe it's only an 
approximation (I forgot the algorithm), but this dates back perhaps 35
years, where trigonometric functions were very time consuming. 

Best regards --Gernot Hoffmann
 

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

#923

gernot.hoffmann@hs-emden-leer.de wrote:
> 
> John,
> 
> to be honest, the older version (kind of pastel) looked for me more
> esthetical than the one between (didn't see the last one).

That's pretty much still available, though I forget its exact
parameters. I've uploaded forkosh.com/decorative5.ps that's
a pretty much random "color wheel", which was the version
originally intended for maximum "decorativeness".
By the way, although named .ps, it's eps, see below.

The forkosh.com/decorative4.ps now runs through 0<=h<=360
just once around its entire circumference (rather than
the three times for ngon=3 earlier). That's controlled by
the (new) huesteps=0 attribute for once around, or omit the
huesteps attribute entirely for the original "three times around".
   That's arguably not as decorative, but its intent was
to be a little more informative, in a somewhat decorative way,
or something like that. The older more decorative stuff is still
all available, just by running the cgi with an appropriate
query string eps&attribute1=value1&etc. I haven't "disabled"
any functionality, just added new stuff and demonstrated it.
Using any old file's %title line for the cgi's query string
should reproduce that old file (unless I've goofed).

> Here, *.PS files are automatically converted into PDF by Acrobat.
> If you could send PDF, then everybody could use the free Adobe Reader
> or Acrobat.
> 
> If you used *.EPS instead of *.PS, then we could view them immediately 
> by other Adobe programs (Photoshop, InDesign, Illustrator).

Already done. Just replace that leading ps&etc attribute with eps&etc.
That was actually in the program all along. I just didn't think
to mention it. The only differences are the top two lines,
  1,2c1
  < %!PS-Adobe EPSF-3.0
  < %%BoundingBox: 0 0 612 792
  ---
  > %!PS
and the (absence of the) last line preceding the %%EOF
  465a465  [or some other line#, depending on the graphic]
  > showpage
I hope that's all that's needed. When I originally wrote
the program and read some online pages about ps, that's
all that seemed necessary. So I coded it that way, but
never really checked the correctness of the results
beyond the fact that gv doesn't complain.

> Yes, this HLS<-->RGB conversion is really tricky. Maybe it's only an 
> approximation (I forgot the algorithm), but this dates back perhaps 35
> years, where trigonometric functions were very time consuming. 

Yeah, antique slide rules on ebay sell for a lot these days.
The angles of the rotated rgb axes all seem to be 45 degrees
wrt the sl-plane, but I still couldn't immediately see how
you're getting all the projections so easily. But it's all
hidden in the function, and can be easily changed if needed,
completely transparent to the rest of the program.

> Best regards --Gernot Hoffmann
Thanks again.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#924

Am Sonntag, 1. Juli 2012 14:15:11 UTC+2 schrieb JohnF:
> I'm writing a toy program to generate some decorative string art
> (a better waste of time than playing computer games, anyway:).
> Sample output is at http://www.forkosh.com/decorative.ps
> 
> Every line (in that sample) starts with constant r,g,b=95,0,95
> out of 255 (or .37 0 .37 if you view that ps file) at one end point,
> and varies linearly to randomly selected r,g,b values at the other end.
> (There's a thread in comp.programming.postscript about this,
> where Gernot Hoffmann provided the ps code that does this.)
> 
> Originally, I just used the C function drand48() to select three
> random numbers for r,g,b values. But that looked pretty "washed out",
> probably because the uniform distribution is likely to give similar
> enough values so the composite color is pretty often grayish.
> (I didn't "do the math" to figure that out; I just looked at it.)
> 
> After failing to google much of anything about this kind of topic,
> or even figuring out what search terms might be relevant, I played
> around a bit, and settled on the following C code snippet...
> 
>    /* --- constant rgb0 initial color supplied by user --- */
>    red0   = ((double)fgred0)/255.;    /* in the example case */
>    green0 = ((double)fggreen0)/255.;  /* fgr,g,b0 are 95,0,95 */
>    blue0  = ((double)fgblue0)/255.;   /* as stated above */
>    /* --- randomize rgb1 end color --- */
>    red1   = pow(drand48(),1.0);       /* exponent 1.0 does nothing */
>    green1 = pow(drand48(),1.0);       /* now, may be changed later */
>    blue1  = pow(drand48(),1.0);
>    /* --- enhance largest, diminish other two --- */
>    if ( red1 >= green1 && red1 >= blue1 ) { /* red is largest */
>      red1 = pow(red1,0.333);
>      green1 = pow(green1,2.0); blue1 = pow(blue1,2.0); }
>    else if ( green1 >= blue1 ) {            /* green is largest */
>      green1 = pow(green1,0.333);
>      red1 = pow(red1,2.0); blue1 = pow(blue1,2.0); }
>    else {                                   /* blue is largest */
>      blue1 = pow(blue1,0.333);
>      red1 = pow(red1,2.0); green1 = pow(green1,2.0); }
>    /* --- emit postscript instruction --- */
>    fprintf(fp,"%.2f %.2f %.2f %.2f %.2f %.2f setrgb01\n",
>    red0,green0,blue0,red1,green1,blue1);
> 
> ...which sets the initial constant color, chooses final random
> colors with drand48(), and then:
>   (a) replaces the largest of the three random r,g,b numbers
>       with its cube root (makes it even larger, closer to 1),
>   (b) and squares the other two (makes them smaller, closer to 0).
> However, it still looks a bit "washed out" to my eye. But pushing the
> exponents (1/3 and 2) too much just "degenerates" the palette to rgb.
> So maybe my whole idea is just no good. Is there some standard,
> or not-so-standard, way to choose random rgb numbers that both
> (a) remain pretty much random, and that also (b) make the resulting
> image more "vibrant" to the eye (whatever that quantitatively means;
> I can tell what it subjectively means just by looking)?
> -- 
> John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

John,

as stated in my doc, I'm not the inventor of the HLStoRGBf-algorithm.
'f' stands for 'Foley,van Dam, Computer Graphics' (famous book), and 
I had coded this in several programming languages, even Intel Assembly.

On the other hand, I had recognized early, that this color space 
suffers much from a disadvantage: The saturation on the surface of 
the double cone is S=1. On the vertical axis we have S=0. Near to poles
we have in vicinity S=1 and S=0, which is in my opinion a not acceptable
discontinuity. In order to resolve this problem I had developed my own
HLS space, which uses S as a true cylinder coordinate - small S for 
small radius. At that time, trigonometric functions were sufficiently 
fast, using the standard floating point unit.  

Mainly, I wanted to clarify, that I'm not the inventor of the tricky 
algorithm. Thanks for the interesting discussion!

Best regards --Gernot Hoffmann
      

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.graphics.algorithms

csiph-web