Generates too many fibers about app-afq_no-life HOT 4 CLOSED

according to dan: Life culls anywhere from 70 to 85 percent. Thus you should expect a 3 to 6 x increase.

so I think the numbers are actually ok. it is only a problem if it is finding fibers outside of the tracts.

from app-afq_no-life.

OK> "should expect a 3 to 6 x increase"

The actual size of tracts directory however, is about 30 times larger (68M v.s 2000M). 68M by itself is probably too large to begin with, but 2000M is non-starter.

It seems that not only the number of fibers are greater, but for each fibers it is either much longer, or has more way-points - inflating the size of the tracts.json (coordinates array seems to be x2-x3 times lager)

Do you know this is the case?

life.1.gz
nolife.1.gz

from app-afq_no-life.

this app now subsamples the tracts for the .json files to only include every third streamline. Should be able to visualize now.

from app-afq_no-life.

@kitchell Thanks! It looks like tracts are about 1/3 of original counts.

Before > Right SLF,17314
Now > Right SLF,5888

However, 5888 is still way to high.. at least for my 1-yo laptop (XPS15) with 16G memory / GTX 1050 GPU. It seems to load the page barely, then it crashes...

I believe the subsampling at ever third streamline has another issue, where the tract only has small number of tracts. In such case, we want to display all tracts without subsampling..

Can you update the sampling algorithm so that, it simply grabs the first 1000 tracts, and show all if there are less than 1000 tracts? I believe each tracts are more/less randomly distributed so grabbing the first 1000 tracts (instead of a proper sampling) should not affect how tracts are visualized.. Do you think that will not work?

from app-afq_no-life.