Volume planes on multiple data display is erratic

[meng@…]

Looks like volume planes command to cycle through planes when applied to multiple datasets that are different optical microscopy channels may not correctly handle the blending.

Begin forwarded message:

From: Elaine Meng <>
Subject: Re: Graham data, reasonable ChimeraX session
Date: October 13, 2016 at 11:04:35 AM PDT
To: Tom Goddard

Hi Tom,
Graham-data script take 2...

Script attached, setup2.cxc. Changes from the first one, setup.cxc, are that I set each of the 4 imaging datasets to step 1 and made the top levels to go to the max value, and used the volume command instead of “transparency” to make the 4 segmentation meshes transparent.

I noticed that the data looks very “sandwich-y” in that the middle Z layers have much less intensity than the perimeter of the cell, and if you rotate 90 degrees you can barely see anything. I thought it might be a rendering weirdness in ChimeraX, but it seems to be the same way in Chimerax.

I also attach another Chimera session with colors and levels the same as in the ChimeraX script setup2.cxc and a side-by-side image comparison, so that you can see the blending difference. (The model numbers aren’t the same in the session vs. the script, though… sorry). As you’re probably well aware, there are more white spots in ChimeraX where data peaks overlap.

A possible bug (prioritize as desired): I was running volume planes to try to understand whether there was really data in the middle of the sandwich or not, and discovered that if I run this command repeatedly in ChimeraX (after setup2.cxc) I get different playbacks, sometimes only containing one of the datasets, and after about 10x, sometimes none of the datasets.

volume #1,​3,​5 planes z,1,1000,1,10

In the Chimera session, the corresponding command does give a consistent result upon repeated use:

volume #1,​2,​4 planes z,1,1000,1,10

Elaine

[Tom Goddard]

There are only 58 z planes in this data. So the command

volume #1,​​3,​​5 planes z,1,1000,1,10

which says to cycle through to z plane 1000 is going to spend a very long time, possibly minutes showing regions outside the bounds of the density map. This is not considered an error in the current design, and it does not terminate the command -- it does exactly what you asked for. So then when you run the command again, you probably don't realize that it is still running the previous command. After running it again and again you have many copies of the command trying to adjust the planes of the 3 maps at each new frame. The behavior is undefined -- it is not defined which command will have the final word -- but by testing apparently some copy of the command which is display a region outside the map is winning out.

I could try to fix this in a few ways -- terminating the command if the region goes outside the bounds of the map, or terminating the last volume planes command on a map if a new command is issued. These are a bit complex and the error seems very obscure, so I'm not going to fix this.