iv3d-users

Text archives Help


[IV3D-USERS] Re: Re: Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs)


Chronological Thread 
  • From: Tim Holy <holy@wustl.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: [IV3D-USERS] Re: Re: Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs)
  • Date: Mon, 6 Dec 2010 04:54:10 -0600
Hi Jens,

On Monday, December 06, 2010 12:44:13 am Jens Krueger wrote:
> that is very much what we do in the new bricking scheme that we are
> currently testing. Due to various reasons, however, this will not be an
> ImageVis3D 2.0 feature shipping with 2.1. To give you just one idea what
> the problems are, they are not  the code itself but more that by changing 
> the internal storage format we break compatiblity with older version so we
> need to make sure we have cross converters etc. in place.

Very nice!

--Tim

> 
> 
> Gruß
>  Jens Krüger
> 
> ------------------------------------------------------------
> 
> Interactive Visualization and Data Analysis Group
> http://www.ivda.uni-saarland.de
> 
> Prof. Dr. Jens Krüger
> Research Group Leader, MMCI
> Senior Researcher, DFKI
> Adjunct Professor, SCI
> Adjunct Professor, University of Utah
> 
> Campus  D3 4, Raum 2.32
> 66123 Saarbrücken
> 
> Telefon: +49 681 302-70750
> Mobil: +49 1512 5377420
> 
> Am 06.12.2010 um 03:21 schrieb Tim Holy:
> > Hi Tom,
> > 
> > On Sunday, December 05, 2010 06:11:05 pm tom fogal wrote:
> >> However the process happens to work by subsampling in all dimensions
> >> instead of just the very large dimensions.  This means when your
> >> data are heavily anisotropic (e.g. 2000x1000x30), the low resolution
> >> will shrink even the dimension which is already tiny (e.g. down to
> >> 200x100x3).  When the data gets that thin, there simply aren't that
> >> many voxels, and in many cases you just won't be able to see the data
> >> until the progressive renderer kicks in.
> > 
> > In our own code (Matlab + C functions), we handle this by having
> > subsampling progressively aim to achieve voxels that are of
> > approximately equal size along each dimension. That is, if images are
> > acquired with pixels that are 0.71 microns on a side, and we slice every
> > 5 microns, then in our analysis we create a pyramid of images with voxel
> > sizes on the following schedule: 0.71 x 0.71 x 5 (original voxel size)
> > 1.42 x 1.42 x 5 (i.e., subsample on X & Y, but not Z)
> > 2.84 x 2.84 x 5 (")
> > 5.86 x 5.86 x 5 (")
> > 11.36 x 11.36 x 10 (i.e., this time we subsample on Z, too)
> > 22.72 x 22.72 x 20 (")
> > etc.
> > 
> > This doesn't work as a good default if the volume being sampled really is
> > long and thin, of course. But the main point is that if you can
> > selectively subsample along certain axes and skip subsampling on others,
> > you can do whatever you want to make sure the data don't just
> > "disappear" on you.
> > 
> > If this strategy is viewed as desirable, I'd be happy to send you our C
> > code. But I bet it would be easier for you to implement it directly
> > rather than trying to figure out how to weave our code into yours.
> > 
> > Speaking of voxel geometry, here's a heads-up: at some point fairly soon
> > we will start collecting data where the axes of the 3d data array are
> > not orthogonal in real space. That is, in real life the data array will
> > have "shear." I don't know whether IV3D/Tuvok can handle that yet, but
> > if not I will be interested in finding out what is needed to get it
> > implemented (and perhaps give it a shot myself, if it is not yet
> > built-in and if I am capable of it).
> > 
> > Best,
> > --Tim

Archive powered by MHonArc 2.6.16.

Top of page