Wesley Smith

I searched the archives, but didn't find anything on this subject. 

I'm using jit.gl.volume for visualizing some data right now and

First, the range of values for intesity according to the help HTML doc

are implied to be [0, 1] when in fact they are [0, 255].

Second, the density and distance parameters do absolutely nothing on my system.

Hi,
I searched the archives, but didn't find anything on this subject. 
I'm using jit.gl.volume for visualizing some data right now and
noticed a few inconsistencies.

First, the range of values for intesity according to the help HTML doc
are implied to be [0, 1] when in fact they are [0, 255].

jit-gl-volume

On Feb 7, 2006, at 10:59 AM, Wesley Smith wrote:

> I searched the archives, but didn't find anything on this subject.

> I'm using jit.gl.volume for visualizing some data right now and

> First, the range of values for intesity according to the help HTML doc

> are implied to be [0, 1] when in fact they are [0, 255].

Thanks for the mention. Actually it is unbounded for the maximum, and 

as far as viewing is concerned depended on the number slices, and 

perhaps other attributes. I suppose that the default value implies 

the range, but nowehere is the range specified. Perhaps we can post 

the formula used, which would be significantly more descriptive than 

> Second, the density and distance parameters do absolutely nothing 

Hmmm. Same here. Perhaps these are legacy parameters based on an 

earlier implementation. I think the distance is now implicit in the 

object transformation, and I'm not sure what the difference between 

> I searched the archives, but didn't find anything on this subject.
> I'm using jit.gl.volume for visualizing some data right now and
> noticed a few inconsistencies.
>
> First, the range of values for intesity according to the help HTML doc
> are implied to be [0, 1] when in fact they are [0, 255].

Thanks for the mention. Actually it is unbounded for the maximum, and  
as far as viewing is concerned depended on the number slices, and  
perhaps other attributes. I suppose that the default value implies  
the range, but nowehere is the range specified. Perhaps we can post  
the formula used, which would be significantly more descriptive than  
posting ranges of acceptable values.

> Second, the density and distance parameters do absolutely nothing  
> on my system.

Hmmm. Same here. Perhaps these are legacy parameters based on an  
earlier implementation. I think the distance is now implicit in the  
object transformation, and I'm not sure what the difference between  
density and intensity would be.

I would say density is a threshold for displaying info and intensity

is kind of like a limunance of the entire dataset. If this were the

case, then I would expect there to de a density mode 0/1 for

displaying everything below/above the given density value. What do

I'm not sure what the difference between
> density and intensity would be.
>
'
I would say density is a threshold for displaying info and intensity
is kind of like a limunance of the entire dataset.  If this were the
case, then I would expect there to de a density mode 0/1 for
displaying everything below/above the given density value.  What do
you think?

On Feb 7, 2006, at 1:14 PM, Wesley Smith wrote:

> I'm not sure what the difference between

> I would say density is a threshold for displaying info and intensity

> is kind of like a limunance of the entire dataset. If this were the

> case, then I would expect there to de a density mode 0/1 for

> displaying everything below/above the given density value. What do

Sounds appropriate to me, but I'll need to find sometime to review 

what is happening in this object and try to discern the intended 

purpose of this feature, as the original developer, Derek, has moved 

on to another employer. I'm not sure if I'll find the time to do this 

in the near future, but keep in mind that such a task can also be 

accomplished with an object like [jit.op @op >p], jit.lumakey, or 

>  I'm not sure what the difference between
>> density and intensity would be.
>>
> '
> I would say density is a threshold for displaying info and intensity
> is kind of like a limunance of the entire dataset.  If this were the
> case, then I would expect there to de a density mode 0/1 for
> displaying everything below/above the given density value.  What do
> you think?

Sounds appropriate to me, but I'll need to find sometime to review  
what is happening in this object and try to discern the intended  
purpose of this feature, as the original developer, Derek, has moved  
on to another employer. I'm not sure if I'll find the time to do this  
in the near future, but keep in mind that such a task can also be  
accomplished with an object like [jit.op @op >p], jit.lumakey, or  
jit.chromakey in the meantime.

> in the near future, but keep in mind that such a task can also be

> accomplished with an object like [jit.op @op >p], jit.lumakey, or

True, but if the ops could be done in opengl via the opengl interface

available within jit.gl.volume which would be preferable. Obviously,

this will require some work, so I don't expect this to be addressed

immediately. Just want to get it on the record.

> in the near future, but keep in mind that such a task can also be
> accomplished with an object like [jit.op @op >p], jit.lumakey, or
> jit.chromakey in the meantime.
>

True, but if the ops could be done in opengl via the opengl interface
available within jit.gl.volume which would be preferable.  Obviously,
this will require some work, so I don't expect this to be addressed
immediately.  Just want to get it on the record.

On Feb 7, 2006, at 1:58 PM, Wesley Smith wrote:

> True, but if the ops could be done in opengl via the opengl interface

> available within jit.gl.volume which would be preferable.

This stuff is all happening on the CPU before the 3D texture is 

dispatched to the GPU, so I don't think it will have significant 

performance difference except on really large matrices.

> True, but if the ops could be done in opengl via the opengl interface
> available within jit.gl.volume which would be preferable.

This stuff is all happening on the CPU before the 3D texture is  
dispatched to the GPU, so I don't think it will have significant  
performance difference except on really large matrices.