Re: [osg-users] osgVolume ready for testing
Yes. I will be testing the osgVolume in the next couple days, this looks exciting :) cheers ! guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 11:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing Hi Guillaume, Just to be clear, it looks to me that the typo was "LUMINANACE" (an extra A crept in) which should be "LUMINANCE". Robert. On Tue, Aug 18, 2009 at 4:01 PM, Poirier, Guillaume wrote: > I got the source from > > http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGrap > h-2.8.2.zip > > In osgvolume.cpp. > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert > Osfield > Sent: August-18-09 10:53 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] osgVolume ready for testing > > On Tue, Aug 18, 2009 at 3:40 PM, Poirier, > Guillaume wrote: >> Thanks. The typos are on lines 687, 689, 695, and 930. > > And which version of the OSG are you talking about??? These line > numbers don't make sense for the svn/trunk version. The best way to > point to an issue like this is to fix and then provide the changed > file. > > As a general note, I'm not diagnosed but have many of the traits of > dyslexia, this comes out in practice with me making typo/spelling > mistakes that I never spot on review myself, it's only via spell > checkers in email clients that I can hide how many mistakes I make in > general mail, with coding alas there is no such safety net... so for > code it's the community that have the eagles eyes and spot and correct > my mistakes. > > Thankfully C++ compilers catch the vast majority of actual coding > typo's, so it tends to be just variable names, or comments that you'll > see mistakes in, in the case of variable name typo's, they be carried > over to all instances otherwise it wouldn't compile. Curiously we > don't actually see many bugs introduced due to me problems with > spelling ineptitude, with is lucky really... ;-) > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or > g > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Guillaume, Just to be clear, it looks to me that the typo was "LUMINANACE" (an extra A crept in) which should be "LUMINANCE". Robert. On Tue, Aug 18, 2009 at 4:01 PM, Poirier, Guillaume wrote: > I got the source from > > http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGrap > h-2.8.2.zip > > In osgvolume.cpp. > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert > Osfield > Sent: August-18-09 10:53 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] osgVolume ready for testing > > On Tue, Aug 18, 2009 at 3:40 PM, Poirier, > Guillaume wrote: >> Thanks. The typos are on lines 687, 689, 695, and 930. > > And which version of the OSG are you talking about??? These line > numbers don't make sense for the svn/trunk version. The best way to > point to an issue like this is to fix and then provide the changed > file. > > As a general note, I'm not diagnosed but have many of the traits of > dyslexia, this comes out in practice with me making typo/spelling > mistakes that I never spot on review myself, it's only via spell > checkers in email clients that I can hide how many mistakes I make in > general mail, with coding alas there is no such safety net... so for > code it's the community that have the eagles eyes and spot and correct > my mistakes. > > Thankfully C++ compilers catch the vast majority of actual coding > typo's, so it tends to be just variable names, or comments that you'll > see mistakes in, in the case of variable name typo's, they be carried > over to all instances otherwise it wouldn't compile. Curiously we > don't actually see many bugs introduced due to me problems with > spelling ineptitude, with is lucky really... ;-) > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or > g > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
I got the source from http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGrap h-2.8.2.zip In osgvolume.cpp. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 10:53 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing On Tue, Aug 18, 2009 at 3:40 PM, Poirier, Guillaume wrote: > Thanks. The typos are on lines 687, 689, 695, and 930. And which version of the OSG are you talking about??? These line numbers don't make sense for the svn/trunk version. The best way to point to an issue like this is to fix and then provide the changed file. As a general note, I'm not diagnosed but have many of the traits of dyslexia, this comes out in practice with me making typo/spelling mistakes that I never spot on review myself, it's only via spell checkers in email clients that I can hide how many mistakes I make in general mail, with coding alas there is no such safety net... so for code it's the community that have the eagles eyes and spot and correct my mistakes. Thankfully C++ compilers catch the vast majority of actual coding typo's, so it tends to be just variable names, or comments that you'll see mistakes in, in the case of variable name typo's, they be carried over to all instances otherwise it wouldn't compile. Curiously we don't actually see many bugs introduced due to me problems with spelling ineptitude, with is lucky really... ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
On Tue, Aug 18, 2009 at 3:40 PM, Poirier, Guillaume wrote: > Thanks. The typos are on lines 687, 689, 695, and 930. And which version of the OSG are you talking about??? These line numbers don't make sense for the svn/trunk version. The best way to point to an issue like this is to fix and then provide the changed file. As a general note, I'm not diagnosed but have many of the traits of dyslexia, this comes out in practice with me making typo/spelling mistakes that I never spot on review myself, it's only via spell checkers in email clients that I can hide how many mistakes I make in general mail, with coding alas there is no such safety net... so for code it's the community that have the eagles eyes and spot and correct my mistakes. Thankfully C++ compilers catch the vast majority of actual coding typo's, so it tends to be just variable names, or comments that you'll see mistakes in, in the case of variable name typo's, they be carried over to all instances otherwise it wouldn't compile. Curiously we don't actually see many bugs introduced due to me problems with spelling ineptitude, with is lucky really... ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Thanks. The typos are on lines 687, 689, 695, and 930. guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 10:02 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing Hi Guiillaume, On Tue, Aug 18, 2009 at 2:52 PM, Poirier, Guillaume wrote: > My question is: If I have 1024 slices as 1024 png image files, how do I > load them in osgvolume ? Sorry this is trivial... osgconv --image *.png is how I'd do it... > Also I noticed a typo in osgvolume.cpp, "REPLACE_ALPHA_WITH_LUMINANACE". ? Which line numbers?? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Guiillaume, On Tue, Aug 18, 2009 at 2:52 PM, Poirier, Guillaume wrote: > My question is: If I have 1024 slices as 1024 png image files, how do I > load them in osgvolume ? Sorry this is trivial... osgconv --image *.png is how I'd do it... > Also I noticed a typo in osgvolume.cpp, "REPLACE_ALPHA_WITH_LUMINANACE". ? Which line numbers?? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
My question is: If I have 1024 slices as 1024 png image files, how do I load them in osgvolume ? Sorry this is trivial... Also I noticed a typo in osgvolume.cpp, "REPLACE_ALPHA_WITH_LUMINANACE". cheers ! guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 6:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing Hi Guillaume, I'm sorry but your explanation doesn't mean anything to me, I just don't understand the problem you have that your are trying to solve. Please also remember the osgvolume example is just an code example, it's not a tool, you as programming will be using the osgVolume NodeKit, it's up to you how your app assembles it's data. Robert. On Mon, Aug 17, 2009 at 6:14 PM, Poirier, Guillaume wrote: > Sorry I meant that you can do something like: > >>osgvolume --images data/*.png > > or > >>osgvolume --images data/data_000.png > > And it would load all 256 slices from data_000.png to say data_255.png. > > > guillaume > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert > Osfield > Sent: August-17-09 1:04 PM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] osgVolume ready for testing > > Ho Guillaume, > > On Mon, Aug 17, 2009 at 4:58 PM, Guillaume > Poirier wrote: >> Sorry for the simple question... I am trying to load a list of images > using the --images flag. Looking at the osgvolume.cpp code in 2.8.2, I > don't see how it can detect *.png like you mentioned, or detect the list > of slices from the filenames. Am I right on this ? > > It doesn't need to detect the image file type, it just passes the > filename to readImageFile() and it's does the reading via the OSG's > normal plugin mechanism. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or > g > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Guillaume, I'm sorry but your explanation doesn't mean anything to me, I just don't understand the problem you have that your are trying to solve. Please also remember the osgvolume example is just an code example, it's not a tool, you as programming will be using the osgVolume NodeKit, it's up to you how your app assembles it's data. Robert. On Mon, Aug 17, 2009 at 6:14 PM, Poirier, Guillaume wrote: > Sorry I meant that you can do something like: > >>osgvolume --images data/*.png > > or > >>osgvolume --images data/data_000.png > > And it would load all 256 slices from data_000.png to say data_255.png. > > > guillaume > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert > Osfield > Sent: August-17-09 1:04 PM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] osgVolume ready for testing > > Ho Guillaume, > > On Mon, Aug 17, 2009 at 4:58 PM, Guillaume > Poirier wrote: >> Sorry for the simple question... I am trying to load a list of images > using the --images flag. Looking at the osgvolume.cpp code in 2.8.2, I > don't see how it can detect *.png like you mentioned, or detect the list > of slices from the filenames. Am I right on this ? > > It doesn't need to detect the image file type, it just passes the > filename to readImageFile() and it's does the reading via the OSG's > normal plugin mechanism. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or > g > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Sorry I meant that you can do something like: >osgvolume --images data/*.png or >osgvolume --images data/data_000.png And it would load all 256 slices from data_000.png to say data_255.png. guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-17-09 1:04 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgVolume ready for testing Ho Guillaume, On Mon, Aug 17, 2009 at 4:58 PM, Guillaume Poirier wrote: > Sorry for the simple question... I am trying to load a list of images using the --images flag. Looking at the osgvolume.cpp code in 2.8.2, I don't see how it can detect *.png like you mentioned, or detect the list of slices from the filenames. Am I right on this ? It doesn't need to detect the image file type, it just passes the filename to readImageFile() and it's does the reading via the OSG's normal plugin mechanism. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Ho Guillaume, On Mon, Aug 17, 2009 at 4:58 PM, Guillaume Poirier wrote: > Sorry for the simple question... I am trying to load a list of images using > the --images flag. Looking at the osgvolume.cpp code in 2.8.2, I don't see > how it can detect *.png like you mentioned, or detect the list of slices from > the filenames. Am I right on this ? It doesn't need to detect the image file type, it just passes the filename to readImageFile() and it's does the reading via the OSG's normal plugin mechanism. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi, Sorry for the simple question... I am trying to load a list of images using the --images flag. Looking at the osgvolume.cpp code in 2.8.2, I don't see how it can detect *.png like you mentioned, or detect the list of slices from the filenames. Am I right on this ? Thank you! Cheers, Guillaume -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16341#16341 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Paul, On Fri, Jan 30, 2009 at 12:55 PM, Paul Melis wrote: > BTW, is there currently support in osgVolume for interactively manipulating > a transfer function? I haven't tried it yet, but it should work automatically. osg::TransferFunction1D holds an osg::Image that it should update and dirty, and this osg::Image is attached to a convention texture which should in theory just update when the image is updated. > I noticed the call to osgVolume::applyTransferFunction() in the osgvolume > example and that one kind of feels like it does processing on the image > data. Is that correct? You can apply the transfer function directly to the image, but with GPU based shaders I've found it best to do all the compute of the transfer function on the GPU, it's faster and produces high quality results and... you can update the transfer function dynamically. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Paul et. al, On Wed, Jan 28, 2009 at 3:49 PM, Robert Osfield wrote: > I recall that perhaps I didn't wire up the old command line options to > the new property switch... I will go and investigate once I've > completed work on other issues I'm trying to resolve. To osgvolume I've now added the setting of the default rendering property according to whether the --light, --isosurface and --mip are used. Unfortunately I check it in right now as the server is down :-| I have been testing the transfer function support are confirm that it is indeed broken right now, it looks like changes to osgVolume::Property graph traversal has introduced this regression. It's likely to be a single line fix, but which line is the question!!! Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Gerrick Bivins wrote: Perhaps you mean the dicom data dictionary? http://www.mevis-research.de/~meyer/dcmtk/docs_352/dcmdata/datadict.txt Yes, you're right. I remembered having to set the DCMDICTPATH before the files even loaded, but I think there was also another problem. Will have to check at home. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi guys, Perhaps you mean the dicom data dictionary? http://www.mevis-research.de/~meyer/dcmtk/docs_352/dcmdata/datadict.txt On Mac I had to point to the installed dictionary file: export DCMDICTPATH=/opt/local/lib/dicom.dic Otherwise I'd receive an error like this: "Error in reading dicom file /Users/gbivins/work/APIs/OpenSceneGraph-Data/CardiacCT, error = No data dictionary No model loaded, please specify and volumetric image file on the command line.." biv On 1/28/09 10:00 AM, "Robert Osfield" wrote: > Hi Paul, > > On Wed, Jan 28, 2009 at 3:53 PM, Paul Melis wrote: >> Yes, the input actually is a set of DICOM files but OSG fails on reading >> these as there is no DICOMDIR file and creating that one with a tool in >> DCMTK also fails. So I converted them to PNG files. > > I haven't come across needing a DICOMDIR file. Exactly what would this file > be? > > Do you have links to your datasets? > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Paul, On Wed, Jan 28, 2009 at 3:53 PM, Paul Melis wrote: > Yes, the input actually is a set of DICOM files but OSG fails on reading > these as there is no DICOMDIR file and creating that one with a tool in > DCMTK also fails. So I converted them to PNG files. I haven't come across needing a DICOMDIR file. Exactly what would this file be? Do you have links to your datasets? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Robert Osfield wrote: Hi Paul, On Wed, Jan 28, 2009 at 3:31 PM, Paul Melis wrote: Ok, good to hear. The 8-bit files I tried seem to work fine, but there seems to be some problem with 16-bit png files that don't get read in correctly. I'll see if I can dig deeper in the near future. Are building the data of an stack of images? This would suggest that either the code that places all the 2d images into a 3d image is broken, or the png plugin is broken in some way. Yes, the input actually is a set of DICOM files but OSG fails on reading these as there is no DICOMDIR file and creating that one with a tool in DCMTK also fails. So I converted them to PNG files. osgvolume --cpu-tf --tf file.tf dataset.dds Does it work without the --cpu-tf? No, that's what I meant in my previous post. BTW, the --mip/--isosurface/--light flags are currently not functional it seems? Actually by default there should all being working as the code creates a ProprtySwitch that allows you to switch between different sets of volume rendering properties. Pressing 'v' in osgvolume to cycle between the various properties. Yes, that works, great! I recall that perhaps I didn't wire up the old command line options to the new property switch... I will go and investigate once I've completed work on other issues I'm trying to resolve. Ok Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Paul, On Wed, Jan 28, 2009 at 3:31 PM, Paul Melis wrote: > Ok, good to hear. The 8-bit files I tried seem to work fine, but there seems > to be some problem with 16-bit png files that don't get read in correctly. > I'll see if I can dig deeper in the near future. Are building the data of an stack of images? This would suggest that either the code that places all the 2d images into a 3d image is broken, or the png plugin is broken in some way. > osgvolume --cpu-tf --tf file.tf dataset.dds Does it work without the --cpu-tf? > BTW, the --mip/--isosurface/--light flags are currently not functional it > seems? Actually by default there should all being working as the code creates a ProprtySwitch that allows you to switch between different sets of volume rendering properties. Pressing 'v' in osgvolume to cycle between the various properties. I recall that perhaps I didn't wire up the old command line options to the new property switch... I will go and investigate once I've completed work on other issues I'm trying to resolve. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Robert,
Robert Osfield wrote:
On Wed, Jan 28, 2009 at 3:07 PM, Paul Melis wrote:
Robert Osfield wrote:
The osgvolume example supports reading a file containing a transfer
function. Am I correct in assuming this file must have the format
where the color values are in the range [0-1]?
This is correct, here's an example of a simple little transfer
function that I put together for testing.
00 0 0 0
0.15 1 0 0 0.2
0.2 0 1 0 0.3
0.35 0 1 1 0.4
0.6 1 1 1 0.8
11 1 1 1
Ah! The scalar value range is also mapped onto [0-1], I didn't expect
that. I was using values in the range [0-255]. Now I indeed get things
more in line with what I expect.
It also seems that you must
use --cpu-tf in order for the transfer function to actually get used, but
I'm still not getting the results I expect (compared to other volume
rendering packages).
No, you should be able to use the GPU for transfer functions - this is
supported already, the shaders are available and built into osgVolume.
You get the best visual quality by doing the transfer function down
on the GPU as well as it works at higher precision than the CPU based
conversion which drops you down to RGBA8.
Without the --cpu-tf flag the transfer function isn't used, as per
osgvolume.cpp (line 1217):
if (!gpuTransferFunction && transferFunction.valid())
{
for(Images::iterator itr = images.begin();
itr != images.end();
++itr)
{
*itr = osgVolume::applyTransferFunction(itr->get(),
transferFunction.get());
}
}
What are the current requirements on the data in
VolumeTiles, only 8-bit?
You can use any precision you want. Most of the dicom files I've been
testing against are 16bit, and this certainly produces better results
than 8bit data sets.
Ok, good to hear. The 8-bit files I tried seem to work fine, but there
seems to be some problem with 16-bit png files that don't get read in
correctly.
I'll see if I can dig deeper in the near future.
I wonder if it's how you are setting up osgvolume that is the problem.
Could you give an example of the osgvolume command line you are
using, as well as links to the data.
osgvolume --cpu-tf --tf file.tf dataset.dds
BTW, the --mip/--isosurface/--light flags are currently not functional
it seems?
Regards,
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Paul, On Wed, Jan 28, 2009 at 3:07 PM, Paul Melis wrote: > Robert Osfield wrote: > The osgvolume example supports reading a file containing a transfer > function. Am I correct in assuming this file must have the format > > where the color values are in the range [0-1]? This is correct, here's an example of a simple little transfer function that I put together for testing. 00 0 0 0 0.15 1 0 0 0.2 0.2 0 1 0 0.3 0.35 0 1 1 0.4 0.6 1 1 1 0.8 11 1 1 1 > It also seems that you must > use --cpu-tf in order for the transfer function to actually get used, but > I'm still not getting the results I expect (compared to other volume > rendering packages). No, you should be able to use the GPU for transfer functions - this is supported already, the shaders are available and built into osgVolume. You get the best visual quality by doing the transfer function down on the GPU as well as it works at higher precision than the CPU based conversion which drops you down to RGBA8. > What are the current requirements on the data in > VolumeTiles, only 8-bit? You can use any precision you want. Most of the dicom files I've been testing against are 16bit, and this certainly produces better results than 8bit data sets. I wonder if it's how you are setting up osgvolume that is the problem. Could you give an example of the osgvolume command line you are using, as well as links to the data. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Robert Osfield wrote: Hi All, Over the last ten days I've been pulling together parts of my work on volume rendering to create a usable osgVolume NodeKit. The osgVolume NodeKit is still in it's infancy, but should be have enough features for end users to start trying it out. This rev of osgVolume will be the base for the next stable OSG-2.8 release, and should provide the basic framework for us to start building on more advanced and scalable features once 2.8 is out the door. The basic ideas behind osgVolume is that a osgVolume::Volume group node decorates all the tiles in a volume, the tiles are represented by osgVolume::VolumeTile nodes that are non-intersecting bricks. Each tile has an its imagery associated with it attached via an osgVolume::Layer, this might be a CompositeLayer if you have multiple attributes, or a single ImageLayer. The layers and tiles are located in space via osgVolume::Locator which is a effectively 4x4 transform matrix that positions the local 0,0,0 to 1,1,1 coords of the tile or layer into the 3D model coords. How the basic rendering algoirithm used to render tiles is provided the VolumeTechnique that is attached to the VolumeTile, currently there is the FixedFunctionTechnique and RayTracedTechnique, and rendering hints/options within these techniques are controlled via osgVolume::Property objects that are attached the the imagery layers. The number of classes at play may at first seem a bit bewildering, but hopefully one you start diving into code it'll become obvious how they all fit together. The classes have been put together to make it possible to extend osgVolume to handling lots of custom rendering techniques, and also to scale the size of imagery that we can tackle. For instance it should be possible with this NodeKit to build paged volumes leveraging osgVolume::VolumeTile coupled with PagedLOD, much in the same way that you can built paged terrain databases that couple osgTerrain::TerrainTile with PagedLOD. -- osgVolume features that are now checked into svn/trunk are: Dicom loader (DCMTK or ITK based) Support for non power of two textures + compressed textures. Support for 4D texture via osg::ImageSequence Support for rendering techniques (selected by osgVolume::Properties + osgVolume::VolumeTechnique ) : osgVolume::FixedFunctionTechnique : basic fixed function path, screen aligned image stack, with alpha function support for clipping out fragments. osgVolume::RayTracedTechnique : ray tracing using GLSL shaders: support for transfer functions with ability to either do pre-computed or computed in shaders basic intensity rendering + with alpha function support for clipping out fragments. lit intensity rendering + with alpha function support for clipping out fragments. lit iso surface rendering (value controllable interactively) maximum image project rendering + with alpha function support for clipping out fragments. Support for properties switch for switching between different properties/rendering techniques. Support for interactively adjusting iso surface values, transparency, sample density and alpha function, and switching of properties via event callback that can be attached to the volume tiles. The osgvolume example illustrates how to set up osgVolume::Volume + VolumeTile nodes, along with selection of the osgVolume::Property objects that inform the rendering backend what type of rendering is required -- Features not yet included: Features that aren't included yet is support for mixing polygonal models with the ray traced volumes, and handling of multiple intersecting volume image layers. The osgVolume class design will support both these key features but right now the shaders aren't in place to support these rendering techniques. Also not tackled yet is tiling of the volume, again the class design does support this, but I haven't yet attempted building a volume from many tiles - currently I've just focused on a volume containing a single tile. I have lots of ideas in this direction so if you're interested I can expand. The osgvolume example supports reading a file containing a transfer function. Am I correct in assuming this file must have the format where the color values are in the range [0-1]? It also seems that you must use --cpu-tf in order for the transfer function to actually get used, but I'm still not getting the results I expect (compared to other volume rendering packages). What are the current requirements on the data in VolumeTiles, only 8-bit? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
HI Richard, On Wed, Jan 21, 2009 at 4:02 PM, Schmidt, Richard wrote: > Is related to > > http://www.gamedev.net/community/forums/topic.asp?topic_id=516446 No it's not related. > Can one implement a sparse voxel octree using osgVolume? You might want to use a custom Node rather than osgVolume to do such an specific algorithm, although perhaps a custom VolumeTechnique might be able to do it. I don't really know enough about the specifics of this algorithm to provide any concrete assessment though. There will be ways of building an octree of VolumeTile's that could be a sparse, but this would be a scene graph level optimization rather a GPU level one. The scene graph level approach would be one that is likely to scale better as you'd be able leverage the OSG's support for database paging. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi JS, On Wed, Jan 21, 2009 at 3:49 PM, Jean-Sébastien Guay wrote: > Congrats on getting all this work on osgVolume done! Thanks. I have to admit it''s not quite "done" yet though, enough for 2.8, but still plenty fun left in developing it further :-) > Even though I don't work with volume rendering, I've always liked looking at > examples of it. I'd be interested in trying out the example, but I'm > wondering: > > a) do you have any example files I could use to see it in action? I have plenty of example files I've pulled down from the net. I don't have any that I own myself to pass on though. I'm in a bit of rush right now, but once the dust has settled I'll put up a page on the wiki that provides pointers to various files. > b) would I need to build the Dicom loader to load these files, or do you > have some files that wouldn't need this loader? No, the dicom load is only required if you want to use dicom image files. osgVolume/osgvolume just use the standard osg::Image class for representing the volume data so you can read these from 3D .dds or dicom files, or just build up the 3D image from 2S slices. > c) what are the command lines to use for testing? There are quite a few options, mainly associated with different ways of loading data. To load a dicom image (which is typically a directory containing a series of 2D dicom images) osgvolume mydicomdirectory Or to load a series of png files as a single 3D image: osgvolume --images *.png To get full list of options: osgvolume --help Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Robert, Sounds great. I have never done any volume rendering stuff - but you mentioned gpu raytraying. Is related to http://www.gamedev.net/community/forums/topic.asp?topic_id=516446 Can one implement a sparse voxel octree using osgVolume? Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Robert, Congrats on getting all this work on osgVolume done! To test out osgVolume you'll need to grab OpenSceneGraph and OpenSceneGraph-Data (for shaders) from svn/trunk. I'll be tagging 2.7.9 very soon, so it'll be in this, and obviously the up coming stable 2.8 release, but I've very much appreciate testing and feedback prior to making releases so I can make any required improvements in time for the stable release. Even though I don't work with volume rendering, I've always liked looking at examples of it. I'd be interested in trying out the example, but I'm wondering: a) do you have any example files I could use to see it in action? b) would I need to build the Dicom loader to load these files, or do you have some files that wouldn't need this loader? c) what are the command lines to use for testing? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Paul, On Wed, Jan 21, 2009 at 3:05 PM, Paul Melis wrote: >> Dicom loader (DCMTK or ITK based) >> > > I think I saw you mention at one point that GDCM might also be included as a > loader? The reason I ask is that ITK is a fairly large dependency, while > DCMTK doesn't seem to be developed anymore (the latest release I know of is > from 2005), while GDCM is actively developed. Or does ITK use GDCM under the > hood? Other members of the community suggested GDCM as an option, and I briefly looked at it, but having already written the ITK path, and most of the DCMTK path I stuck with the later routes rather than take on another implemented. Others are welcome to dive in an implement a GDCM plugin. > What's the requirements for all these features in terms of GPU being used? I > tried a previous version from SVN some time ago and got an error during > shader compilation that my card (FX5200) doesn't support while loops. Good question, GLSL support is essential for any sensible volume rendering, the FixedFunctionTechnique fallback is very basic, and I have no plans on trying to emulate the advanced techniques possible with a pure GLSL path. Within GLSL there are obviously different capabilities w.r.t drivers and hardware, and I must admit I haven't spent time considering how to manage these differences. You might be able to rewrite the shaders to make them more backwards compatible and still retain the existing functionality, or it might be necessary to implement another VolumeTechnique that supports the cards that have GLSL, but not the full capabilities of more modern cards. I'm open to suggestions. For a point of reference I've been developing against Geforce 6 series upwards. > This is fantastic work! I've been doing volume rendering mostly with VTK, > but VTK is really hard to integrate with other rendering packages (e.g. OSG) > as its use of OpenGL is spaghetti-strewn throughout its classes and there's > no clean encapsulation of OpenGL state. If the OSG volume rendering manages > to approach the VTK level (which shouldn't be that hard) we would have a > nice alternative. Integration with existing scene graph is pretty straight forward - just add a VolumeTile to the scene graph with the appropriate Locator/Layer/Properties/Technique attached an it'll automatically rendering the volume. No custom OpenGL paths are used, the VolumeTechniques that have been implemented so far both use standard scene graph elements to set up state and rendering primitives, this ensures that it'll play nice with the rest of the OSG. I don't expect future volume rendering techniques to require any custom OpenGL paths either as we already have vertex, geometry and fragment shaders built into the core OSG. It shouldn't be too difficult to integrate ITK with osgVolume, as ITK allows you to adapt external representations of imagery both in and out of ITK. There is an example of this in the dicom plugin's ITK code path. One possibility would be to provide some glue classes in the include/osgVolume header directory to facilitate integration, this would have to be done entirely in the header though as I don't want to add any external dependencies to osgVolume - it's a pure OSG based solution so is easy to port and maintain. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Hi Robert, Robert Osfield wrote: Over the last ten days I've been pulling together parts of my work on volume rendering to create a usable osgVolume NodeKit. The osgVolume NodeKit is still in it's infancy, but should be have enough features for end users to start trying it out. This rev of osgVolume will be the base for the next stable OSG-2.8 release, and should provide the basic framework for us to start building on more advanced and scalable features once 2.8 is out the door. The basic ideas behind osgVolume is that a osgVolume::Volume group node decorates all the tiles in a volume, the tiles are represented by osgVolume::VolumeTile nodes that are non-intersecting bricks. Each tile has an its imagery associated with it attached via an osgVolume::Layer, this might be a CompositeLayer if you have multiple attributes, or a single ImageLayer. The layers and tiles are located in space via osgVolume::Locator which is a effectively 4x4 transform matrix that positions the local 0,0,0 to 1,1,1 coords of the tile or layer into the 3D model coords. How the basic rendering algoirithm used to render tiles is provided the VolumeTechnique that is attached to the VolumeTile, currently there is the FixedFunctionTechnique and RayTracedTechnique, and rendering hints/options within these techniques are controlled via osgVolume::Property objects that are attached the the imagery layers. Nice! I just quickly tried to digest the above, but it sounds like a sensible way of organizing the concepts involved. The number of classes at play may at first seem a bit bewildering, but hopefully one you start diving into code it'll become obvious how they all fit together. The classes have been put together to make it possible to extend osgVolume to handling lots of custom rendering techniques, and also to scale the size of imagery that we can tackle. For instance it should be possible with this NodeKit to build paged volumes leveraging osgVolume::VolumeTile coupled with PagedLOD, much in the same way that you can built paged terrain databases that couple osgTerrain::TerrainTile with PagedLOD. -- osgVolume features that are now checked into svn/trunk are: Dicom loader (DCMTK or ITK based) I think I saw you mention at one point that GDCM might also be included as a loader? The reason I ask is that ITK is a fairly large dependency, while DCMTK doesn't seem to be developed anymore (the latest release I know of is from 2005), while GDCM is actively developed. Or does ITK use GDCM under the hood? Support for non power of two textures + compressed textures. Support for 4D texture via osg::ImageSequence Support for rendering techniques (selected by osgVolume::Properties + osgVolume::VolumeTechnique ) : osgVolume::FixedFunctionTechnique : basic fixed function path, screen aligned image stack, with alpha function support for clipping out fragments. osgVolume::RayTracedTechnique : ray tracing using GLSL shaders: support for transfer functions with ability to either do pre-computed or computed in shaders basic intensity rendering + with alpha function support for clipping out fragments. lit intensity rendering + with alpha function support for clipping out fragments. lit iso surface rendering (value controllable interactively) maximum image project rendering + with alpha function support for clipping out fragments. Support for properties switch for switching between different properties/rendering techniques. Support for interactively adjusting iso surface values, transparency, sample density and alpha function, and switching of properties via event callback that can be attached to the volume tiles. What's the requirements for all these features in terms of GPU being used? I tried a previous version from SVN some time ago and got an error during shader compilation that my card (FX5200) doesn't support while loops. The osgvolume example illustrates how to set up osgVolume::Volume + VolumeTile nodes, along with selection of the osgVolume::Property objects that inform the rendering backend what type of rendering is required -- Features not yet included: Features that aren't included yet is support for mixing polygonal models with the ray traced volumes, and handling of multiple intersecting volume image layers. The osgVolume class design will support both these key features but right now the shaders aren't in place to support these rendering techniques. Also not tackled yet is tiling of the volume, again the class design does support this, but I haven't yet attempted building a volume from many tiles - currently I've just focused on a volume containing a single tile. I have lots of ideas in this direction so if you're interested I can expand. -- Ready for testing an feedback! This is fantastic work! I've been doing volume rendering mostly with VTK, but VTK is really hard to integrate w
[osg-users] osgVolume ready for testing
Hi All, Over the last ten days I've been pulling together parts of my work on volume rendering to create a usable osgVolume NodeKit. The osgVolume NodeKit is still in it's infancy, but should be have enough features for end users to start trying it out. This rev of osgVolume will be the base for the next stable OSG-2.8 release, and should provide the basic framework for us to start building on more advanced and scalable features once 2.8 is out the door. The basic ideas behind osgVolume is that a osgVolume::Volume group node decorates all the tiles in a volume, the tiles are represented by osgVolume::VolumeTile nodes that are non-intersecting bricks. Each tile has an its imagery associated with it attached via an osgVolume::Layer, this might be a CompositeLayer if you have multiple attributes, or a single ImageLayer. The layers and tiles are located in space via osgVolume::Locator which is a effectively 4x4 transform matrix that positions the local 0,0,0 to 1,1,1 coords of the tile or layer into the 3D model coords. How the basic rendering algoirithm used to render tiles is provided the VolumeTechnique that is attached to the VolumeTile, currently there is the FixedFunctionTechnique and RayTracedTechnique, and rendering hints/options within these techniques are controlled via osgVolume::Property objects that are attached the the imagery layers. The number of classes at play may at first seem a bit bewildering, but hopefully one you start diving into code it'll become obvious how they all fit together. The classes have been put together to make it possible to extend osgVolume to handling lots of custom rendering techniques, and also to scale the size of imagery that we can tackle. For instance it should be possible with this NodeKit to build paged volumes leveraging osgVolume::VolumeTile coupled with PagedLOD, much in the same way that you can built paged terrain databases that couple osgTerrain::TerrainTile with PagedLOD. -- osgVolume features that are now checked into svn/trunk are: Dicom loader (DCMTK or ITK based) Support for non power of two textures + compressed textures. Support for 4D texture via osg::ImageSequence Support for rendering techniques (selected by osgVolume::Properties + osgVolume::VolumeTechnique ) : osgVolume::FixedFunctionTechnique : basic fixed function path, screen aligned image stack, with alpha function support for clipping out fragments. osgVolume::RayTracedTechnique : ray tracing using GLSL shaders: support for transfer functions with ability to either do pre-computed or computed in shaders basic intensity rendering + with alpha function support for clipping out fragments. lit intensity rendering + with alpha function support for clipping out fragments. lit iso surface rendering (value controllable interactively) maximum image project rendering + with alpha function support for clipping out fragments. Support for properties switch for switching between different properties/rendering techniques. Support for interactively adjusting iso surface values, transparency, sample density and alpha function, and switching of properties via event callback that can be attached to the volume tiles. The osgvolume example illustrates how to set up osgVolume::Volume + VolumeTile nodes, along with selection of the osgVolume::Property objects that inform the rendering backend what type of rendering is required -- Features not yet included: Features that aren't included yet is support for mixing polygonal models with the ray traced volumes, and handling of multiple intersecting volume image layers. The osgVolume class design will support both these key features but right now the shaders aren't in place to support these rendering techniques. Also not tackled yet is tiling of the volume, again the class design does support this, but I haven't yet attempted building a volume from many tiles - currently I've just focused on a volume containing a single tile. I have lots of ideas in this direction so if you're interested I can expand. -- Ready for testing an feedback! To test out osgVolume you'll need to grab OpenSceneGraph and OpenSceneGraph-Data (for shaders) from svn/trunk. I'll be tagging 2.7.9 very soon, so it'll be in this, and obviously the up coming stable 2.8 release, but I've very much appreciate testing and feedback prior to making releases so I can make any required improvements in time for the stable release. Good luck, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
