iv3d-users

Text archives Help


[IV3D-USERS] Re: odd color volume bug?


Chronological Thread 
  • From: tom fogal <tfogal@sci.utah.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: [IV3D-USERS] Re: odd color volume bug?
  • Date: Tue, 08 Mar 2011 10:31:36 -0700
Hi Collin!

Colin Poczatek <jpoczatek@rics.bwh.harvard.edu> writes:
> Ok, I've convinced myself that this is a bug but as usual it's
> possible I'm wrong.  It's possible that I broke our QVis export code,
> but I kinda doubt it.
>
> Background:  So we have multichannel data (16bit) and commonly view
> it in 2D by taking (Channel-A / Channel-B) (now a float) and mapping
> that to a hue scale and mapping Channel-B to alpha.  We've been doing
> the same thing making color volumes (QVis format) and rendering in
> iv3d.
>
> In the attached screenshot on the left there's a file I made a while
> back, and on the right is the same data with a different hue scale
> isosurface and 1dtf rendered.

How long ago is "a while back"?  A year ago?  2?

> When I change the bounds on the hue scale so more voxels are
> saturated (ie close to max hue) those voxels aren't rendered as
> bright but appear very dark.  This is apparent if you look at the
> "pink ball".

Can you turn off lighting and tell me if that fixes the problem?

> This isn't an isosurface issue as you can see in the 1dtf view, with
> a clipping plane to show the interior of the "pink ball".
>
> To double check that I was writing values that made sense, I ran the
> .raw part of the QVis file through unu and grabbed a little 3x3x3
> nrrd from the center of the "pink ball" and looked at the bytes in
> a hex editor.  RGBA values are all (212, 55, 212, 155) (+/- 1 or 2)
> which seem to me to be sensible values.

I have a vague memory of messing with these shaders so that they'd be
easier to use with 3 (not 4) channel data.  One thing to note is that
you really want to set alpha to 1 (i.e. the top of the TFqn) across
your entire dataset if you have 4-channel data.  Otherwise you get some
really strange results.

We should really detect 4-channel data and change the default transfer
function, to be honest... patches welcome ;)

If the alpha in the TFqn isn't the issue, could you send me your data
(preferably in QVis format so I can make sure conversion isn't messed
up) + transfer function?

Best,

-tom

Archive powered by MHonArc 2.6.16.

Top of page