iv3d-users

Text archives Help


Re: [IV3D-USERS] Implementing a Reader Parallel to UVF


Chronological Thread 
  • From: tom fogal <tfogal@sci.utah.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: Re: [IV3D-USERS] Implementing a Reader Parallel to UVF
  • Date: Mon, 16 Jun 2014 15:01:43 +0200
On 06/16/2014 12:52 PM, Mathieu Malaterre wrote:
On Fri, Jun 13, 2014 at 7:45 PM, tom fogal <tfogal@sci.utah.edu> wrote:
On 06/13/2014 12:20 PM, Mathieu Malaterre wrote:
- GetRange(), I used hardcoded values. I did check those are correct
on the whole volume: [-600, 8000]

these are expected to be per-brick ranges. I *think* it should only affect
culling, so you might be okay with making it "too wide" like this.

That's odd because the signature does not take neither `ts` nor `lod`:

virtual std::pair<double,double> GetRange() const = 0;

Are you sure this is meant to be per-brick ?

oops, nope, you're right. I was thinking of:

virtual tuvok::MinMaxBlock MaxMinForKey(const BrickKey&) const;

which, of course, *is* per-brick. sorry.

It's easy to compute with std::minmax_element, though, and with your current
data set sizes that wouldn't be *too* painful.

Ok, will do finer computation. I assume you meant for LOD 0.

correct.

- GetBitWidth() returns 32, as I am dealing with signed integer, and
GetComponentCount() returns 1.

My guess is that this path is broken. For technical (OpenGL) reasons, data
wider than 16bit are hard. There was some code for doing greater-than-16bit
data, long ago, I think under a define of BIAS_SCALE in the GLSL shaders.
However, it was never enabled by default and has likely atrophied.

Using 16 definitely helps here. Thanks much for the quick help.

np.

- GetBrickOverlapSize() returns for now UINTVECTOR3(0,0,0) (is this
correct?)

you tell me ;-) What is called BrickOverlap internally is commonly referred
to as "ghost data" in the literature or even other software. Certainly, if
your bricks have no ghost data, then the (0,0,0) is the correct thing to
return. That said, a volume renderer cannot do proper interpolation at
boundaries without this ghost data, so you'll be able to see the block
boundaries if that is the case.

Ok. I am not very interested in volume rendering for now (mainly the
2x2 MPR view), so 0,0,0 is fine with me. Thanks for the explanation.

oh, you should unfortunately be aware of a long-standing bug in which the slice views only use the coarsest level of detail... :-( apologies.

i don't have time to dig into it right now, but i could show you the code that would need fixing if you'd like to address this.

- GetBrick is a very silly implementation, which does
std::ifstream::read (on LOD 0 file) into the std::vector<uint8_t>
params. reading went ok (.good()), vector was resized to proper actual
file length.

oh, i would have expected a resize() to be necessary.

I am doing a resize here. I took care to multiply by sizeof( sample )
since ouput is stored in vector<uint8_t>. So I have something like:

bool MF3::GetBrick(const BrickKey& bk, std::vector<uint8_t> & vals) const
[...]
const std::string & fn = Internals->Filename;
std::ifstream is( fn.c_str(), std::ios::binary );
const size_t n = 64 * 64 * 42 * sizeof( int16_t );
vals.resize( n );
is.read( (char*)&vals[0], n );
return true;

Okay, yes, this looks correct.

This might depend on
the renderer you use; I think our newer renderer sizes things correctly
before it passes it into GetBrick.

vals was handed to me with a size of 67108864 bytes which did not make
much sense to me... I'am resiz'ing anyway.

exactly as you should.

IIRC the newer renderer tries to avoid allocations, so it starts by resizing the vector to the maximum brick size possible. But this shouldn't be relied upon.

IIRC the default IV3D extents normalizes the data to be within the unit
cube, so extents of e.g. (512,512,336) might cause craziness. I might be
wrong on that. Adding a print and loading a standard UVF would be an easy
way to check me, though. Ditto for the bricks' centers.

For simplification I'll use BrickMD.extents to be 1,1,1 and
BrickMD.center (0.5,0.5,0.5) and try again.

[snip]
I don't want to discourage you---as I said, "simplify data management" is a
laudable goal---but is there a reason that the conversion pipeline isn't
working for you that we could potentially fix?

It does not make much sense to do conversion to me. Opening directly
the data directly is my goal here (you can see my data as some sort of
JPEG 2000 in 3D).

ahh, okay, yeah; that's the core of IV3D's/Tuvok's model. Bricking is an important missing component, though. You might consider a frontend to the DynamicBrickingDS to get around this issue.

.. but that's a concern for later. It wasn't clear if you had things working or just simply 'better'. Are you getting something besides white volumes now?

-tom

Archive powered by MHonArc 2.6.18.

Top of page