Dear Andrew,

Thanks for the support. +10 was unexpected. Was only expecting +1

Sorry for framing it as a storage problem. I tend to look things from the storage viewpoint.

The reason for framing it as a storage problem is I thought by fixing the orientation as storage we  can solve these problems:

• The viewing problem as you had so well described: The theory goes that if I set the storage orientation, then you can be sure that your viewing convention is always correct without (1) referring to a particular checkbox and (2)[more importantly] worrying whether a nifti file created by third party actually remember to set the the bit or not. Believe it or not, it is difficult for a programmer to remember whether he set a checkbox to true/false. [I share your sentiment/problems with viewing. It is perhaps worse for me as I don't write my own viewing program and has to rely on third parties. In fact, my favourite image viewing program is to write out the images as it is (ignores any orientation information) in PNG and view it using preview]
• Most users simply do not even know about the different in orientation, they just accept whatever the program tells them as the gospel truth. That's not good.
• Worse still when we get data from multiple centres with different convention and nobody from the centre can tell us definitely what their orientation is. It is a big go around, asking radiographers, physicist or just about everyone we can think of, then experiment with the data to confirm orientation. Even then, sometimes we have to fudge it. In fact, sometimes I am hoping something like left brain activated by left hand movement (for right hander) happens in every dataset we have to confirm that we got the orientation wrong so that we can correct it.
• There are programs that (1)simply ignores orientation,  (2)some program reads orientation, the flip the images and (3)some programs read and honour orientation, but can sometimes fail to set the orientation bit corrrectly when creating the output.  Having two ways of storing orientation (sform and qform) is not helping either. [Please note that I am just arguing orientation information shouldn't be store in them, not that they are not useful. Although I would say it should had been only either sform or qform, and use the 3x4 transformation matrix notation only]
• Mixing programs from different analysis suit is almost impossible because of the orientation mix up, or we simply don't know how the orientation is handled.
• The most coherent approach I seen in dealing with orientation is FSL, where it put out a statement on how its programs treat orientation information. That is still simpy another way of saying orientation is the users' problem. In some sense that is simply confirming that you the user is responsible for orientation issue. Given the current situation, IMHO FSL's hand is forced.
• My approach? Unless I tell you I read orientation information, I don't. I simply copy your input hdr to the output hdr as well.

In short, orientation problem is impeding multicentre works and mixing programs from different analysis suites.

The reason for transforming orientation to storage problem is the scanner is usually the place with the most programming expertise or best information source (physicist, radiographers) so it is the best place to handle the orientation problem. Furthermore, we nip the problem in the bud if we resolve it there.

HTH
Cinly