POV-Ray : Newsgroups : povray.general : df3 question Server Time
29 Mar 2024 09:15:55 EDT (-0400)
  df3 question (Message 1 to 9 of 9)  
From: Stephen
Subject: df3 question
Date: 10 Sep 2017 09:55:19
Message: <59b54447$1@news.povray.org>
A while ago when I was working with df3s. Both Alain and Clipka 
mentioned that df3s use grey levels not three channels of colour.
Tga2df3.exe creates RGB df3s (The utility Oosawa 4D Volume Viewer, can 
split them using only one of the channels).
How does PovRay's internal workings handle this, mathematically?
If PovRay reads a value of (say) <0.5, 0.7, 0.1> what density value 
would it give it?
Similarly for <0, 0.9, 0> or any other combination of colour components?


-- 

Regards
     Stephen


Post a reply to this message

From: clipka
Subject: Re: df3 question
Date: 10 Sep 2017 11:23:09
Message: <59b558dd$1@news.povray.org>
Am 10.09.2017 um 15:55 schrieb Stephen:
> A while ago when I was working with df3s. Both Alain and Clipka
> mentioned that df3s use grey levels not three channels of colour.
> Tga2df3.exe creates RGB df3s (The utility Oosawa 4D Volume Viewer, can
> split them using only one of the channels).
> How does PovRay's internal workings handle this, mathematically?
> If PovRay reads a value of (say) <0.5, 0.7, 0.1> what density value
> would it give it?
> Similarly for <0, 0.9, 0> or any other combination of colour components?

To the best of my knowledge, there is no such thing as a RGB DF3, so
you're asking the wrong question.

The right questions should be, "how does tga2df3.exe handle RGB colours
mathematically?" and "how does OOsawa 4D Volume Viewer get colours out
of it?"

I would presume tga2df3.exe uses the greyscale value (or an average of
the channels) from the images; and that OOsawa 4D Volume Viewer
essentially just uses a colour_map-ish system to convert density to colour.


Post a reply to this message

From: Stephen
Subject: Re: df3 question
Date: 10 Sep 2017 14:50:24
Message: <59b58970$1@news.povray.org>
On 10/09/2017 16:23, clipka wrote:
> Am 10.09.2017 um 15:55 schrieb Stephen:
>> A while ago when I was working with df3s. Both Alain and Clipka
>> mentioned that df3s use grey levels not three channels of colour.
>> Tga2df3.exe creates RGB df3s (The utility Oosawa 4D Volume Viewer, can
>> split them using only one of the channels).
>> How does PovRay's internal workings handle this, mathematically?
>> If PovRay reads a value of (say) <0.5, 0.7, 0.1> what density value
>> would it give it?
>> Similarly for <0, 0.9, 0> or any other combination of colour components?
> 
> To the best of my knowledge, there is no such thing as a RGB DF3, so
> you're asking the wrong question.
> 

Knowing that you are asking the wrong question is always good.


> The right questions should be, "how does tga2df3.exe handle RGB colours
> mathematically?" and "how does OOsawa 4D Volume Viewer get colours out
> of it?"
> 
> I would presume tga2df3.exe uses the greyscale value (or an average of
> the channels) from the images; and that OOsawa 4D Volume Viewer
> essentially just uses a colour_map-ish system to convert density to colour.
> 

I'm not convinced. I distinctly remember Oosawa telling me that the 
opened df3 was not monochromatic and asking me which colour channel to 
use. I say remember because I had an unfortunate accident with my PC and 
lost all the data on it and my backups did not work. <insert obscenity 
here> And when I downloaded the current version. That did not happen. 
When I looked at a newly created df3 by tga2df3 in a hex editor it was 
95% nulls.
So I will just grumble to myself. :-(


-- 

Regards
     Stephen


Post a reply to this message

From: clipka
Subject: Re: df3 question
Date: 10 Sep 2017 15:26:36
Message: <59b591ec$1@news.povray.org>
Am 10.09.2017 um 20:50 schrieb Stephen:

>> I would presume tga2df3.exe uses the greyscale value (or an average of
>> the channels) from the images; and that OOsawa 4D Volume Viewer
>> essentially just uses a colour_map-ish system to convert density to
>> colour.
>>
> 
> I'm not convinced. I distinctly remember Oosawa telling me that the
> opened df3 was not monochromatic and asking me which colour channel to
> use.

Maybe there is (or was) a POV-Ray /patch/ (or 3rd party software) that
implements a coloured variant of the DF3 files; but I know of none, and
I can literally guarantee that official POV-Ray only reads
single-channel DF3s.


Post a reply to this message

From: Stephen
Subject: Re: df3 question
Date: 10 Sep 2017 15:45:15
Message: <59b5964b$1@news.povray.org>
On 10/09/2017 20:26, clipka wrote:
> Am 10.09.2017 um 20:50 schrieb Stephen:
> 
>>> I would presume tga2df3.exe uses the greyscale value (or an average of
>>> the channels) from the images; and that OOsawa 4D Volume Viewer
>>> essentially just uses a colour_map-ish system to convert density to
>>> colour.
>>>
>>
>> I'm not convinced. I distinctly remember Oosawa telling me that the
>> opened df3 was not monochromatic and asking me which colour channel to
>> use.
> 
> Maybe there is (or was) a POV-Ray /patch/ (or 3rd party software) that
> implements a coloured variant of the DF3 files; but I know of none, and
> I can literally guarantee that official POV-Ray only reads
> single-channel DF3s.
> 

I believed you the first time you told me. As I always do. :-)
And it is irrelevant now as I don't have a copy of Oosawa that shows the 
behaviour I described.

-- 

Regards
     Stephen


Post a reply to this message

From: Alain
Subject: Re: df3 question
Date: 11 Sep 2017 21:12:35
Message: <59b73483$1@news.povray.org>
Le 17-09-10 à 14:50, Stephen a écrit :
> On 10/09/2017 16:23, clipka wrote:
>> Am 10.09.2017 um 15:55 schrieb Stephen:
>>> A while ago when I was working with df3s. Both Alain and Clipka
>>> mentioned that df3s use grey levels not three channels of colour.
>>> Tga2df3.exe creates RGB df3s (The utility Oosawa 4D Volume Viewer, can
>>> split them using only one of the channels).
>>> How does PovRay's internal workings handle this, mathematically?
>>> If PovRay reads a value of (say) <0.5, 0.7, 0.1> what density value
>>> would it give it?
>>> Similarly for <0, 0.9, 0> or any other combination of colour components?
>>
>> To the best of my knowledge, there is no such thing as a RGB DF3, so
>> you're asking the wrong question.
>>
> 
> Knowing that you are asking the wrong question is always good.
> 
> 
>> The right questions should be, "how does tga2df3.exe handle RGB colours
>> mathematically?" and "how does OOsawa 4D Volume Viewer get colours out
>> of it?"
>>
>> I would presume tga2df3.exe uses the greyscale value (or an average of
>> the channels) from the images; and that OOsawa 4D Volume Viewer
>> essentially just uses a colour_map-ish system to convert density to 
>> colour.
>>
> 
> I'm not convinced. I distinctly remember Oosawa telling me that the 
> opened df3 was not monochromatic and asking me which colour channel to 
> use. I say remember because I had an unfortunate accident with my PC and 
> lost all the data on it and my backups did not work. <insert obscenity 
> here> And when I downloaded the current version. That did not happen. 
> When I looked at a newly created df3 by tga2df3 in a hex editor it was 
> 95% nulls.
> So I will just grumble to myself. :-(
> 
> 

Maybe it assumed that any gray level DF3 would use only a single byte 
per voxel, and wrongly concluded that more byte per voxel meant that it 
was to be interpreted as some kind of RGB DF3.
If that's the case, in a 3 byte per voxel format, the first byte would 
be assumed to represent red, then the next green and finally blue.
A 2 bytes (16 bits) per voxel would be encoded as 5,5,5 or 5,6,5 bit per 
channel, and a 4 bytes (32 bits) as 10,10,10 ; 10,11,10 ; 11,11,10 or 
10,12,10 bit per channel.

The DF3 is intended to be gray scale, but misinterpreted as been colour.


Alain


Post a reply to this message

From: Stephen
Subject: Re: df3 question
Date: 12 Sep 2017 07:49:13
Message: <59b7c9b9$1@news.povray.org>
On 12/09/2017 02:13, Alain wrote:

> 
> Maybe it assumed that any gray level DF3 would use only a single byte 
> per voxel, and wrongly concluded that more byte per voxel meant that it 
> was to be interpreted as some kind of RGB DF3.
> If that's the case, in a 3 byte per voxel format, the first byte would 
> be assumed to represent red, then the next green and finally blue.
> A 2 bytes (16 bits) per voxel would be encoded as 5,5,5 or 5,6,5 bit per 
> channel, and a 4 bytes (32 bits) as 10,10,10 ; 10,11,10 ; 11,11,10 or 
> 10,12,10 bit per channel.
> 

That makes sense.

> The DF3 is intended to be gray scale, but misinterpreted as been colour.
> 
> 

There was a bug fix (undocumented) not too long before I first posted 
about Oosawa. So maybe that release has been removed from the site.
I found a copy of tga2df3.exe's source code on these forums.

It distinctly says:
/* read B,G,R convert to grey level */

It also gives the ratio of RGB going into the grey value. And that is 
what I need to adjust the media densities in PovRay when using df3's 
created by the slicing method. To use in PovRay.

So for me that is a win. :-)

http://news.povray.org/povray.unix/thread/%3C2### [at] johncoppenscom%3E/

I bet it would be possible to modify the code to produce three df3 
files, one for each colour. Without rendering the animation three times 
using a coloured filter (transmit) over the camera. That's how I've been 
doing it.


-- 

Regards
     Stephen


Post a reply to this message

From: William F Pokorny
Subject: Re: df3 question
Date: 12 Sep 2017 11:51:48
Message: <59b80294$1@news.povray.org>
On 09/11/2017 09:13 PM, Alain wrote:
> Le 17-09-10 à 14:50, Stephen a écrit :
>>
>> I'm not convinced. I distinctly remember Oosawa telling me that the 
>> opened df3 was not monochromatic and asking me which colour channel to 
>> use. I say remember because I had an unfortunate accident with my PC 
>> and lost all the data on it and my backups did not work. <insert 
>> obscenity here> And when I downloaded the current version. That did 
>> not happen. When I looked at a newly created df3 by tga2df3 in a hex 
>> editor it was 95% nulls.
>> So I will just grumble to myself. :-(
>>
> 
> Maybe it assumed that any gray level DF3 would use only a single byte 
> per voxel, and wrongly concluded that more byte per voxel meant that it 
> was to be interpreted as some kind of RGB DF3.
> If that's the case, in a 3 byte per voxel format, the first byte would 
> be assumed to represent red, then the next green and finally blue.
> A 2 bytes (16 bits) per voxel would be encoded as 5,5,5 or 5,6,5 bit per 
> channel, and a 4 bytes (32 bits) as 10,10,10 ; 10,11,10 ; 11,11,10 or 
> 10,12,10 bit per channel.
> 
> The DF3 is intended to be gray scale, but misinterpreted as been colour.
> 
> 
> Alain

As Christoph and Alain indicate/hint, you can create/encode a df3 file 
with color information provided you decode it appropriately in the SDL.

With the warning I ran only a quick sanity test or two, the following is 
an example using a df3 for an object's pigment - applied in the usual 
density_file unit cube - and requiring the new 3.8 (formally 3.7.1) 
pigment {user_defined {}} capability:

//---
#declare FnDF3val = function {
     pattern { density_file df3 "spiral.df3" interpolate 0 }
}

#declare DF3BitDepth = 8;
#declare DF3Depth    = pow(2,DF3BitDepth);
#declare BaseModVal  = int(DF3Depth/4)-1;

#declare PigByDF3 = pigment {
   user_defined {
     function { mod(FnDF3val(x,y,z)*DF3Depth/(BaseModVal*3),BaseModVal) }
     function { mod(FnDF3val(x,y,z)*DF3Depth/(BaseModVal*2),BaseModVal) }
     function { mod(FnDF3val(x,y,z)*DF3Depth/(BaseModVal*1),BaseModVal) }
     function { 0 },
     function { 0 }
   //function { mod(FnDF3val(x,y,z)*DF3Depth               ,BaseModVal) }
   }
}
//---

While we can create colors from grayscale/value encoded df3s as done 
with the shipped spiral.df3 above, what I've found in practice is the 
'density' and color is often best handled separately or as distinct 
color-density channels - if you really want control. Similary true with 
isosurface base shape functions being generated apart from the, related, 
pattern-functions controlling the pigments/textures applied to the 
isosurface.

Note the interpolate 0 on the density_file for no interpolation. 
Interpolations 1 or 2 would distort(1) any encoded color information as 
the interpolation happens internally in grayscale/single-value space.

Additional caveats with respect to df3 interpolation vs not and 
density_file interpolation noise in general can be found as part of 
documentation at:

http://wiki.povray.org/content/User:Wfpokorny/DensityFile

Bill P.


Post a reply to this message

From: Stephen
Subject: Re: df3 question
Date: 12 Sep 2017 13:33:03
Message: <59b81a4f@news.povray.org>
On 12/09/2017 16:51, William F Pokorny wrote:

> 
> As Christoph and Alain indicate/hint, you can create/encode a df3 file 
> with color information provided you decode it appropriately in the SDL.
> 

I am always impressed and humbled when I see code like you posted below.

I fear that I have muddied the waters in this thread. There are actually 
two topics involved. I have gone seamlessly from one to the other.

I am satisfied that my presumption that df3's could hold colour 
information is wrong. This was what the original post was about. I was 
trying to help someone who is writing a utility for df3s.
We both want to extract the information from complex objects without 
knowing what the pigment is. In my case it was from meshes generally 
created in Poser. So at this point I digressed to how I create them. 
Which is taking small slices of cross sections and letting PovRay doing 
the work of working out the colour. Then using a camera with a filter to 
separate the colour channels into Red, Green and Blue images. Which 
tga2df3 created three df3s. This is quite laborious and time consuming.

I wholly agree with you that density and colour should be kept separate.
Coincidently I read the link you posted below. It is well done and very 
informative btw. :)

This thread has certainly cleared up a few things about df3s for me and 
opened up a new direction for me to explore. :-)

Thanks to all.


> With the warning I ran only a quick sanity test or two, the following is 
> an example using a df3 for an object's pigment - applied in the usual 
> density_file unit cube - and requiring the new 3.8 (formally 3.7.1) 
> pigment {user_defined {}} capability:
> 
> //---
> #declare FnDF3val = function {
>      pattern { density_file df3 "spiral.df3" interpolate 0 }
> }
> 
> #declare DF3BitDepth = 8;
> #declare DF3Depth    = pow(2,DF3BitDepth);
> #declare BaseModVal  = int(DF3Depth/4)-1;
> 
> #declare PigByDF3 = pigment {
>    user_defined {
>      function { mod(FnDF3val(x,y,z)*DF3Depth/(BaseModVal*3),BaseModVal) }
>      function { mod(FnDF3val(x,y,z)*DF3Depth/(BaseModVal*2),BaseModVal) }
>      function { mod(FnDF3val(x,y,z)*DF3Depth/(BaseModVal*1),BaseModVal) }
>      function { 0 },
>      function { 0 }
>    //function { mod(FnDF3val(x,y,z)*DF3Depth              
,BaseModVal) }
>    }
> }
> //---
> 
> While we can create colors from grayscale/value encoded df3s as done 
> with the shipped spiral.df3 above, what I've found in practice is the 
> 'density' and color is often best handled separately or as distinct 
> color-density channels - if you really want control. Similary true with 
> isosurface base shape functions being generated apart from the, related, 
> pattern-functions controlling the pigments/textures applied to the 
> isosurface.
> 
> Note the interpolate 0 on the density_file for no interpolation. 
> Interpolations 1 or 2 would distort(1) any encoded color information as 
> the interpolation happens internally in grayscale/single-value space.
> 
> Additional caveats with respect to df3 interpolation vs not and 
> density_file interpolation noise in general can be found as part of 
> documentation at:
> 
> http://wiki.povray.org/content/User:Wfpokorny/DensityFile
> 
> Bill P.


-- 

Regards
     Stephen


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.