Text archives Help

---

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.