Text archives Help

---

Hi Jens,

Thanks a lot for your reply that is very helpful.

I looked at the saved 1d transfer function file. It has 4097
lines/rows. Each row has 4 columns (except the 1st row is 4096 by
itself). My guess is that: the first line specifies #entries in the
colormap; the 4 columns (from left to right) are R G B A (0: the least
components or fully transparent, 1: the most components or opaque).
Please correct me if I'm wrong.

My understanding of your reply is: Let's say a voxel has intensity v,
and the min & max intensity in the raw (also in the uvf) file are m,
M. Then the color of v is at row: (v-m)/(M-m)*4095+1
(assume that the file's first line is numbered as row 0).
Please also tell me if I'm wrong.

If my understanding above is  correct, then the easiest way for us may
be to generate our own 1d transfer func file.

Thank you guys very much for the wonderful software. It's really
pleasant to use it.

Best,
-Zhongsheng

On Wed, Jan 13, 2010 at 2:58 AM, Jens Krueger <jens@sci.utah.edu> wrote:
> Hi Zhongsheng,
>
> ImageVis3D, normalizes the lookups into the transfer function (not the data 
> itself). This is done for a good reason, let me explain what would happen 
> if we would not normalize the lookup: Most of the scanning hardware today 
> (e.g. CT, MR) produces 12bit values (but encode those as 16 bit) that means 
> that out of the range from 0 to 65536 only the first 4096 values are used 
> (i.e. 6.25 %) if we would now do a transfer function lookup into the 
> largest possible function (also 4096 on most GPUs) we would only use 256 
> (=2^8=8bits) values, which means we would treat the data like 8bit data. 
> Thus we normalize the lookup into the TF and are then able to use the 
> entire 12 bit range.
>
> So say you still want ImageVis3D not to do this normalization, there are a 
> few "quick hack" ways to get this done and we can also add a "disable 
> normailzation" feature to our lengthy todo list. One quick hack would be to 
> make sure all your datasets have the same maximum and minimum value (you 
> would only have to set two entries in your entire volume) that would cause 
> the normalization routine to apply the same normalization to all of your 
> files (effectively disabling it).
>
> Just as a side note, remember you are not looking at the raw values in 
> ImageVis3D (or any other DVR tool) but there is always a transfer function 
> applied and that transfer function does to have be monotonically 
> increasing, it can be designed any way! Thus a dataset with reduced 
> intensities does not necessarily have to be dimmer (even without the 
> quantization).
>
> Cheers
>   Jens
>
>
> Am 13.01.2010 um 03:32 schrieb Zhongsheng Guo:
>
>> Hi,
>>
>> It seems imagevis3d displays the data in a normalized way: we have 2
>> test data, which are both uint16 and are identical except that the
>> intensities in the 2nd file is half of those in the 1st file. After
>> convert the raw files to uvf files, load them in imagevis3d, then load
>> the same 1d transfer function from a file, the two volumes look same
>> in imagevis3d. Our expectation was the 2nd volume would look dimmer,
>> but they are same.
>>
>> Do you know if it's possible to control the mapping from intensities
>> (in raw, or in uvf) to colors (in imagevis3d's display)?
>>
>> Thanks!
>>
>> Best,
>> -Zhongsheng
>
>

---

• [IV3D-USERS] normalization when convert raw to uvf, Zhongsheng Guo, 01/12/2010
  • [IV3D-USERS] Re: normalization when convert raw to uvf, Jens Krueger, 01/13/2010
    • [IV3D-USERS] Re: Re: normalization when convert raw to uvf, Zhongsheng Guo, 01/14/2010
      • [IV3D-USERS] Re: Re: Re: normalization when convert raw to uvf, tom fogal, 01/16/2010
        • [IV3D-USERS] Re: Re: Re: Re: normalization when convert raw to uvf, Zhongsheng Guo, 01/21/2010

---

Archive powered by MHonArc 2.6.16.