-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix inflated number of Z slices in main adult brain template #61
Comments
@Robbie1977 commented: I'm not sure why we went for the inflation rather than resolving the size (may have been a wlz issue in earlier versions) as TAG is handled ok on http://vfbsandbox.inf.ed.ac.uk/site/stacks/tg.htm see https://github.com/VirtualFlyBrain/VFB/blob/Sandbox-Server/data/flybrain/tg/tiledImageModelData.jso as apposed to https://github.com/VirtualFlyBrain/VFB/blob/Dev-Server/data/flybrain/main/tiledImageModelData.jso for the main brain. The only issue with deflating will be this having to be done to all wlz data files - which can be done but is not a quick job. |
Thanks @Robbie1977! Looking at: I don't fully understand the pixel size, which appears to be
My understanding (confirmed once by Arnim Jenett) was that the JFRC template brain (which has always been released uncalibrated, more recently with correction factor of 1.47 for the refractive index mismatch due to the 20x air objective used for imaging) originally had exactly the same spatial calibration as all the other FlyLight images, which have voxel size (0.622088, 0.622088, 1) and was then made isotropic by interpolating in Z to give (0.622088, 0.622088, 0.622088). So I am not sure where the 0.46 comes from. Any ideas @dosumis? |
Those sizes are for the TAG template that is 0.46~ isotopic. Regards, Rob Court On 8 Mar 2014, at 23:55, jefferis notifications@github.com wrote: Thanks @Robbie1977 https://github.com/Robbie1977! Looking at: I don't fully understand the pixel size, which appears to be {"x":"0.4612588", "y":"0.4612588", "z":"0.46", My understanding (confirmed once by Arnim Jenett) was that the JFRC Reply to this email directly or view it on |
No idea I'm afraid. Would have been handled by NM. You could try asking him. |
Apologies both – that was stupid. Lucky I was just commenting not coding at midnight. Anyway the problem remains that the template brain is incorrectly physically calibrated (i.e. 1µm not 0.622µm voxels) and has an inappropriately inflated number of Z slices – I presume as a sort of poor man's fix for the refractive index mismatch correction . My feeling is that the longer we delay any fix the more painful it will be and the extra Z slices make navigation more painful, but of course 1) there is no real use made of the spatial calibration in the viewer at the moment and 2) I won't be the one making that particular fix. |
I’ve got a question outstanding with Bill Hill asking if the system had/has an issue with uneven voxel size, so when we know for definite we could look at a plan to resize however as you say it’s not an urgent matter and I’d also like to standardise our 3rd party image storage to make it straightforward and see if we can save some space. Worth mentioning reducing the Z count may also save us considerable space over the whole set. Regards, Rob On 9 Mar 2014, at 21:58, jefferis notifications@github.com wrote:
|
FYI this is the response from Bill Hill: The voxel size encoding in a Woolz object is relative and http://www.emouseatlas.org/eAtlasViewer_ema/application/ema/anatomy/EMA27.php prompt% WlzFacts EMA27_3D_orig.wlz Object type: WLZ_3D_DOMAINOBJ. When you cut a section through an object with non-cubic voxels The distance slider will probably report the normalized voxel |
Will have to change on mass - propose to delay this until the main system is pushed and stable |
All updated a while ago during data restore. |
Split from a discussion started for feature request #45 since this is clearly a separate, and I think quite serious, bug.
As noted in June 2013:
I noticed for the first time that the woolz data in the vfb browser has 326 slices, not 218 like the JFRC2 template. I presume that the stack has been inflated 50% in Z by adding interpolated slices, rather than by changing the Z spacing, and that strikes me as an odd choice. Is there a reason?
The text was updated successfully, but these errors were encountered: