Fix inflated number of Z slices in main adult brain template

[jefferis]

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?

[jefferis]

@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.

[jefferis]

Thanks @Robbie1977!

Looking at:

https://github.com/VirtualFlyBrain/VFB/blob/Sandbox-Server/data/flybrain/tg/tiledImageModelData.jso#L36

I don't fully understand the pixel size, which appears to be

{"x":"0.4612588", "y":"0.4612588", "z":"0.46", "units":["\u03BC\u006D", "\u03BC\u006D", "\u03BC\u006D"]}

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?

[Robbie1977]

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:

https://github.com/VirtualFlyBrain/VFB/blob/Sandbox-Server/data/flybrain/tg/tiledImageModelData.jso#L36

I don't fully understand the pixel size, which appears to be

{"x":"0.4612588", "y":"0.4612588", "z":"0.46",
"units":["\u03BC\u006D", "\u03BC\u006D", "\u03BC\u006D"]}

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 were 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 https://github.com/dosumis?

Reply to this email directly or view it on
GitHubhttps://github.com//issues/61#issuecomment-37113885
.

[dosumis]

No idea I'm afraid. Would have been handled by NM. You could try asking him.

[jefferis]

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.

[Robbie1977]

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:

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.

—
Reply to this email directly or view it on GitHub.

[Robbie1977]

FYI this is the response from Bill Hill:
Yes, objects with non-cubic voxel size set should work.

The voxel size encoding in a Woolz object is relative and
doesn't have any units, ie they could be \mu or km. We frequently
use non-cubic voxels, often 4,4,7, as in EMA27:

http://www.emouseatlas.org/eAtlasViewer_ema/application/ema/anatomy/EMA27.php

prompt% WlzFacts EMA27_3D_orig.wlz

Object type: WLZ_3D_DOMAINOBJ.
Linkcount: 0.
Domain type: WLZ_PLANEDOMAIN_DOMAIN.
Linkcount: 1.
Domain plane bounds: 0 305
Domain line bounds: 51 223
Domain column bounds: 60 380
VoxelSize: 4 4 7
Values type: WLZ_VOXELVALUETABLE_GREY.
Linkcount: 1.
Background type: WLZ_GREY_UBYTE.
Background value: 255.
Values plane bounds: 0 305
Property list NULL.

When you cut a section through an object with non-cubic voxels
using wlziip you get back an image cut using normalized voxel
scaling, eg for 4,4,7 it's 1,1,1.75 (with 1.75 = 7 / 4). I
think the javascript client also queries wlziip for the voxel
size and knowing that we use \mu for the units, this lets us
report true measurement distances by simply multiplying the
distance by 4 and scale factor in the javascript client.

The distance slider will probably report the normalized voxel
distance as in the EMA27 case where z runs from -268 - 266,
int((268 + 266 + 1) / 1.75) = 306 (== Domain plane bounds: 0
305). Maybe it's the interpretation of these distances which is
giving the impression that the stack is being rescaled? You
should be able to check this easily using WlzFacts.

[Robbie1977]

Will have to change on mass - propose to delay this until the main system is pushed and stable

[Robbie1977]

All updated a while ago during data restore.