iv3d-users

Text archives Help


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


Chronological Thread 
  • From: "Steve kaye" <stevekaye@talktalk.net>
  • To: <iv3d-users@sci.utah.edu>
  • Subject: [IV3D-USERS] Re: 3D tiffs + color transfer functions (was: Display assigned colour in Tifs)
  • Date: Mon, 6 Dec 2010 13:34:38 -0000
  • Importance: Normal
Hello Everyone,
The new devbuild works for the tif stack (stack.tif). Brilliant. See the attached jpg.

Just to clarify - this image is made up of multiple tifs, each representing gravity lineaments at a relative depth in the crust. The stack of displayed lineaments builds a plane descending into the crust, for example, a fault or thrust plane. The white-grey outlines are coasts. The area is west of Sumatra where the recent earthquakes along some of the faults shown have killed many people.

Tom, thanks very much for your notes. I followed them to get the result described. Z is set to 2.0 and all lighting turned off. You were right, of course, turning off lighting has the most effect. I think I can improve on the results with more examination within the ID transform.

I'll wait to test load the 'directory of tifs' until I hear from you.

I have another question, which I'm reluctant to ask given I'm high-jacking your application for unintended use, but would it be possible to enable a switch from the present perspective projection to orthographic? Or, maybe a method to slide from perspective to orthographic. Why? Perspective projection while viewing my sort of data, i.e basically a map with z information, is difficult to interpret away from the 'focal point' (not sure of the right term).

Finally, I'm very grateful for all your assistance, especially as you worked over the weekend. Thank you.

Regards, Steve Kaye

-----Original Message----- From: tom fogal
Sent: Monday, December 06, 2010 12:11 AM
To: Steve kaye
Cc: iv3d-users@sci.utah.edu
Subject: [IV3D-USERS] 3D tiffs + color transfer functions (was: Display assigned colour in Tifs)

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: kaye.JPG
Description: JPEG image


Archive powered by MHonArc 2.6.16.

Top of page