This repository was archived by the owner on Jul 8, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 8, 2022. It is now read-only.
Statistics are showing wrong resolution(um/voxel) #294
Description
In channel.cpp (at line 392) the calculation:
"Vector3f voxelSize = info.boundingBox.getSize() / info.voxels"
is wrong.
info.boundingBox.getSize() is the bounding box of the circuit but in Livre we are adding a cutoff
distance to this bounding box. So the number of voxels is too big.
Activity
bilgili commentedon May 31, 2016
This is not "wrong", this is "invalid" for Fivox data source only. Cutoff distance is only meaningful for this data source. We have to think about this carefully.
chevtche commentedon Jun 30, 2016
resolution in um/voxel is only used in Fivox. I don't think it's used for any other datasource??
bilgili commentedon Jun 30, 2016
what is to do with cutoff distance :)
chevtche commentedon Jun 30, 2016
Because now our total bounding box is equal to the circuit bounding box + 2 * cutoff distance.
bilgili commentedon Jun 30, 2016
But, what is to do with Livre :) Livre does not have a context for cutoff distance. This problem is related to Fivox to seperate cutoff distance from volume size !
chevtche commentedon Jun 30, 2016
Livre has nothing to do with resolution values like ( um/voxel ) it's a pure Fivox stuff...
It's why we can just remove this statistic.
bilgili commentedon Jun 30, 2016
ok with that :)
eile commentedon Jul 1, 2016
Not ok with that. Livre does (and has to) know resolution values. It is not only for the overlay, but more importantly for the camera synchronization.
bilgili commentedon Jul 1, 2016
Through data source, yes. But the report over there is pure wrong. It is only valid for some use cases. The synchronization of reference frames between applications is not present since we have concentrated on camera only.
eile commentedon Jul 1, 2016
"pure wrong" is a string statement. It's useful for data sources which have a real-world size. Maybe it should not be printed for the ones which don't.
I don't get 'reference frames'? The ZeroEQ lookout is defined in meters, therefore the real-world size is important. We can assume a default unit meter cube for the undefined ones.
bilgili commentedon Jul 1, 2016
I am wrong, you are right. Re-checking the code, I have mixed it with worldSize. I thought it was the normalized space, but we have a separate value for defining the space. If it was the normalized space it would be wrong. I mean by the reference frame this one.
chevtche commentedon Jul 4, 2016
Ok, to summarize the problems I found:
info.boundingBox is the bounding box of the circuit. It is needed for camera synchronization and
only for that currently.
info.voxels is the total number of voxels ( with the ones added by the cutoff distance ). It
doesn't match the info.boundingBox. Because of that, info.boundingBox.getSize() / info.voxels doesn't
always give us the right resolution.
This resolution information is only valid for some DataSources like BBIC and
Fivox. MemoryDataSource, UVF and Cubist don't provide any "real world" measurements.
Assuming anything for a dataSource like UVF is just wrong (a vein with 2m radius?).
What do we want to show exactly? The printed resolution is actually the maximum
possible resolution and not the current one. Livre using out of core LODs, blocks with
different resolution are loaded at the same time.
For me it seems that the right thing to do is to add a Vector3f resolution field in the VolumeInformation class and initialize it to some negative values. If a data source provide this information, we show it, if not we don't show anything.
eile commentedon Jul 4, 2016
chevtche commentedon Jul 4, 2016
2)"This can't be wrong, as you are doing it already in any case". We are not doing that... The only
thingy that can be computed is the meters per livre unit. For that we need a valid data bounding box
provided by Brion (or BBIC ?). UVF, memory and Cubist datasources are totally "real world" unit agnostic.
"Livre scales everything to be in meters" I don't understand this statement. Livre itself is "real world" unit agnostic. The resolution printing is the only place where "real world" units are used. Even during
the camera synchronization the "real world" unit will simplify because we are interested in a ratio only.
Ahmet told me that UVF doesn't have the required information. And for the UVF it will be very wrong to assume anything. If we use as a default 1m cube and look at a human cell volume, the resolution print will tell to the user that the cell is 1 meter big. What is the point to lie like that? It can only confuse people IMHO...
eile commentedon Jul 4, 2016
When running Livre in a VR setting, the user sees data at a certain scale. Today all data is scaled to be two meters.
um/voxel says how many um a voxel is? What do you have in mind?
chevtche commentedon Jul 4, 2016
After a discussion with Juan, Daniel and Jafet, we agreed that the best solution will be to compute the transformation matrix between data and application spaces in the datasource and use it to multiply the camera.
chevtche commentedon Jul 4, 2016