iv3d-users

Text archives Help


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


Chronological Thread 
  • From: alaa Alzabi <am082842@gmail.com>
  • To: iv3d-users@sci.utah.edu
  • Subject: Re: [IV3D-USERS] Implementing a Reader Parallel to UVF
  • Date: Mon, 16 Jun 2014 13:53:52 +0300
I can see you both conservation and I don’t know why

On Jun 16, 2014, at 1:52 PM, Mathieu Malaterre <mathieu.malaterre@gmail.com>
wrote:

> Hi Tom,
>
> 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 ?
>
>> 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.
>
>>
>>> - 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.
>
>> I could verify if you turned on messages/warnings/errors and sent us a
>> debug
>> log.
>
> Ah good point. I'll use that next time.
>
>>
>>> - 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.
>
>>
>>> - GetDomainSize() only returns for ts=0 / lod=0 a domain of (64,64,42)
>>> and assert(0) for any other one (called only when I zoom in).
>>
>>
>> you could probably return the voxel sizes from the other LODs and be fine.
>
> Ok will do that next.
>
>>
>>> - 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;
>
>
>> 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.
>
>>
>>> - MaxGradientMagnitude() returns for now:
>>> -std::numeric_limits<float>::max() (could not figure out a decent
>>> default implementation).
>>
>>
>> This probably ends up being used in scaling calculations for doing proper
>> lighting. To remove it from the equation for now, I would just turn
>> lighting off after you load your volume.
>
> Ok make sense.
>
>>
>>> And upon construction I am doing:
>>>
>>> // cstor
>>> {
>>> m_pHist1D.reset();
>>> m_pHist1D.reset(new Histogram1D(
>>> std::min(MAX_TRANSFERFUNCTION_SIZE, 1<<GetBitWidth())));
>>> for (size_t i = 0;i<m_pHist1D->GetSize();i++) {
>>> m_pHist1D->Set(i, 1);
>>> }
>>> m_pHist2D.reset();
>>> VECTOR2<size_t> vec(256, std::min(MAX_TRANSFERFUNCTION_SIZE,
>>> 1<<GetBitWidth()));
>>> m_pHist2D.reset(new Histogram2D(vec));
>>> for (size_t y=0; y < m_pHist2D->GetSize().y; y++) {
>>> for (size_t x=0; x < m_pHist2D->GetSize().x; x++) {
>>> m_pHist2D->Set(x,y,1);
>>> }
>>> }
>>>
>>> // add two bricks
>>> {
>>> BrickMD bmd;
>>> FLOATVECTOR3 vBrickExtents(64,64,42);
>>> UINTVECTOR3 vBrickVector(64,64,42);
>>>
>>> bmd.extents = vBrickExtents;
>>>
>>> FLOATVECTOR3 vBrickCorner(32,32,21);
>>> bmd.center = vBrickCorner;
>>> bmd.n_voxels = vBrickVector;
>>>
>>> const BrickKey k = BrickKey(0, 0, 0);
>>> AddBrick(k, bmd);
>>> }
>>> {
>>> BrickMD bmd;
>>> FLOATVECTOR3 vBrickExtents(512,512,336);
>>> UINTVECTOR3 vBrickVector(512,512,336);
>>>
>>> bmd.extents = vBrickExtents;
>>>
>>> FLOATVECTOR3 vBrickCorner(256,256,168);
>>> bmd.center = vBrickCorner;
>>> bmd.n_voxels = vBrickVector;
>>>
>>> const BrickKey k = BrickKey(0, 4, 0);
>>> AddBrick(k, bmd);
>>> }
>>> }
>>
>>
>> If you have 4 LODs, you should add a minimum of 4 bricks. But I think it
>> would give you an empty (as opposed to white) volume if that was the case.
>
> Ok.
>
>> 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.
>
>>
>>> This is were I am at now. Any suggestion how to diagnose what the
>>> issue could be would be very much appreciated.
>>
>>
>> "Simplify data management" is a laudable goal, but the parallel reader
>> stuff
>> was originally designed around the "my data are too large to convert to
>> UVF"
>> use case. Terabytes, for example.
>>
>> A lot of the mechanisms for IV3D performing well are based around some
>> guarantees---16bit or smaller data, for example---that your situation does
>> not seem to hit.
>>
>> 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).
>
> Thanks for your help (again!).


Archive powered by MHonArc 2.6.18.

Top of page