Text archives Help

---

Hi everyone,

I'm the one guy responsible for implementing the code we are talking about. 
So let me comment on this a little. Obviously, the entire process will be 
O(n) at best as there is nothing we can do about visiting each element at 
least once. So the only thing we can do is tweak the constant time overhead. 
That, however could be reduced significantly, if there is sufficient interest 
(and funding) to this. The issue with the current version of imageVis3D's 
conversion routine is it's generality, ImageVis can really handle crazy data. 
Usually, your data however is not that crazy and a specialized implementation 
could speed up the conversion (in particular for large data sets) by orders 
of magnitude, but it takes time to implement this.

Cheers
   Jens

Am 18.01.2010 um 18:49 schrieb tom fogal:

> Hi Louis,
> 
> Louis Borgeat <louis.borgeat@nrc-cnrc.gc.ca> writes:
>> I have been trying to import a raw volume dataset with imageVis3D.
>> The dataset is a cube of about 10K^3 x 8 bit = ~1TB.
>> The import task was killed after about 10 days due to a power outage,
>> and judging from the variations in temp files sizes, was far from
>> completed.  The machine used has large&fast disk arrays, and plenty
>> of resources.  Is this normal behavior for such a large dataset, or
>> should this have been faster ?
> 
> Unfortunately, as you're seeing, there are some known performance
> issues with the conversion process.  It requires at least two O(n)
> passes over the data, and the bricking stage in particular is not at
> all cache friendly.
> 
>> What is the best/fastest way to import TB-sized datasets into
>> ImageVis3D ?
> 
> We could invest some time into fixing the issues I know about (which
> would be a Good Thing anyway), but realistically bricking a terabyte is
> going to take an absurd amount of time no matter how you slice it.  A
> better approach is to have data that ImageVis3D can read without any
> conversion.
> 
> There are two paths to get there: have your data source write out a
> different format that fits better with IV3D, and modify ImageVis3D's IO
> subsystem to understand your format better.  Attacking the problem on
> both fronts is likely to be a good approach.  While it doesn't directly
> cover this, the PDF I sent to Jim Kress (on this list) over the weekend
> would probably be enlightening.
> 
> The big questions are: 1) do you have someone in your lab that can
> write C++ code, and 2) do you have control over your output format?
> 
> Cheers,
> 
> -tom

---

• [IV3D-USERS] Importing large raw datasets, Louis Borgeat, 01/18/2010
  • [IV3D-USERS] Re: Importing large raw datasets, tom fogal, 01/18/2010
    • [IV3D-USERS] Re: Re: Importing large raw datasets, Jens Krueger, 01/18/2010

---

Archive powered by MHonArc 2.6.16.