iv3d-users

Text archives Help


[IV3D-USERS] Re: change in handling RGBA data...


Chronological Thread 
  • From: tom fogal <tfogal@sci.utah.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: [IV3D-USERS] Re: change in handling RGBA data...
  • Date: Mon, 10 Jan 2011 13:19:16 -0700

Hi Colin!

Colin Poczatek <jpoczatek@rics.bwh.harvard.edu> writes:
> I've been looking at a new-ish version (v1823 if I'm reading it
> right, I got the 64bit binary off launchpad since I was having make
> fail building from the source)

I'm very happy to hear you've got a workaround, though I'd appreciate
it if you could email me your build log so I could fix whatever the
build issue is.

> on IV3D and noticed a change.  Before loading QVis RGBA data one
> would use isosurface rendering on the A channel.  Now it seems that
> the 1DTF mode is correct

Yes, we semi-recently implemented support for the 1D TF mode with RGB /
RGBA data.

> (or the only one that works).

We recently discovered isosurfacing was broken.  I fixed it in Tuvok's
r1827 (just yesterday).

> However I can't think of what that's actually doing now, whereas
> the isosurface made intuitive sense.  If I don't change the default
> (sigmoid function on all channels?) TF am I seeing a rendering of
> "unaltered" data as defined in the file (I'd guess no)?

Correct, the default TFqn significantly modifies the data as they are
stored on disk.

> If I change the TF that's mapping from ??? to ???. Is it just
> remapping each channel individually?

To get exactly what is in your data, you will want to set the transfer
function to 1 (top of the histogram) on all channels, though most
people will want to tone down the alpha a bit.

Basically the 1D TFqn is a filter on what you have in your data, and 1
is the identity filter.  There's more detail here:

  https://lists.sci.utah.edu/sympa/arc/iv3d-users/2010-12/msg00011.html

> Do you guys know what commit that change was made in?  The old way
> seemed to work "better" with my data... Going to be making some
> figures for a paper soon.  The new way is less cartoony and maybe
> more true, I'm not sure...

I don't remember at this point, unfortunately.  But I think setting the
1D TFqn to all ones will give you something you like.  Also, be sure to
turn off lighting.

> Somewhat related, is there documentation for the 1DTF file format?
> In case I know exactly what pixel values should be rendered as...

There's no official documentation, but it is dead simple:

  <number of values in the table>
  R G B A
  R G B A
  R G B A
  ...

R, G, B, and A are each floating point values.  Of course, there should
be <number of values in the table> lines of R G B A.

You could just steal tuvok/IO/TransferFunction1D.[cpp|h] and use that
to write them, though.  The interface is pretty simple; it's basically
a vector of 4-floats with a "Save" and "Load" interface.

HTH,

-tom



Archive powered by MHonArc 2.6.16.

Top of page