[x3d-public] ImageTexture3D support in x3dom

[Andreas Plesch]

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> 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/X3dNodeInventoryComparis
> on.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 (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
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzma
> n
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171223/3e26b6e1/attachment-0001.html>