iv3d-users

Text archives Help


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


Chronological Thread 
  • From: Mathieu Malaterre <mathieu.malaterre@gmail.com>
  • To: iv3d-users@sci.utah.edu
  • Subject: Re: [IV3D-USERS] Implementing a Reader Parallel to UVF
  • Date: Wed, 18 Jun 2014 11:13:03 +0200
Tom,

On Mon, Jun 16, 2014 at 3:01 PM, tom fogal <tfogal@sci.utah.edu> wrote:
> 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.

I do not know if I'll be able to fix it, but since I need it I may
tweak the code to see how it goes. What should I be starring at ?

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

I am not sure I understand what you mean. Should I be reading
DynamicBrickingDS.cpp instead of uvfDataset.cpp to implement my own
reader ?
I can generate pertty much any brick size (power of 2 are much
easier). So I was thinking to generate only on-demand brick size which
match the current user setting (Edit>Settings>UVF File
Parameters>Bricksize).

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


I do get a nice volume rendering of lod=0 (ts=0), but now even if I
zoom nothing else gets called. However I did declare to have multiple
LOD:

unsigned MF3::GetLODLevelCount() const
{
return 4;
}

and constructor appends 4 of them (dummy implementation for now):

[...]
{
BrickMD bmd;
FLOATVECTOR3 vBrickExtents(1.0,1.0,1.0); // world coordinate
FLOATVECTOR3 vBrickCenter(0.5,0.5,0.5); // world coordinate
UINTVECTOR3 vBrickVector(64,64,42); // num of pixels

bmd.extents = vBrickExtents;
bmd.center = vBrickCenter;
bmd.n_voxels = vBrickVector;

const BrickKey k = BrickKey(0, 0, 0);
AddBrick(k, bmd);
}
{
BrickMD bmd;
FLOATVECTOR3 vBrickExtents(1.0,1.0,1.0); // world coordinate
FLOATVECTOR3 vBrickCenter(0.5,0.5,0.5); // world coordinate
UINTVECTOR3 vBrickVector(128,128,84);

bmd.extents = vBrickExtents;
bmd.center = vBrickCenter;
bmd.n_voxels = vBrickVector;

const BrickKey k = BrickKey(0, 1, 0);
AddBrick(k, bmd);
}
{
BrickMD bmd;
FLOATVECTOR3 vBrickExtents(1.0,1.0,1.0); // world coordinate
FLOATVECTOR3 vBrickCenter(0.5,0.5,0.5); // world coordinate
UINTVECTOR3 vBrickVector(256,256,168);

bmd.extents = vBrickExtents;
bmd.center = vBrickCenter;
bmd.n_voxels = vBrickVector;

const BrickKey k = BrickKey(0, 2, 0);
AddBrick(k, bmd);
}
{
BrickMD bmd;
FLOATVECTOR3 vBrickExtents(1.0,1.0,1.0); // world coordinate
FLOATVECTOR3 vBrickCenter(0.5,0.5,0.5); // world coordinate
UINTVECTOR3 vBrickVector(512,512,336);

bmd.extents = vBrickExtents;
bmd.center = vBrickCenter;
bmd.n_voxels = vBrickVector;

const BrickKey k = BrickKey(0, 3, 0);
AddBrick(k, bmd);
}
[...]

Thanks again for comments.

Archive powered by MHonArc 2.6.18.

Top of page