Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1D analysis #159

Merged
merged 125 commits into from
Nov 3, 2023
Merged

1D analysis #159

merged 125 commits into from
Nov 3, 2023

Conversation

jeffjennings
Copy link
Contributor

@jeffjennings jeffjennings commented Feb 20, 2023

Adds utilities to obtain the 1d (radial) representation of:
- an image (such as that obtained from an MPoL model), onedim.radialI
- a visibility distribution (such as that obtained from an MPoL model), onedim.radialV

radialI expects an image array rather than an ImageCube, and radialV expects a set of 2D visibility amplitudes rather than a FourierCube. I did this to make the routines immediately accessible for generic numpy arrays, so a bit of preprocessing from cubes is required (if I'd done the converse, a bit of processing for numpy arrays would be required, and I thought it best to keep the functions in this slightly more general design).

Note:
Adds frank as an EXTRA_REQUIRES : tests and analysis dependency.

Todo:

  • radial image space function radialI
  • radial visibility function radialV (account for optically thick vs thin)
  • add tests

Closes #189

This should only be reviewed and merged after #195 is resolved, as that branch was pulled into this one.

@jeffjennings jeffjennings self-assigned this Feb 20, 2023
@jeffjennings jeffjennings marked this pull request as draft February 20, 2023 04:33
@jeffjennings jeffjennings added this to the v0.1.4 milestone Feb 20, 2023
@jeffjennings
Copy link
Contributor Author

jeffjennings commented Nov 2, 2023

test_radialI diagnostic plot, showing the correct recovery of a 1d brightness profile from a projected 2d image:
test_radialI

test_radialV diagnostic plot, showing the correct recovery of a 1d visibility profile from a projected 2D visibility distribution:
test_radialV

@jeffjennings jeffjennings marked this pull request as ready for review November 2, 2023 00:44
@jeffjennings
Copy link
Contributor Author

This should only be reviewed and merged after #195 is resolved, as that branch was pulled into this one.

@jeffjennings jeffjennings requested a review from iancze November 2, 2023 03:17
@iancze
Copy link
Collaborator

iancze commented Nov 2, 2023

This is excellent!

radialI expects an image array rather than an ImageCube, and radialV expects a set of 2D visibility amplitudes rather than a FourierCube. I did this to make the routines immediately accessible for generic numpy arrays, so a bit of preprocessing from cubes is required (if I'd done the converse, a bit of processing for numpy arrays would be required, and I thought it best to keep the functions in this slightly more general design).

I would be in favor of doing the converse, but we should have a broader discussion about core objects in the codebase. My reasoning is that the ImageCube is a well-defined object of MPoL with conventions on how it should be packed and its dimensionality, whereas a numpy image array is just a numpy array. So to have this work correctly on numpy arrays, we then need to impose conventions on correct intake of numpy arrays, which might give users another potentially confusing object to deal with.

What types of data do you envision these routines to work on? I would think the radialI and radialV would be most useful directly applied to ImageCubes and FourierCubes produced directly from an RML optimization loop, but maybe you have other use cases in mind.

@jeffjennings
Copy link
Contributor Author

jeffjennings commented Nov 2, 2023

This is excellent!

radialI expects an image array rather than an ImageCube, and radialV expects a set of 2D visibility amplitudes rather than a FourierCube. I did this to make the routines immediately accessible for generic numpy arrays, so a bit of preprocessing from cubes is required (if I'd done the converse, a bit of processing for numpy arrays would be required, and I thought it best to keep the functions in this slightly more general design).

I would be in favor of doing the converse, but we should have a broader discussion about core objects in the codebase. My reasoning is that the ImageCube is a well-defined object of MPoL with conventions on how it should be packed and its dimensionality, whereas a numpy image array is just a numpy array. So to have this work correctly on numpy arrays, we then need to impose conventions on correct intake of numpy arrays, which might give users another potentially confusing object to deal with.

What types of data do you envision these routines to work on? I would think the radialI and radialV would be most useful directly applied to ImageCubes and FourierCubes produced directly from an RML optimization loop, but maybe you have other use cases in mind.

Thanks! And yes that makes sense, I'm happy to change it to require less/no pre-processing for mpol model inputs. I was thinking of images generated by external software, like .fits obs or images from simulations, or observed / simulated visibilities. But it's equally easy to stuff those into cubes as it is to break mpol images out into numpy.

@jeffjennings
Copy link
Contributor Author

@iancze I updated radialI (radialV) to take in an ImageCube (FourierCube) - ready for review.

Copy link
Collaborator

@iancze iancze left a comment

Choose a reason for hiding this comment

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

Thanks, this looks great!

@iancze iancze merged commit 4676447 into main Nov 3, 2023
4 checks passed
@iancze iancze deleted the one_dim branch November 3, 2023 06:42
@iancze iancze mentioned this pull request Nov 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1D profiles of images and visibility models
2 participants