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.

I am using beta 34 under windows 7 and Fedora 11 on a Fujitsu Lifebook t5010.
So far as I know I have all the proper libraries downloaded in Fedora, I just
rebuilt the beta with libSDL.

My scene code is as follows:.

camera {
    location <3.5, 5.0, -10.0>
    up y
    right x*(image_width/image_height)
    look_at 0.0
    }
//light_source { <3.5, 5.0, -10.0> color rgb 1.0 }

#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))) }

object {
    sphere { 0.0, 3.0 }
        hollow on
        pigment { rgbft 1 }
        finish {
            ambient 1
            diffuse 0
            }
        interior {
            media {
                intervals 1
                scattering { 1, rgb 0.1 }
                samples 30, 50
                emission rgb 0.6
                density {
                    function { r(x,y,z,1) }
                    color_map {
                        [0.0 rgb 0]
                        [1.0 rgb <1,0,0>]
                        }
                    }
                }
            media {
                intervals 1
                scattering { 1, rgb 0.1 }
                samples 30, 50
                emission rgb 0.6
                density {
                    function { g(x,y,z,1) }
                    color_map {
                        [0.0 rgb 0]
                        [1.0 rgb <0,1,0>]
                        }
                    }
                }
            media {
                intervals 1
                scattering { 1, rgb 0.1 }
                samples 30, 50
                emission rgb 0.6
                density {
                    function { b(x,y,z,1) }
                    color_map {
                        [0.0 rgb 0]
                        [1.0 rgb <0,0,1>]
                        }
                    }
                }
            }
    }

I ran the same scene under both Windows and Linux using the same settings each
time +a0.3 +FN24 +W800 +H600

Fedora renders the image beautifully, properly blending the three channels, but
the save file only retains a fraction of the color-depth.

Windows saves exactly what it renders, but most of the color is just gone. The
center of the color-space turns solid black, and the most vivid waves of color
that show in the Fedora render are gone as well, leaving only some smudges in
the primary and secondary zones

A.D.B.

Post a reply to this message

Just Tried it on my desktop computer (Mac G5 Quad-2.5 Ghz Tower, dual-booting
Tiger and Ubuntu 9.10 PPC)

The output is exactly as it was in fedora, except that it saves exactly what it
renders.  I'm currently running beta 31 compiled with the MegaPOV interface
under Tiger, because the Tiger compile of beta 34 was 32-bit only.  Under
Ubuntu, I've compiled the unix 64-bit binaries.

I believe I'm currently running the 32-bit under both systems on my Lifebook.

I'll post the result of my latest render in p.b.i

A.D.B.

Post a reply to this message

"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.

Post a reply to this message

PM 2Ring wrote:

> POV can read jpeg for image maps, but it doesn't use jpeg as an output format,
> due to the lossy compression.

well I think it's there although probably not recommended:

http://news.povray.org/povray.newusers/thread/%3Cweb.4ac879683b0d195ed001f37b0@news.povray.org%3E/

Post a reply to this message

"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.

Post a reply to this message

Anthony D. Baye wrote:

> 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.

I get the same result as posted earlier (black with a few colored bits) 
on winblows xpsp3 32bit with 3.7b34 using both fn24 and fn8.

Dont have my 'buntu box set up for pov yet.

bit

Post a reply to this message

> 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.
> 
> I am using beta 34 under windows 7 and Fedora 11 on a Fujitsu Lifebook t5010.
> So far as I know I have all the proper libraries downloaded in Fedora, I just
> rebuilt the beta with libSDL.
> 
> My scene code is as follows:.
> 
> camera {
>     location <3.5, 5.0, -10.0>
>     up y
>     right x*(image_width/image_height)
>     look_at 0.0
>     }
> //light_source { <3.5, 5.0, -10.0> color rgb 1.0 }
> 
> #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))) }
> 
> object {
>     sphere { 0.0, 3.0 }
>         hollow on
>         pigment { rgbft 1 }
You should use "rgbt 1" or "rgbf 1".
>         finish {
>             ambient 1
Normaly, you use "ambient 0" in a case like this.
>             diffuse 0
>             }
>         interior {
>             media {
>                 intervals 1
Default value.
>                 scattering { 1, rgb 0.1 }
>                 samples 30, 50
Only the first value is used. ",50" is totaly ignored.
>                 emission rgb 0.6
>                 density {
>                     function { r(x,y,z,1) }
>                     color_map {
>                         [0.0 rgb 0]
>                         [1.0 rgb <1,0,0>]
>                         }
>                     }
>                 }
>             media {
>                 intervals 1
>                 scattering { 1, rgb 0.1 }
>                 samples 30, 50
>                 emission rgb 0.6
>                 density {
>                     function { g(x,y,z,1) }
>                     color_map {
>                         [0.0 rgb 0]
>                         [1.0 rgb <0,1,0>]
>                         }
>                     }
>                 }
>             media {
>                 intervals 1
>                 scattering { 1, rgb 0.1 }
>                 samples 30, 50
>                 emission rgb 0.6
>                 density {
>                     function { b(x,y,z,1) }
>                     color_map {
>                         [0.0 rgb 0]
>                         [1.0 rgb <0,0,1>]
>                         }
>                     }
>                 }
>             }
>     }
> 
> I ran the same scene under both Windows and Linux using the same settings each
> time +a0.3 +FN24 +W800 +H600
You want 24 bits per CHANEL? 72 per pixel...
+fn set output to PNG at 8 bits per chanel, for 24 bits per pixel.
> 
> Fedora renders the image beautifully, properly blending the three channels, but
> the save file only retains a fraction of the color-depth.
> 
> Windows saves exactly what it renders, but most of the color is just gone. The
> center of the color-space turns solid black, and the most vivid waves of color
> that show in the Fedora render are gone as well, leaving only some smudges in
> the primary and secondary zones
> 
> A.D.B.
> 
> 
> 

Alain

Post a reply to this message

> "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

Post a reply to this message

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