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