Text archives Help

---

Hi,

Jens forwarded me the data.  I think I've fixed the 3D tiff issue...
example rendering attached.  Could you try a new devbuild and let me
know how it works for you?

Haven't looked at the stack (directory full of) 2D tiffs, yet...

Also, you've got RGB data... I changed our color renderer so it
supports RGB data instead of just RGBA data.  Designing a transfer
function for this kind of data is a little more difficult than most,
and we don't have any good documentation on how to do that... so I
figured I'd share that here.

This'll be long, so I'll summarize first and explain why after.

  . Only the 1D tfqn and isosurface modes support color data

  . Experiment with making the alpha equal 0 whereever the 1D histogram
  is gray, especially at the lowest and highest ends of the histogram.

  . When loading color data, make the red, green, and blue channels all
  one in the 1D histogram.

  . When loading image stacks, make sure to open the "Rendering
  Options" and crank up the "Z" spacing relative to X and Y.

  . When loading any thin volume (very little Z axis resolution), which
  usually comes from image stacks but could be from anything, crank up
  the minimum resolution.

  . One almost always wants to turn lighting off for color data.

-------------
Now, *why* you should do all these things.

  Experiment with making the alpha equal 0 whereever the 1D histogram
  is gray, especially at the lowest and highest ends of the histogram.

All volume data has "dead spots" where there is no real data.  Since
there is no community-wide agreed-upon convention for saying "there
is no data at this location", different conventions pop up.  A (very)
common convention is to use 0.  Another common convention is to use the
maximum value the output range supports, such as 255 or 65535.

A volume renderer *wants* to simply throw out such voxels, but without
a convention we don't know which voxels they are.  The aforementioned
conventions mean that setting the alpha to 0 (i.e. the bottom, in
Y) on the 1D histogram for the low and high values usually helps
out considerably.  If a volume acquisition method uses 0 for "no
data", then by making your alpha (i.e. Y) 0 at histogram location
(i.e. X) 0 will mean all of the "no data" voxels will disappear from
the visualization.

(Your data, Steve, follow this model: there's "junk" around X=0, and
if you give that data a non-zero alpha, you're going to "see" all the
"junk" -- which basically means encasing your data in a deep black fog.
By setting Y=0 when X=0, you get rid of the 'fog'.)

For color data, this can be more difficult.  The red channel could
conceivably have "junk" data in a location where the green channel has
good data.  You can't just set alpha=0 in those locations, because
it'll remove both the "junk" data as well as the green you wanted to
see.  We don't have a good solution to this... but fortunately it does
not occur very often in practice.

  When loading color data, make the red, green, and blue channels all
  one in the 1D histogram.

ImageVis3D maps your color with the colors you specify in the 1D
transfer function editor.  Let's say you've got a lot of 250's in the
"blue" channel of your data as it exists on disk.  In the editor, you
can specify that "blue" is 0.5 at histogram location x=250.  This means
that you won't see a high-intensity blue for those values -- you'll
instead see

So if you specify that the "blue" channel is at 0.5 for the x=250
location in the histogram, then you're going to get something more
like a blue intensity of 125 (dark blue) instead of 250 (bright
blue) for those locations.  This can be nice if you're experimenting
with different data acquisition processes, but for the most part is
undesirable, since it artificially modifies the colors you expected
to see.  Thus, with color data, you generally want to select the RGB
channels and make them 1 (i.e. at the top of the histogram) for the
entire width of the histogram).  This means the scaling factor is 1...
which is of course an identity function.

  When loading image stacks, make sure to open the "Rendering Options"
  and crank up the "Z" spacing relative to X and Y.

Image stacks are just that -- images.  If we get a series of images,
we have no idea that you acquired them by slicing the data every 33
millimeters, or if you generated them to have twice the resolution in
Z as you do in, say, the X dimension.  From a series of 2D images,
there's no way to store this information anyway; most programs that
would produce a series of TIFFs, for example, would not indicate that
the slice distance between each TIFF was some value, "Z" -- *even if
the program exporting the data knows this*!

In this case, ImageVis3D does not have all the information it needs.
Lacking it, it makes the assumption that the X, Y, and Z dimensions are
isotropic -- that the spacing is the same for all of them.  This is
rarely if ever true for image stacks.

  When loading any thin volume (very little Z axis resolution), which
  usually comes from image stacks but could be from anything, crank up
  the minimum resolution.

ImageVis3D constructs multiple resolutions of your data as it converts
it to UVF.  If you've got a series of 2000 by 2000 images, for
example, we'll construct a series of 200 by 200 images by selectively
downsampling the original images.  ImageVis3D uses what's called a
'progressive renderer', which means that we'll always display the 2000
by 2000 data, but if we can't do that quick enough we'll show you the
200 by 200 version while we compute the larger one.

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.

Enabling the bounding box can help you to orient yourself within
the data in such a situation, but your data still disappears at low
resolution.  A better fix is to open up the "Progress Viewer" and
use the sliders to ensure that the minimum (lowest) resolution never
renders at all.  ImageVis3D will run a bit slower, but this can make it
significantly easier to understand what's going on.

  One almost always wants to turn lighting off for color data.

Lighting effects the volume rendering calculation in ways which are
typically very confusing for color data... especially if the data are
already lit.  Furthermore, it's one more stage that prevents you from
seeing your data exactly as they exist on-disk, which is a moot point
with scalar data but generally undesirable with color data.

Furthermore, lighting is computationally very expensive.  If you're
having performance issues, turning of lighting can help considerably.

-------------

I hope that helps everyone figure out how to extract the subset[s] of
data you are interested in!  Best,

-tom

"Steve kaye" <stevekaye@talktalk.net> writes:
> Jens, Check your PMs. Regards, Steve Kaye
> 
> -----Original Message----- 
> From: Jens Krueger
> Sent: Sunday, December 05, 2010 1:41 PM
> To: Steve kaye
> Cc: iv3d-users@sci.utah.edu
> Subject: [IV3D-USERS] Re: Re: Re: Re: Re: Re: Re: Display assigned colour 
> in 
> Tifs
> 
> Hi Steve,
> 
> can you send us one or some of your files? That way we can try to reproduce 
> your problem here and trace the issue with our debugginh tools. Most likely 
> it will be an easy fix then. If you have multiple tiffs then the load from 
> directory is definately what you want to do, if your entire volume is 
> stored 
> in a single tiff file then load from file should be the right option.
> 
> The log snipped 1 you send below looks ok (it is exepcted that the DICOM 
> importer reports no usable objects since TIFFs aren't DICOMs :-) ) then it 
> seems that the image parser is looking into the TIFF file which also seems 
> ok. I guess whatever is in the debug log after that would be interesting.
> 
> The crash you observe in snipped 2 looks like a bug in imagevis (hence the 
> request for your data files above), that is one of the reasons why 
> ImageVis3d 2.0 has noot been released yet since we are looking into those 
> issues with the new features. So by sending your data you can actually 
> speed 
> up the release process :-).
> 
> Cheers
> 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 05.12.2010 um 14:14 schrieb Steve kaye:
> 
> > Hello,
> > I've downloaded the devbuild (windows-latest 5-12-2010 - 64bit) but have 
> > a 
> > data load problem. I've tried the two approaches to loading:
> >
> > 1) Load data from directory of tifs ... IV3d scans the files and then 
> > reports 'no valid files found ......'
> > Debuglog looks like this:-
> > (05.12.2010 12:58:02) MESSAGE (DICOMParser::GetDICOMFileInfo) File 
> > 'D:/personal/Indonesia study V3.0 - UCL 
> > reposition/Gravity/west-indonesia-lineaments/Imagej/9.tif' is not a DICM 
> > file.
> > (05.12.2010 12:58:02) MESSAGE (DICOMParser::GetDirInfo) 0 files in 
> > candidate list.
> > (05.12.2010 12:58:02) MESSAGE (IOManager::ScanDirectory)   found 0 DICOM 
> > stacks
> > (05.12.2010 12:58:02) MESSAGE (ImageParser::GetDirInfo) Looking for image 
> > data in file D:/personal/Indonesia study V3.0 - UCL 
> > reposition/Gravity/west-indonesia-lineaments/Imagej/1.tif
> >
> > 2) Load from file, i.e. a stack tif ........  IV3D crashes. But, IV3D 
> > devbuild will load a uvf file of the same data created within the 
> > 'released' version.
> > Debuglog of crash looks like this ....
> > (05.12.2010 12:53:50) MESSAGE 
> > (`anonymous-namespace'::identify_converters) 
> > Converter 'TIFF Volume (Image stack)' can read 'D:\personal\Indonesia 
> > study V3.0 - UCL 
> > reposition\Gravity\west-indonesia-lineaments\Imagej\stacktest.tif'!
> >
> > But the above converter seems to be ignored as the software goes on to 
> > try 
> > other types before trying to load via ...
> > (05.12.2010 12:53:50) MESSAGE (TiffVolumeConverter::ConvertToRAW) 
> > Attempting to convert TiffVolume: D:\personal\Indonesia study V3.0 - UCL 
> > reposition\Gravity\west-indonesia-lineaments\Imagej\stacktest.tif
> > (05.12.2010 12:53:50) MESSAGE (TiffVolumeConverter::ConvertToRAW) 
> > TiffVolume dimensions: 1602x1314x16
> > (05.12.2010 12:53:50) MESSAGE (TiffVolumeConverter::ConvertToRAW) 8 bits 
> > per component.
> > (05.12.2010 12:53:50) MESSAGE (TiffVolumeConverter::ConvertToRAW) 3 
> > components.
> > (05.12.2010 12:53:50) MESSAGE (TiffVolumeConverter::ConvertToRAW) Reading 
> > 1602x1314 TIFF slice 0 of 15
> >
> > when it crashes.
> >
> > I've tried both 32 and 64bit devbuild versions with the same results. 
> > Everything above works on the same datasets when using the 'released' 
> > version.
> >
> > By the way, I use imageJ (actually FIJI) to create the stacks.
> >
> > If there is an easy fix then I'd be pleased to hear of it but, if you 
> > would have to spend a lot of time on it then please don't just for my 
> > sake - I can wait for V2.0.
> >
> > Regards, Steve Kaye
> >
> > -----Original Message----- From: Steve kaye
> > Sent: Saturday, December 04, 2010 7:48 PM
> > To: iv3d-users@sci.utah.edu
> > Subject: [IV3D-USERS] Re: Re: Re: Re: Re: Display assigned colour in Tifs
> >
> > Hello everyone,
> > That is wonderful news about V2.0 and the inclusion of the possibility for
> > loading colour images. Do you know yet when V2.0 will be released?
> >
> > In the meantime I shall try to get a devbuild working.
> >
> > Thanks very much for your work.
> >
> > Regards, Steve Kaye
> >
> >
> > -----Original Message----- From: Tom (mobile)
> > Sent: Saturday, December 04, 2010 5:15 PM
> > To: iv3d-users@sci.utah.edu
> > Subject: [IV3D-USERS] Re: Re: Re: Re: Display assigned colour in Tifs
> >
> > Hi Tim!
> >
> > =)  Glad to hear it helps.  It was an oft-requested
> > feature.
> >
> > Also, Jens semi-recently implemented a 2D slice-based
> > renderer.  That renderer should support every GPU
> > that's been put out in the last decade.  I think
> > you might also need a devbuild to use it.  You
> > can switch to it under the "Renderer" tab of the
> > settings.
> >
> > Best,
> >
> > -tom
> >
> > ----- Original message -----
> >> On Saturday, December 04, 2010 10:35:55 am Tom (mobile) wrote:
> >> > Jens is right, this is already implemented on our
> >> > trunk.
> >>
> >> This is great news. This (and to a much smaller extent, the relative
> >> immaturity of OpenGL drivers that run on my laptop) is the main blocker
> >> in   terms of our using IV3D. I am excited to hear about this, and look
> >> forward to   jumping back in! Once I clear a couple more things from my
> >> plate, that is :-).
> >>
> >> Best, and congrats.
> >> --Tim
> >>
> >> >
> >> > -tom
> >> >
> >> > ----- Original message -----
> >> >
> >> > > Hi Steve,
> >> > >
> >> > > just toe make sure what you need let me try to put in my own words.
> >> > > Your have your data stored as a stack of color TIFF files and when
> >> > > you load them they are converted to grey-scale but you would prefer
> >> > > if we could load them as color images directly (without the need of
> >> > > a transfer function). Is that correct? If yes I think we may have
> >> > > already addressed your feature request and it will be included in
> >> > > ImageVis3D 2.0 to be released soon, Tom correct me if I'm wrong here
> >> > > about loading color images.
> >> > >
> >> > > 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 04.12.2010 um 14:49 schrieb Steve kaye:
> >> > > > Welcome to list iv3d-users@sci.utah.eduHello,
> >> > > > I use iv3d to display crustal gravimetric lineaments (faults, etc.)
> >> > > > using stacks of tifs in which each tif represents a depth in the
> >> > > > crust and is colour coded. This page shows what I mean -
> >> > > > http://www.bandaarcgeophysics.co.uk/banda_grav_lines.htm ;.
> >> > > >
> >> > > > This might seem an inappropriate use of iv3d but it works rather
> >> > > > well, covering large geographic areas and displaying very
> >> > > > efficiently. Thank you.
> >> > > >
> >> > > > But, as you know the colour assigned to each tiff is not displayed
> >> > > > which, in my case because of the thin line nature of the
> >> > > > lineaments, limits its visual usefulness - the depth queuing is
> >> > > > degraded.
> >> > > >
> >> > > > Would it be possible in a future release to capture the colour
> >> > > > values and display these instead of using transforms? Or both?
> >> > > >
> >> > > > Regards, Steve kaye

Attachment: pngUdZ_hlT_A2.png
Description: geophysics.png

---

• [IV3D-USERS] Display assigned colour in Tifs, Steve kaye, 12/04/2010
  • [IV3D-USERS] Re: Display assigned colour in Tifs, Jens Krueger, 12/04/2010
    • [IV3D-USERS] Re: Re: Display assigned colour in Tifs, Tom (mobile), 12/04/2010
      • [IV3D-USERS] Re: Re: Re: Display assigned colour in Tifs, Tim Holy, 12/04/2010
        • [IV3D-USERS] Re: Re: Re: Re: Display assigned colour in Tifs, Tom (mobile), 12/04/2010
          • [IV3D-USERS] Re: Re: Re: Re: Re: Display assigned colour in Tifs, Steve kaye, 12/04/2010
            • [IV3D-USERS] Re: Re: Re: Re: Re: Re: Display assigned colour in Tifs, Steve kaye, 12/05/2010
              • [IV3D-USERS] Re: Re: Re: Re: Re: Re: Re: Display assigned colour in Tifs, Jens Krueger, 12/05/2010
              • [IV3D-USERS] Re: Re: Re: Re: Re: Re: Re: Re: Display assigned colour in Tifs, Steve kaye, 12/05/2010
              • [IV3D-USERS] 3D tiffs + color transfer functions (was: Display assigned colour in Tifs), tom fogal, 12/05/2010
              • [IV3D-USERS] Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs), Tim Holy, 12/05/2010
              • [IV3D-USERS] Re: Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs), Jens Krueger, 12/05/2010
              • [IV3D-USERS] Re: Re: Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs), Tim Holy, 12/06/2010
              • [IV3D-USERS] Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs), Steve kaye, 12/06/2010

---

Archive powered by MHonArc 2.6.16.