[x3d-public] ImageTexture3D support in x3dom

Mon Jan 1 20:43:39 PST 2018

Leonard,

Date: Mon, 1 Jan 2018 17:30:56 -0800
From: Leonard Daly <Leonard.Daly at realism.com>
To: x3d-public at web3d.org
Subject: Re: [x3d-public] ImageTexture3D support in x3dom
Message-ID: <a526830c-7de2-361f-680c-9fa52678553e at realism.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

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.

I got the 800 shades of grey from the first link originally. Medical
display manufacturer s have more recent white papers but they focus on
color which seems essentially an unsolved standardization challenge for the
rigorous medical field.

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).

After looking I found to my surprise that this changed recently (2017) as
hdr displays with 10bit per channel color are now consumer products and
10bit output is generated by professional gpus (and perhaps high end gaming
cards).
OpenGL supports 10bit channels and webGL2 now as well.

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.

This touches on HDR as well as medical imaging.

x3dom is webgl1 . The 1992 abstract claims that compression to 8bit did not
lead gaps in diagnoses, so that would be the easy path for now to deal with
higher fidelity input.

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-0001.html>

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

Message: 3
Date: Mon, 1 Jan 2018 20:32:41 -0500
From: Andreas Plesch <andreasplesch at gmail.com>
To: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] problem in nrrd example file header
Message-ID:
        <CAKdk67vw1KaaE0WeivUwQ8RCO-nhDAz-V_WqaxJLtHndwMz-gA at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

It turns out that

http://savage.nps.edu/Savage/VolumeRendering/datasets/nrrd/
mri_ventricles_segment.nrrd

has the same problem of a malformed header line, eg. an excess space
character in the spacings line.

Here is a corrected nrrd file:

https://cdn.glitch.com/405924cd-3c0d-476e-9b88-
520a5610604c%2Fmri_ventricles_segment_fixed.nrrd?1514854259949

-Andreas

On Mon, Dec 18, 2017 at 4:18 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:
> I am working on ImageTexture3D support for x3dom using the existing
> ImageTextureAtlas node and https://github.com/scijs/nrrd-js as a
> parser.
>
> It turns out the the parser is very strict, and so discovered a
> malformed header line in
> https://savage.nps.edu/Savage/VolumeRendering/datasets/nrrd/
mri_ventricles.nrrd
> used in http://www.web3d.org/x3d/content/examples/Basic/VolumeRendering/
BasicVentriclesIndex.html
>
> Specifically, the header line
> 'spacings:  NaN 0.009 0.009 0.009'
>
> has _two_ space character after the colon delimiter. Exactly _one_
> space is allowed, however, as described here:
>
> http://teem.sourceforge.net/nrrd/format.html#general.2
> second paragraph:
> ... a string "<field>" identifying the field (called the field
> identifier), then a colon followed by a single space ": ", and then
> the information describing the field "<desc>" (called the field
> descriptor) ...
>
> The second space then acts as a separator making the first value in
> the array an empty string which causes throwing when attempting to
> parse as a float.
>
> I made an attempt at fixing the header by removing one space and made
> the file available here:
>
> https://cdn.glitch.com/af228b45-6772-432d-a549-74f9f447b2c3%2Fmri_
ventricles2.nrrd?1513631507711
>
> -Andreas
>
> --
> Andreas Plesch
> Waltham, MA 02453

--
Andreas Plesch
Waltham, MA 02453

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

Subject: Digest Footer

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

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

End of x3d-public Digest, Vol 106, Issue 1
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180101/f9d29f83/attachment-0001.html>