Open Lestropie opened 9 years ago
It would be useful to have control of lots of different options during a screenshot recording. In the past I have dealt with this by making separate animations, then either combining or blending them before converting to a movie.
Ideally what we need is a way to script up a recording, that allows us to change any of the mrview options. My concern is that adding buttons for changing ROIs to the screenshot tool will unnecessarily clutter the UI for most applications.
I guess this might end up being related to the way we handle command line options for mrview. It is also closely related to a 'mrview save/load state' feature that we have talked about in the past.
What exactly do you mean by 'navigating overlay images"? In case you didn't already know, you can currently 'shift-click' a specific overlay to view only that one.
What I'm referring to here isn't switching between overlay images; it's having a 4D overlay image, and switching between volumes in that image (ie. changing the position along axis 3). This needs a control in the overlay tool (which can be disabled when the currently selected overlay is only 3D, or when multiple overlays are selected).
In addition, I have a collaborative application where it is necessary to step through these volumes during screen capture, much like there is currently a control in the screen capture tool to set a target volume in the main image.
Ah, I see.
On Thu, Jul 23, 2015 at 1:57 PM, Robert Smith notifications@github.com wrote:
What I'm referring to here isn't switching between overlay images; it's having a 4D overlay image, and switching between volumes in that image (ie. changing the position along axis 3). This needs a control in the overlay tool (which can be disabled when the currently selected overlay is only 3D, or when multiple overlays are selected).
In addition, I have a collaborative application where it is necessary to step through these volumes during screen capture, much like there is currently a control in the screen capture tool to set a target volume in the main image.
— Reply to this email directly or view it on GitHub https://github.com/MRtrix3/mrtrix3/issues/297#issuecomment-123956192.
By the way, on the side of screen capturing things; funny pro-tip: while recording stuff using the screen capture tool, everything in the viewer remains accessible and interactive. It might not be smooth, perfectly timed, etc... but it definitely allows you to e.g. make a volume more/less transparent, etc.. somewhere along an animation; without requiring play/stop setups or other editing afterwards.
I do agree that we should be a bit careful with what we might potentially clutter the screen capture tool with. Basically any property/setting of the main image as well as any of the tools is a potential candidate, but you wouldn't want to add them all obviously. Would a good logic be to only add in things that act on the main image, or general properties such as the camera/focus position? And have all the rest (e.g. things that act on overlay or other tools' properties/settings) somewhere in a bit of a more secondary location (like, as part of a scripting approach to animations; or maybe in a (few) secondary dock(s) that can be accessed through e.g. a button in the main screen capture tool)? What do you guys think of this in general?
(oh yeah, and I definitely agree the overlay tool itself needs a 4D control of course)
What I want to do at some stage is a QGroupBox that can be expanded and contracted (haven't been able to find anything built in to QT to do this). That way, somewhere in the screen capture tool you could have a bunch of group boxes, each providing access to settings in a particular tool, but all collapsed by default.
Other problem is that you could conceivably have access to every single setting in every other tool within the screenshot tool, which would be overkill. I have an application that requires stepping through overlay image volumes, which is why I want to do it, but we need to figure out where the line is.
The more tricky aspect is figuring out how to do this in the code. Certainly don't want every tool having full public access to every other tool. Things like the overlay tool, where there are potentially multiple overlay images loaded (and the screenshot tool would need access to the full list), are tricky. Currently the leader in my head is:
As you can see, it gets pretty ugly for even a single functionality...
Yes, as Rob says, having dependencies between tools is probably a Bad Idea. I prefer Dave's suggestion of allowing the whole thing to be scripted. Even using the current command line option might be sufficient, as long as all the required options are there. It would be painful to write, but we could provide wrappers that take an easier to write format and massage that into something suitable for MRView (for example).
Otherwise, @lestropie: have you tried switching the main and overlay images around? If you make your overlay the main image, assign it whatever colourmap you need, than load your main image as an overlay, and make it greyscale, that ought to allow you to do what you're after...? Although clip planes only apply to the main image, so that probably won't do what you want... Oh well.
Otherwise, @lestropie: have you tried switching the main and overlay images around? If you make your overlay the main image, assign it whatever colourmap you need, than load your main image as an overlay, and make it greyscale, that ought to allow you to do what you're after...?
That's what I've instructed him to do thus far; but it's not ideal, because...
Although clip planes only apply to the main image, so that probably won't do what you want... Oh well.
Partly done with #307; leaving here in case I get around to attacking the screenshot tool extension part.