Skip to content

Allow more unit types for pixel_scale#10123

Merged
mhvk merged 1 commit intoastropy:masterfrom
Jerry-Ma:generalize_pixel_scale
Apr 16, 2020
Merged

Allow more unit types for pixel_scale#10123
mhvk merged 1 commit intoastropy:masterfrom
Jerry-Ma:generalize_pixel_scale

Conversation

@Jerry-Ma
Copy link
Contributor

@Jerry-Ma Jerry-Ma commented Apr 7, 2020

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 pixscale unit to u.rad/u.pix (or u.pix/u.rad), instead, it constructs the correct scaling relation by decomposing the unit and inspect the dimensionality of u.pix in the unit of pixscale.

Fixes #10110

@astropy-bot astropy-bot bot added the units label Apr 7, 2020
@pllim pllim requested review from eteq and mhvk April 7, 2020 21:58
@pllim pllim added this to the v4.1 milestone Apr 7, 2020
Copy link
Member

@pllim pllim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@nden
Copy link
Contributor

nden commented Apr 8, 2020

@Jerry-Ma Could you add a test that it serializes to asdf?
Adding an example to the list here will do it. Thanks.

@Jerry-Ma
Copy link
Contributor Author

Jerry-Ma commented Apr 8, 2020

@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: pixel_scale(100. * u.pix / u.imperial.inch).

The reason is that Asdf serialize the argument in an alternated form for some units. In this case, the scaled form of u.imperial.inch is used. This results in the serialized file as follows:

#ASDF 1.0.0
#ASDF_STANDARD 1.4.0
%YAML 1.1
%TAG ! tag:stsci.edu:asdf/
--- !core/asdf-1.1.0
asdf_library: !core/software-1.0.0 {author: Space Telescope Science Institute, homepage: 'http://github.com/spacetelescope/asdf',
  name: asdf, version: 2.5.2}
history:
  extensions:
  - !core/extension_metadata-1.0.0
    extension_class: asdf.extension.BuiltinExtension
    software: {name: asdf, version: 2.5.2}
  - !core/extension_metadata-1.0.0
    extension_class: astropy.io.misc.asdf.extension.AstropyAsdfExtension
    software: {name: astropy, version: 4.1.dev917+g8267d16fa.d20200407}
  - !core/extension_metadata-1.0.0
    extension_class: astropy.io.misc.asdf.extension.AstropyExtension
    software: {name: astropy, version: 4.1.dev917+g8267d16fa.d20200407}
eq: !<tag:astropy.org:astropy/units/equivalency-1.0.0>
- kwargs_names: [pixscale]
  kwargs_values:
  - !unit/quantity-1.1.0 {unit: !unit/unit-1.0.0 0.39370079cm-1 pixel, value: 100.0}
  name: pixel_scale
inch: !unit/unit-1.0.0 2.54cm
per_inch: !unit/unit-1.0.0 0.39370079cm-1
...

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:

>>> dpi_rt.kwargs[0]  # the round tripped value
{'pixscale': <Quantity 100. 0.393701 pix / cm>}
>>> dpi.kwargs[0]  # the input value
{'pixscale': <Quantity 100. pix / inch>}

This will fail the assertion of equality because the __eq__ of Equivalency class not setup to handle this situation (it only compares kwargs by doing a.kwargs == b.kwargs). However, these two parameters are indeed the same quantity, as the assertion assert_quantity_allclose(dpi.kwargs[0]['pixscale'], dpi_rt.kwargs[0]['pixscale']) passes.

Copy link
Contributor

@mhvk mhvk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Jerry-Ma - this is really nice, thanks! I have one comment about the implementation that is really more about what was there than what you added, but we might as well change it... I give a specific suggestion inline.

Copy link
Contributor

@mhvk mhvk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks all OK modulo a small typo. While getting rid of that, would you mind rebasing & squashing so it is just 1 commit? Thanks!

@Jerry-Ma Jerry-Ma force-pushed the generalize_pixel_scale branch from dd62813 to ce29781 Compare April 8, 2020 20:04
@Jerry-Ma
Copy link
Contributor Author

Jerry-Ma commented Apr 16, 2020

@mhvk Did the squash and rebase, forgot to ping you.

Copy link
Contributor

@mhvk mhvk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Jerry-Ma - thanks for the ping. This looks all OK now, so merging! Thanks for the nice improvement!

@mhvk mhvk merged commit d91f444 into astropy:master Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a new unit equivalency to handle pixel scale specified with length unit.

4 participants