iv3d-users

Text archives Help


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


Chronological Thread 
  • From: Jens Krueger <jens@sci.utah.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: [IV3D-USERS] Re: Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs)
  • Date: Mon, 6 Dec 2010 07:44:13 +0100
Hi Folks,

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. 


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