Hi,

any progress on this? We are really excited to use it in several projects!

thanks,
Jon

any updates?

thanks,
Jon

Hi Jon,

With the priority set to normal and severity set to minor, it's fallen below other critical bugs in Alex's work flow. Would you like to have it re-prioritised?

Hi Nicole,

If we could raise the priority, that would be great. This would be a really cool feature for us, and I know there are several others in our lab who would use slicer if it could display images like this.

thanks,
Jon

Hi Nicole and Alex,

Sorry, I don't mean to be a pain. I'm making figures for two different papers that will be submitted by the end of the month. I'd love to use slicer to make these figures. Do you have a guess as to whether this will be fixed by then? If not, I need to look for another way to make my figures. Again, not trying to be a pain, I just need to decide what I'll be using.

thanks,
Jon

I loaded the volumes and LUT and the picture I got seems to respect 0 alpha.
I am attaching the image, is it not what you expected to see?

Hi Alex,

Thanks for taking a look. Are you sure it's really alpha 0? Or is it just blending the black with the background image? Try adjusting the foreground image slider and watching the background image. If you see the background image getting darker and lighter as you go, then that means it's mixing the background image with the black part of the foreground image. What I want it to look like is the background image untouched in the parts of the foreground image that are not red or blue when the foreground image is turned up to 100%.

thanks,
Jon

Hi Jon,
It seems that right now it is doing alpha blend:
the resulting blend_alpha = fg_opacity fg_alpha + (1-fg_opacity) bg_alpha

if fg=funtional_result_volume; bg=atlas_volume; and fg_opacity = 1.0

blend_alpha = fg_alpha, which is what I see currently.

But you want it to be blend_alpha = bg_alpha always independent of opacity, am I correct?

Jon, is that what you expectat
fg=funtional_result_volume; bg=atlas_volume; fg opacity 100%
(see LUT_Blend1 image)?

This was made using vtkImageBlend::BlendMode(VTK_IMAGE_BLEND_MODE_COMPOUND) which is not currently exposed in slicer UI.

Hi Alex,
Almost. in your blend_alpha formula, if the fg_alpha is 0.0 (which it is in the middle of fmriLUT.ctbl (see rows 100 through 170), and fg_opacity = 1.0, then blend_alpha would = 0, not fg_alpha. In fact, if fg_alpha = 0.0, then blend_alpha will always be some fraction of bg_alpha, dependent on fg_opacity.

Am I wrong in the way I'm thinking about alpha? In my mind it means that if a foreground voxel has alpha 0, then it should be "transparent", and simply show the background voxel at 100%. Is this wrong?

So maybe the formula should be this?

blend_alpha = fg_opacity fg_alpha + (1 - fg_opacityfg_alpha) * bg_alpha

That way if fg_alpha = 0.0, then blend_alpha will = bg_alpha, and the fg_alpha would still modulate blend_alpha the same way if it was = 1.0, which it almost always is.

Feel free to call me if chatting would be easier, 314-488-7132

thanks again,
Jon

Hi Alex,

Sorry, I didn't see your second response before I sent that last note. It's hard to tell, but it still doesn't look right. If you just select "none" for the foreground image in the view from that last image, does the background image look the same? and when you turn the foreground image back on, does that background image get "darker"? It's hard to tell from the pictures.

Jon, I suggest we discuss it with Steve, he is more knowledgeable about this pipeline. Are you available next Tuesday, April 16th?

Sure, I'm available then. And actually, as I look back at Steve's comment, he even says "Probably it is replacing it with the fade value rather than multiplying the fade times the alpha", which I think is what I just suggested in the formula, right now in the bg part of the blend equation it's fg_opacity (the fade) and not fg_opacity*fg_alpha (the fade times the alpha).

Jon, after talking to Steve we have decided that we have to restructure the pipeline as shown in the diagram

Hi Alex,

Thanks for the update. It looks like there are two new steps in the pipeline to implement. Any idea as to when this will be done?

thanks again for moving this along,
Jon

Here is a result of the new pipeline at fg opacity = 1. The bg does not changes as I decrease fg opacity, but fg fades to nothing at 0.
Jon, is this what you expect?

Yes, I think that's it! yay! Will this be in tonight's build?

I am testing performance now, scrolling seems just a bit slower but but should be probably ok

Updated vtkMRMLScalarVolumeDisplayNode visualization pipeline to fix alpha compositing problem as described in the attached diagram.
Rev. 21900

Great!

Out of curiosity, is the nice schematics reported in "VtkMRMLScalarVolumeDisplayNode.pdf " added to either the wiki or doxygen ?

Good question - do we have a way to add pdf or png files to doxygen?

BTW, I made them with LucidChart, which is a very simple browser-based drawing package.

Doxygen support images: http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdimage

We would need to make sure the IMAGE_PATH settings is properly configured: https://github.com/Slicer/Slicer/blob/master/Utilities/Doxygen/Doxyfile.txt.in#L744

As a convention, we could do the following:
1) If needed, add a directory named "Documentation" to library, loadable module, etc ...
2) Add images to a sub directory of the documentation folder: /path/to/Documentation/images

It means, if doxygen can be generated on a given platform, we would scan the source tree for path matching "*/Documentation/images" and append them to the IMAGE_PATH setting.

What do you think ?

I think it sounds great to have the option to add pngs to the doxygen - as we discussed today, probably a good idea to come up with our wish list for a nice system to be implemented in the namic renewal.

Closing resolved issues that have not been updated in more than 3 months