Remove the dead use_adjoint_scaling parameter and adjoint_scaling attribute

[Jammy2211]

Summary

use_adjoint_scaling has no effect on either remaining transformer. Both TransformerDFT.image_from and TransformerNUFFT.image_from accepted it and never referenced it in any code path — including all four of TransformerNUFFT's (jax one-shot, jax chunked, numpy one-shot, numpy chunked). Passing True silently did nothing.

Follow-up to #475, which flagged this but deliberately left it alone rather than widening a dependency removal.

It was not always dead — where the work actually went

Class	Applied adjoint_scaling?
TransformerDFT	Never
TransformerNUFFTPyNUFFT	Yes — image *= self.adjoint_scaling, the only real user. Removed in #475.
TransformerNUFFT	Until bd18a769 (2026-05-22), then deliberately removed

bd18a769 states the reason: the 4·N_y·N_x factor "is a Kaiser-Bessel compensation that only the legacy pynufft variant needs; the nufftax adjoint is already the mathematical adjoint and needs no extra scaling." With pynufft gone there is no backend that needs it.

Why remove the attribute too, not just the parameter

adjoint_scaling was public and inert. Leaving it invites someone to apply it by hand and silently scale a dirty image by 4096× on a 32×32 grid. A caller still passing the keyword now gets a TypeError rather than a silent no-op — the safer failure, since the value was genuinely load-bearing for one now-deleted class.

Scale-consistency across the two transformers is unaffected: it comes from both returning the plain mathematical adjoint, not from this flag.

API Changes

Breaking: the use_adjoint_scaling keyword is removed from TransformerDFT.image_from and TransformerNUFFT.image_from, and the adjoint_scaling attribute is removed from both classes. No migration is needed for correctness — the keyword had no effect on either class, so removing the call site changes no numbers. Anyone reading transformer.adjoint_scaling and applying it manually was introducing a 4096×-class error and should stop.

See full details below.

Test Plan

• TransformerNUFFT.image_from vs TransformerDFT.image_from: 1.562e-13 relative, identical before and after this change
• use_adjoint_scaling=True vs False was bit-identical (max|diff| = 0.000e+00) on both classes before removal
• Passing the removed keyword now raises TypeError (loud, not silent)
• pytest test_autoarray — 1179 passed, including test__curvature_matrix__interferometer_sparse_operator__delaunay__dft_and_nufft_match, the parity test bd18a769 added for exactly this path
• Downstream against this branch: PyAutoGalaxy 1103 passed, 1 skipped; PyAutoLens 532 passed, 1 skipped

Full API Changes (for automation & release notes)

Removed

• TransformerDFT.image_from(..., use_adjoint_scaling=) — keyword removed; it was never referenced
• TransformerNUFFT.image_from(..., use_adjoint_scaling=) — keyword removed; unreferenced since bd18a769
• TransformerDFT.adjoint_scaling — attribute removed
• TransformerNUFFT.adjoint_scaling — attribute removed

Changed Signature

• TransformerDFT.image_from(visibilities, xp=np) — was (visibilities, use_adjoint_scaling=False, xp=np)
• TransformerNUFFT.image_from(visibilities, xp=np) — was (visibilities, use_adjoint_scaling=False, xp=np)

Changed Behaviour

• None. Numerically identical output; the removed keyword had no effect on either class.

Migration

• Before: transformer.image_from(visibilities=vis, use_adjoint_scaling=True)
• After: transformer.image_from(visibilities=vis)
• Interferometer.apply_sparse_operator was the only in-repo caller and is updated.

Note for anyone with pre-2026-05-22 results: if you used TransformerNUFFT with use_adjoint_scaling=True before bd18a769, the factor was applied then and is not applied now. Results generated before that commit differ from anything regenerated today by 4 * N_y * N_x. That change landed in May and is not introduced here.

---

Generated by Claude Code