Detect first positional argument as an image to open

[lrq3000]

Dear Chris,

I am transitioning from MRIcron to MRIcroGL for my everyday NIfTI viewing needs, as MRIcron does not support anisotropic images very well (it downscales in every dimensions, including the ones of higher resolution).

I would just like to request if it would be possible to detect the first positional argument as an image to open. Indeed, I am trying to use MRIcroGL as my default app to open nii files, and when I do so it does not open the file, so I guess it's because I have to supply a switch to tell it this is an input image, but it's usually a more involved process to provide a custom commandline in most windows managers (in particular Windows 10 that I am using).

[neurolabusc]

Can you make sure you have the latest version (v1.2.20191219). I just tried from the Windows command line and MRIcroGL myNifti.nii opened the designated file.

With regards to MRIcron downsampling, have you tried increasing the "Maximum Dimension [voxels]" option in the preferences. I have not looked at that in a decade, but that was one method to limit the amount of RAM required to resample data.

[lrq3000]

Thanks a lot for your fast reply!

AH! I did not notice that you moved the project to a newer github repo, I now see it's mentioned in the readme but maybe you could add a link to the new repo directly in the description?

So you're right I was using the version from November, that's the last one released on NITRC, where I downloaded the bin. Now on the MRIcroGL12 repo, I could find the December release, I tried from the commandline just now, and I still get the same issue.

Here is what is opened, whatever is the nifti file I use, I always get the same Borg_Temp image opened:

About your suggestion of raising Maximum Dimension in MRIcron, you're right it worked! But still I would prefer to migrate because MRIcroGL is a lot smoother in the rendering since it's using the graphic card (and is more optimized I guess) :-)

BTW, I can't remember MRIcroGL opening in 2D view by default before, I remember it opening with the 3D view. If this was done on purpose, then I think it's a really good idea, as most people want to see the 2D view first, and then they can use the 3D renderer to create nicer visualization. This is one of the reasons I am now migrating as I think this is a major UX improvement.

[neurolabusc]

The first lines of the 1.0 release and 1.0 source both state that 1.0 is deprecated, each with a link in the bold text.

Usually the Borg_temp opens when there is a problem with the supplied image or path. This is explicit when launching MRIcroGL from the command line on Linux/MacOS, as Unix graphical applications have terminal output. Are you sure you have the path name correct? Can you confirm this is v1.2.20191219?

UX change suggested by @leobonilha. If any user prefers launching to a rendered view, choose the Preferences window and click Advanced. In the text editor set the 'StartupDisplayOrient=64'. (1=axial, 2=coronal, 4=sagittal, 8=sagittal (nose left), 16=MPR.

[lrq3000]

Ah great idea of @leobonilha, kudos! And thank you very much for implementing it!

The first lines of the 1.0 release and 1.0 source both state that 1.0 is deprecated, each with a link in the bold text.

Yes and that's how I found about the new repo, but it's confusing because on NITRC there's not the latest release (the latest is September), then there's no obvious link to the github repo from NITRC (I guess it's there but you have to dig somewhere in the page), so googling MRIcroGL github leads to the old repo, and since there are so many files at the root, the user tend to read only the description at the top before going to the releases to find the latest release, and at first sight we don't necessarily see the message you put, because we are looking for the version number and they are older.

So the whole situation is confusing and that's why I strongly advise to put the redirect link directly in the description on this old github repo (also for issues tracking, I mean for proof I created the issue here instead of the newer repo).

Usually the Borg_temp opens when there is a problem with the supplied image or path. This is explicit when launching MRIcroGL from the command line on Linux/MacOS, as Unix graphical applications have terminal output. Are you sure you have the path name correct? Can you confirm this is v1.2.20191219?

Yes and yes, I can confirm both. Is there a debug log or something I can enable to maybe get more info to send you?

[neurolabusc]

1. When you provide a filename from the command line, in generates a Python script and attempts to run the script. You can see the script and any errors generated by opening the scripting panel on the right hand side. You need to be aware that for Python strings the "\" character is an escape character, e.g. "\t" means tab. The image below shows the Python interpreter error generated when the user runs MRIcroGL d:\tmp.nii from the command line. This is not an issue for Linux or MacOS, as they use / instead of \ as the file separator. Modern versions of Windows accept either, so I would suggest you call MRIcroGL d:/tmp.nii

2. I have created a beta release for the upcoming version MRIcroGL_windows_2020beta.zip that will convert command line \ to /. This will work for opening new files. However, when creating scripts from the user interface instead of the command line, be aware that the Python interpreter requires you to use /. This is not specific to my software, but a general attribute of Python strings.

3. The beta release includes a new Windows debug mode feature. To enable this, run the new software and choose Help/Preferences menu item and then click the Advanced button. This will open the full preferences in a text editor. You can change the line DebugMode=0 to read DebugMode=1. In this mode, a new terminal window opens showing details about file loads. This is only for Windows, as Unix users can always see terminal output by running from the command line. Note that this can show many errors, but not the one you describe hear - that error is detected and reported by the Python interpreter, not my software.