Alain <aze### [at] qwertyorg> wrote:

> > "PM 2Ring" <nomail@nomail> wrote:
> >> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> >>> I'm working on a small experiment with 3d color-space, and it seems to be
> >>> working perfectly, it renders beautifully, but when it saves, the png files have
> >>> a truncated color table.  It's quite distressing.
> >>>
> >>> I've had no obvious trouble with other renders.
> >>>
> >>> Also, my jpeg output seems to be broken, and the render results are completely
> >>> different in windows 7.
> >> POV can read jpeg for image maps, but it doesn't use jpeg as an output format,
> >> due to the lossy compression.
> >>
> >>> I ran the same scene under both Windows and Linux using the same settings each
> >>> time +a0.3 +FN24 +W800 +H600
> >>>
> >> The +FN24 should be +FN8 or just +FN for a 24 bit PNG; the number refers to the
> >> bits per colour.
> >>
> >> See http://www.povray.org/documentation/view/3.6.1/219/
> >>
> >>> #declare r = function(x,y,z,rho) { rho*cos(atan(y/x))*sin(acos(z/sqrt(x*x +
> >>> y*y))) }
> >>> #declare g = function(x,y,z,rho) { rho*sin(atan(y/x))*sin(acos(z/sqrt(x*x +
> >>> y*y))) }
> >>> #declare b = function(x,y,z,rho) { rho*cos(acos(z/sqrt(x*x + y*y))) }
> >> I'm curious as to why you're using trig functions here. An algebraic approach
> >> using basic trig identities will speed things up enormously. See the Mandelbulb
> >> C code I posted recently in the "Accidental Isosurface" thread, which shows how
> >> to do the same functions as you require, but with no trig functions.
> >
> > I could possibly simplify my approach, but it was a quick and dirty experiment;
> > besides, speed isn't the issue.  The issue is color loss under Fedora, which
> > could, possibly, be explained by having the wrong image libraries: except that
> > it happens with all formats.
> > The other issue is a discrepancy between what is rendered in windows, (3.7.0
> > beta 34) and what is rendered on other systems using the same release.
> >
> > For the record, the image in p.b.i was rendered in Ubuntu 9.10 using +fn32.
> > Whether it's a valid usage of the argument or not, the number had no effect.
> >
> > A.D.B.
> >
> >
>
> +fnx set the per chanel depth.
> +fn is 8 bit per chanel, 24 per pixel, 32 if using the alpha chanel.
> +fn16 set 16 bit per chanel, 48 per pixel, 64 if using the alpha chanel.
> +fn24 or +fn32 is not supported, probably defaults to +fn8.
> The valid range is 5 to 16.
>
>
>
> Alain

I had always understood the constant to be bits per pixel, not bits per channel.

As I have stated previously, however, The channel depth has no relation, I tried
it with FN8, and it's absolutely the same. As for your other corrections, none
of them explain the REAL problem, which I will illustrate graphically in p.b.i.

A.D.B.

Post a reply to this message