 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] johncoppens com%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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
