[x3d-public] ImageTexture3D support in x3dom

[Leonard Daly]

Andreas,

This touches on an active research area. I found two papers directly 
related to the question:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3043920/
https://www.ncbi.nlm.nih.gov/pubmed/1449870 (abstract only)

Both are 10+ years old, so there may be more recent work someplace else.

This biggest constraint will be the display end of the system. Most 
graphics cards are strictly 8bpp for b/w. Most monitors are not 
calibrated or stable enough to do higher level resolution than that. It 
is possible to get higher (and better, more expensive) equipment, but 
that is only done in specialized environments (like medical imaging).

Requiring standard X3D browsers to handle high-level images would cause 
an production and/or adoption problem. Allowing them to handle the 
higher end images would be reasonable.


Leonard Daly



> Hi Don,
>
> thanks for checking in on the supported nodes list. X3dom recognized 
> ImageTexture3D but it was just a stub without functionality.
>
> For the rendering all props and recognition need to go to Vicomtech, I 
> only added loading of nrrd files.
>
> I noticed that medical image data often have more than 256 levels of 
> intensity, usually 4096. The human eye apparently can distinguish 
> around 800 levels.
>
> Since most display systems can only show 256 levels of grey, 
> interactive windowing of the data range seems be common concept for 
> exploration.
>
> As a graphics standard, should X3D be concerned with how to visualize 
> 12bit grey images/textures ?
>
> For nrrd I currently support 8bit grey and (soon) 24bit rgb 3d images. 
> The practical question is what to do if there is 16bit grey data, a 
> common situation.
>
> One could automatically rescale to 8bit, assuming 12bit range, with a 
> warning.
>
> One could treat as grey plus alpha but this is generally not what is 
> expected.
>
> One could treat as u v and expect a 2d transfer map. A default 
> transfer function could accomplish grey rescaling but custom maps 
> could use color to represent the full dynamic range. But 2d transfer 
> maps may currently not be supported in x3dom.
>
> Hm, so another option would to treat as uint16 and expect 1d transfer 
> function. A 256 pixel long grey ramp would rescale to 8bit but it 
> would be possible to use 4096 colors, cool to hot for example.
>
> It may be time to check what other x3d browsers do.
>
> Happy holidays, Andreas
>
>
>
>
>
>
>
> On Dec 23, 2017 3:49 PM, "Don Brutzman" <brutzman at nps.edu 
> <mailto:brutzman at nps.edu>> wrote:
>
>     Looks like we already had this node included for X3DOM in the
>     inventory spreadsheet.  Further improvements welcome.  Just
>     updated (clearing an Xj3D bug) and online at
>
>     http://www.web3d.org/specifications/X3dNodeInventoryComparison.pdf
>     <http://www.web3d.org/specifications/X3dNodeInventoryComparison.pdf>
>     http://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx
>     <http://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx>
>
>     The example looks tremendous and certainly conveys why we should
>     keep pressing ahead to make X3D sufficiently capable for archiving
>     diagnostic visualizations in medical records.
>
>     Snapshot attached.  Intentionally large in order to show
>     tremendous detail that is possible.  Curiously the skull
>     information is so rich when examining that it was difficult to
>     find a single view that conveyed as much information.
>
>     Thanks for the great work!
>
>
>     On 12/19/2017 3:26 AM, Andreas Plesch wrote:
>
>         One of the many excellent features of x3dom is its extensive
>         volume rendering support, provided by vicomtech. For loading
>         efficiency it uses a special volume texture format, a 2d
>         texture atlas of slices in regular image formats.
>
>         Using tools like image magick it is not too hard to convert an
>         actual raw data volume to such a texture atlas image but I
>         always thought it would be neat to avoid having to do that. I
>         saw now a way to use existing pieces to start implement the
>         standard ImageTexture3D node which can load nrrd, dicom and
>         other (?) formats.
>
>         Focusing on nrrd, here is a first implementation of the
>         ImageTexture3D node:
>
>         https://x3dom-nrrd.glitch.me/index.xhtml
>         <https://x3dom-nrrd.glitch.me/index.xhtml> (for Halloween next
>         year ...)
>
>         I tested with a few nrrd examples and overall it seems to work
>         although I am sure there a few problems left. But the support
>         is good enough that the node may be listed in a table of
>         supported nodes for x3dom, I suspect.
>
>         a peaceful holiday season, Andreas
>
>         -- 
>         Andreas Plesch
>         Waltham, MA 02453
>
>
>     all the best, Don
>     -- 
>     Don Brutzman  Naval Postgraduate School, Code USW/Br
>     brutzman at nps.edu <mailto:brutzman at nps.edu>
>     Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>     +1.831.656.2149 <tel:%2B1.831.656.2149>
>     X3D graphics, virtual worlds, navy robotics
>     http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180101/06c50ec3/attachment.html>