Text archives Help
- 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.