<div dir="auto">Hi Don,<div dir="auto"><br></div><div dir="auto">thanks for checking in on the supported nodes list. X3dom recognized ImageTexture3D but it was just a stub without functionality.</div><div dir="auto"><br></div><div dir="auto">For the rendering all props and recognition need to go to Vicomtech, I only added loading of nrrd files.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Since most display systems can only show 256 levels of grey, interactive windowing of the data range seems be common concept for exploration.</div><div dir="auto"><br></div><div dir="auto">As a graphics standard, should X3D be concerned with how to visualize 12bit grey images/textures ?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">One could automatically rescale to 8bit, assuming 12bit range, with a warning.</div><div dir="auto"><br></div><div dir="auto">One could treat as grey plus alpha but this is generally not what is expected.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">It may be time to check what other x3d browsers do.</div><div dir="auto"><br></div><div dir="auto">Happy holidays, Andreas</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"> </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 23, 2017 3:49 PM, "Don Brutzman" <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<br>
<br>
<a href="http://www.web3d.org/specifications/X3dNodeInventoryComparison.pdf" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dNodeInventoryComparis<wbr>on.pdf</a><br>
<a href="http://www.web3d.org/specifications/X3dNodeInventoryComparison.xlsx" rel="noreferrer" target="_blank">http://www.web3d.org/specifica<wbr>tions/X3dNodeInventoryComparis<wbr>on.xlsx</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks for the great work!<br>
<br>
<br>
On 12/19/2017 3:26 AM, Andreas Plesch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
Focusing on nrrd, here is a first implementation of the ImageTexture3D node:<br>
<br>
<a href="https://x3dom-nrrd.glitch.me/index.xhtml" rel="noreferrer" target="_blank">https://x3dom-nrrd.glitch.me/i<wbr>ndex.xhtml</a> (for Halloween next year ...)<br>
<br>
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.<br>
<br>
a peaceful holiday season, Andreas<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote>
<br>
all the best, Don<br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzma<wbr>n</a><br>
</blockquote></div></div>