iv3d-users

Text archives Help


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


Chronological Thread 
  • From: Colin Poczatek <jpoczatek@rics.bwh.harvard.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: [IV3D-USERS] Re: Re: odd color volume bug?
  • Date: Tue, 08 Mar 2011 14:30:18 -0500
On 03/08/2011 12:31 PM, tom fogal wrote:
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?

It looks like that was August '10. But looking at thinks again, I'm convinced that there's no problem with the conversion from QVis -> uvf before or now. Also I think this issue existed then, it was just that I chose a scale/medianized enough that there were very few hue saturated pixels. (more below...)

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?


Ok, so that fixes it. I think I missed that since I was focused on using isosurface rendering and hence lighting was always on (and I have a strong feeling of dejavu). Is there a change that can be made to fix this? You lose "depth cues" with no lighting, and my bosses seem to greatly favor the isosurface rendering, though I prefer the 1dtf... But I can mimic an isosurface by changing the alpha values when I write the QVis file...

If you want to look at the files I put them here: (QVis and uvf)
http://zoomwhee.mgh.harvard.edu/~cpoczatek/fogal/

Toggling lighting it's pretty obvious which part of the data are misbehaving.

I find it funny that the shader with lighting just doesn't like pink voxels...

Collin

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



The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine 
at
http://www.partners.org/complianceline . If the e-mail was sent to you in ;
error
but does not contain patient information, please contact the sender and 
properly
dispose of the e-mail.


Archive powered by MHonArc 2.6.16.

Top of page