👋 @man-shu Thanks for creating a PR!

Until this PR is ready for review, you can include the [WIP] tag in its title, or leave it as a github draft.

Please make sure it is compliant with our contributing guidelines. In particular, be sure it checks the boxes listed below.

• PR has an interpretable title.
• PR links to Github issue with mention Closes #XXXX (see our documentation on PR structure)
• Code is PEP8-compliant (see our documentation on coding style)
• Changelog or what's new entry in doc/changes/latest.rst (see our documentation on PR structure)

For new features:

• There is at least one unit test per new function / class (see our documentation on testing)
• The new feature is demoed in at least one relevant example.

For bug fixes:

• There is at least one test that would fail under the original bug conditions.

We will review it as quick as possible, feel free to ping us with questions if needed.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.95%. Comparing base (abb80ff) to head (88fbc46).
Report is 70 commits behind head on main.

@@            Coverage Diff             @@
##             main    #4397      +/-   ##
==========================================
+ Coverage   91.85%   91.95%   +0.09%     
==========================================
  Files         144      143       -1     
  Lines       16419    16639     +220     
  Branches     3434     3529      +95     
==========================================
+ Hits        15082    15300     +218     
+ Misses        792      773      -19     
- Partials      545      566      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

The fix was indeed the one proposed in #4393.

So now the default behavior for all functions under nilearn.image module (except math_img) is to directly copy the input image's header info to the output image in whichever fields possible and update the rest, via new_img_like.

As for math_img, it was the most peculiar case and I think the choices made in #4337 should stay in place.

I'm wondering whether we should go through deprecation cycles...

yeah I am wondering about this as well, because some of this may induce behavior changes in the code.

unless we decide that the old behavior was a bug and that this is a bug fix

Personally I would be +1 deprecation cycles ! This is a noticeable enough change (and I don't know that the before was wrong ) that I think we should alert users.

Personally I would be +1 deprecation cycles ! This is a noticeable enough change (and I don't know that the previous before was wrong ) that I think we should alert users.

Good with me to err on the side of caution and let our users know.

Yes, I also agree with going through the deprecation cycles and letting people know.

But my feeling is that it should not affect existing internal nilearn routines because, as far as I know, we don't ever directly use the header information in any of the workflows. Some bids-dependent functionalities need TR info, but that is extracted from JSON sidecars.

However, some external software probably does use the headers.