<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Andreas,<br>
<br>
This touches on an active research area. I found two papers
directly related to the question:<br>
<a class="moz-txt-link-freetext" href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3043920/">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3043920/</a><br>
<a class="moz-txt-link-freetext" href="https://www.ncbi.nlm.nih.gov/pubmed/1449870">https://www.ncbi.nlm.nih.gov/pubmed/1449870</a> (abstract only)<br>
<br>
Both are 10+ years old, so there may be more recent work someplace
else.<br>
<br>
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). <br>
<br>
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.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67txE66kfxKr+gCrDzz8mv5LwGgZjDG13SLVJnhGk8u0Yg@mail.gmail.com">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a
href="http://faculty.nps.edu/brutzman" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://faculty.nps.edu/brutzma<wbr>n</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>