FYI: VTK integrated this fix:

Fix in https://github.com/MITK/MITK/pull/245, patches VTK

In T26653#188477, @kislinsk wrote:

@maleike

I re-enabled depth peeling support based on your pull request and also enabled depth peeling for volumes and FXAA. It works well for surfaces and volumes but totally breaks rendering of images/cross hair with opacity < 1. So this is not yet complete and I/we have to fix this before I am able to merge it.

Ok, just created https://github.com/MITK/MITK/pull/240

I tried the idea described above today and it fixes the behavior of my interactor that uses the mouse wheel in a 3D window. With this patch the MITK interactor gets to see the event first and can decide whether or not is is handled.

@kislinsk Thanks for your quick fix. I had a look into your changes, this looks very much like an overdue cleanup. Thanks again!

For illustration:

I just looked into this again and provided a merge request (https://github.com/MITK/MITK/pull/233). This also merges into the current release/2018-xx branch

In T26237#180471, @kislinsk wrote:

@maleike NV210? According to google this GPU was released in 2003.

(Didn't see latest comments from yesterday evening, was typing the following while only the initial comments of Stefan were visible in my browser)

I think your idea to add a short notice to Image Croppers UI would already help with the problem. An additional 'reinit' button could also help. However, I would argue against an 'enforced' reinit because this would come as a surprise to the user, potentially unnoticed (objects outside the image would just disappear making some users doubt their perception ;-)

Thanks for looking into this. I just generated a non-axes-aligned image for testing:

@thomass : thanks, that would be great! I just stumbled upon that but won't find the time to analyze the problem (plus the code was a bit lengthy and looked kind of redundant with the 3D mapper's code)

Great news! Honestly I am surprised that everything just works fine (since nobody every tried this), but this is just very good news! Thank you!

Suggestion: use size_t instead which is used all over the standard library to denote memory sizes.
Plus: if you find the time, you could try to generate a random/fixed pattern image of 20GB and verify that MitkWorkbench is able to load _and_ display it. This might uncover a couple of related bugs - or just pass perfectly :-)

@goetzm: just out of curiosity: this looks like something where a bug + fix is available. Could you share why this is closed 'Wontfix'?

Not sure if this was considered a feature (at least I am not aware of documentation): whitelisting modules changed, whitelisting plugins was added since 2016.11.

@goch No, I did not test the script on other platforms than Windows yet. I am surprised to see differences here because I am not aware of modifications other than that caching mechanism that should be working independent of the operation system. If you go through the changes, you might look out to any regex expressions that might be Windows specific..

Good to have your feedback and I am glad that this fix could be helpful for your build. However, I do not fully understand what kind of adaption you would need. Just in case that your problem is that fixup_bundle() clears its cache on each call: I think it should be safe to remove the call to get_prerequisites_clear_cache() in fixup_bundle(). In the latest version the cached result is stored under a name using all parameters passed to get_prerequisites. That should be stable even withour clearing the cache. If this is not sufficient, I am curious to see your use case

In T23292#109426, @goch wrote:

There are still a couple of entries that will not be sorted, as they are specifically added by the datamanager itself.

But the suggested solution is better than the current way.

In T11113#108062, @goch wrote:

However the displayed surface remains solid black for me despite changes in the rendering properties

Hey Daniel, no worries. It wasn't meant to be banned from MITK. I even had to remove my baby MITK Simulation to get things up and running

Code/Pull request available here: https://github.com/MITK/MITK/pull/209

In T18922#107700, @kislinsk wrote:

Had to remove OpenViewCore and QmlItems modules. These modules are not compatible to the OpenGL2 backend. GLEW and QOpenGLFunctions are incompatible as well.

I also ran into this bug when loading attached small mesh: