Text archives Help

---

Hi Tom,

Thanks a lot!

Best,
-Zhongsheng

On Sat, Jan 16, 2010 at 2:31 AM, tom fogal <tfogal@alumni.unh.edu> wrote:
> Zhongsheng Guo <kuai98@gmail.com> writes:
>> 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.
>
> Your understanding of the file format is correct.
>
>> 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).
>
> Close, it boils down to something similar.  More specifically, the
> algorithm is:
>
>  c = v * (2^w / M)
>  color = premultiplied(correct(c))
>
> `v' and `M' have the same meaning you've given. `m' is assumed to be 0
> [1], and `w' is the "bit width" of the dataset.  Since you've mentioned
> your transfer functions have 4096 values, your w==12.  It is also
> possible for w to be 8 in ImageVis3D.  The transfer function will have
> fewer entries if that is the case.
>
> "correct" and "premulitiplied" are some simple functions which are
> required for correctness.  They shouldn't be relevant here.
>
> In the long run, we'll probably switch to a "bias and scale" method,
> which can handle more naturally handles data which haven't been
> modified in any way.
>
>> If my understanding above is correct, then the easiest way for us may
>> be to generate our own 1d transfer func file.
>
> I agree that it will likely prove fairly easy.
>
>> Thank you guys very much for the wonderful software. It's really
>> pleasant to use it.
>
> You're welcome, glad you're getting some use out of it!
>
> Cheers,
>
> -tom
>
> [1] Now that you make me think about it, we've semi-recently added a
>    feature where the input data are left unmodified if they fit in the
>    required 12bit range, which would mean we're not using as much of
>    the available range as we could.  That said, 0 is a pretty common
>    `no data' representation, and thus fairly common as well..
>
>
>> 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 o
>> ut of the range from 0 to 65536 only the first 4096 values are used (i.e. 
>> 6.2
>> 5 %) 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 
>> loo
>> kup 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 
>> normail
>> zation" feature to our lengthy todo list. One quick hack would be to make 
>> sur
>> e all your datasets have the same maximum and minimum value (you would 
>> only h
>> ave to set two entries in your entire volume) that would cause the 
>> normalizat
>> ion 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 
>> > Imag
>> eVis3D (or any other DVR tool) but there is always a transfer function 
>> applie
>> d and that transfer function does to have be monotonically increasing, it 
>> can
>>  be designed any way! Thus a dataset with reduced intensities does not 
>> necess
>> arily 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.