PR fails existing binary test. Being an intrinsically 2D format, there is a more complex relationship between the nature of the input data and the utilisation of square-bracket notation in the output path for PNG. I'll have to remind myself of how it works and then figure out why this edge use case fails.

Need to clarify the intended behaviour in this circumstance.

If anat.nii is a 3D image, let's say 128x128x128, and -coord 0 70 is specified, then you have an image that is 1x128x128. If you were to request to write that image to a PNG, it would detect that the first axis is of unity size, and so write a 2D image based on axes 0 and 1, which would be sagittal assuming RealignTransform is true.

But you're then specifying an output image path with the square-bracket syntax. This would logically take the last non-unity axis---the third axis in this case---and generate one PNG file per coordinate, resulting in 128 images of dimension 1x128. Suspect that this is not what the user intended, but it should nevertheless work rather than segfaulting. I don't think it makes sense that the square-bracket syntax would detect a unity dimension and "attach itself" to that dimension given that by its very nature it's intended to write multiple image files.

Proposed that this be deferred from 3.0.4 to 3.1.0, given that the usage resulting in the segfault is arguably erroneous.

Closing in favour of #2535.