Allow more unit types for pixel_scale#10123
Conversation
pllim
left a comment
There was a problem hiding this comment.
Thanks! Needs a change log and additional text in https://astropy.readthedocs.io/en/latest/units/equivalencies.html#pixel-and-plate-scale-equivalencies .
I've tagged others to review this in detail. At a glance, I think the composite units should be created first before being applied to the values, hence the suggested parentheses.
|
@Jerry-Ma Could you add a test that it serializes to asdf? |
|
@nden Just added the Asdf round trip test. However, there is a can of worm that I opted not to open by choosing the test case, because I think the issue is bigger than the scope of this pull request. In short, the Asdf round trip test would fail on a test case like this: The reason is that Asdf serialize the argument in an alternated form for some units. In this case, the scaled form of Then, it is easy to see that when this file is read and the new pixel_scale is constructed, the kwargs will be of different units. In this particular case, we have: This will fail the assertion of equality because the |
mhvk
left a comment
There was a problem hiding this comment.
Looks all OK modulo a small typo. While getting rid of that, would you mind rebasing & squashing so it is just 1 commit? Thanks!
dd62813 to
ce29781
Compare
|
@mhvk Did the squash and rebase, forgot to ping you. |
Description
This pull request is to address the need of pixel equivalencies on images where pixels are not related to distances on the sky.
This proposed implementation does not assume an equivalency of the
pixscaleunit tou.rad/u.pix(oru.pix/u.rad), instead, it constructs the correct scaling relation by decomposing the unit and inspect the dimensionality ofu.pixin the unit ofpixscale.Fixes #10110