Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.graphics.algorithms > #906
| From | JohnF <john@please.see.sig.for.email.com> |
|---|---|
| Newsgroups | comp.graphics.algorithms |
| Subject | Re: decorative random colors algorithm |
| Date | 2012-07-02 07:58 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <jsrkbk$h8i$1@reader1.panix.com> (permalink) |
| References | <jspf0f$moq$1@reader1.panix.com> <2e449cd7-eba0-4741-968a-ab1404d568e2@googlegroups.com> |
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 )
Back to comp.graphics.algorithms | Previous | Next — Previous in thread | Next in thread | Find similar
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
csiph-web