iv3d-users

Text archives Help


[IV3D-USERS] Re: Re: Re: NRRD import


Chronological Thread 
  • From: tom fogal <tfogal@alumni.unh.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: [IV3D-USERS] Re: Re: Re: NRRD import
  • Date: Fri, 22 Jan 2010 11:57:30 -0700
Tim Holy <holy@wustl.edu> writes:
> On Thursday 21 January 2010 07:36:38 pm tom fogal wrote:
> > Anyway, I've fixed it in the source && kicked our build systems.  Could
> > you try the latest devbuild?  They're available here:
> > 
> >   http://www.sci.utah.edu/devbuilds/imagevis3d/
> 
> So, the crashing bug is fixed and it writes a UVF file now. Yay! Many
> thanks!

You're welcome!

> However, on my installation it seems iv3d only renders the red
> channel, as a grayscale image---if I set the red channel to 0, the
> rendering window is black, whereas if I change any of the other color
> channels there is no obvious effect. The exception is the alpha
> channel; if I set everything to some constant value (either 0, 128,
> or 255), the window comes up black, but if I allow the alpha channel
> to be random I indeed see a cubic volume (depending on whether there
> is information in the red channel).

Because volume rendering vector data makes no sense, you need to use
the isosurface renderer with color data.

We could, in the special case that the vector data in the file is RGBA
color data, render the data directly (i.e. without applying a transfer
function).  This would be a bit of work and I've only had one user ask
for it previously, so we've never jumped on it.

... all that said, we should really detect color data && disable the 1D
and 2D TFs, so you'd never run into this.  Sorry.

> This raises a second issue I should probably mention: two days ago
> when I installed iv3d on my own laptop (32bit but with an ATI GPU,
> so the rendering won't work), I installed the "milestone release"
> 1.2.0. It worked as well as could be expected, meaning it started
> and converted files to UVF. But when I tried a "devbuild" release
> installed as a tarball I immediately got a segfaul (without it ever
> opening a window), with this message in dmesg:
>
> [144112.305471] ImageVis3D[22355]: segfault at 1 ip 002d0542 sp
> bfbc2140 error 4 in libQtCore.so.4.5.2[18c000+22b000]

The tarball is just about the sketchiest thing I've ever created.
I build it in a debian `etch' VM, statically link in Qt, and hope
that users' systems will have similarly compatible libraries (glibc,
libstdc++, the entire stack Qt depends on, etc.)

That hope/assumption is just plain wrong.  It would be a fine approach
for an "etch" binary, but generally isn't applicable to, say, support
a Fedora Core installation.  We become more likely to hit these issues
the farther apart these releases become.

I've been dabbling with supplying FC RPMs, but due to a compiler bug
the latest FC can't compile IV3D [1].

> I think I tried 2 of the 3 most recent tarballs, and they both showed
> this behavior. The ppa, however, works fine (except for rendering,
> that is). So for me personally this is not a pressing issue, but I
> thought you might want to know.

The ppa probably works because it is built on a karmic box, which is
either what you're running or at least has a compatible software stack
to what you have.

I would very much welcome community contributions in the packaging
department.  For debian-derivatives, I can get you a source deb.  I
don't have a spec file for rpm-based distros yet, but would certainly
welcome one.
If anyone is interested, please contact me on tuvok-developers or
off-list, privately.  Thanks,

-tom

[1] https://bugzilla.redhat.com/show_bug.cgi?id=548826

Archive powered by MHonArc 2.6.16.

Top of page