Deprecating Apertures
See original GitHub issueSince the Regions
is getting matured , we can talk about possibilities of how we can replace the Aperture
s with it.
I think they share a lot in common and would be easy to integrate.
I would like to know which would be the best place to start and what are the possible difficulties which we may be facing?
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
aperture | Apple Developer Documentation
aperture. A factor that determines the transition between in-focus and out-of-focus areas. Animatable. iOS 8.0–11.0 Deprecated iPadOS 8.0–11.0 Deprecated ...
Read more >Common Pipeline Library Reference Manual: High level functions to ...
Simple apertures creation from a user supplied selction mask. ... Deprecated: Replace this function with cpl_apertures_get_pos_x() ...
Read more >Aperture photometry — SExtractor 2.24.2 documentation
The use of MAG_BEST is now deprecated as MAG_AUTO measurements are much more robust in versions 2.x of SExtractor. The first improvement is...
Read more >Photo Tip #56: Does Shutter Speed Affect Depth of Field?
First if you change your Aperture you are changing how much light you are exposing your sensor to. Which means you must either...
Read more >Info: Functionality Scheduled for Deprecation - Venafi support
The WebSDK authorization method that involves API keys was formally deprecated in Trust Protection Platform 20.2 and will no longer be available in...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I agree that we shouldn’t deprecate the aperture classes, just rework them so that behind the scenes they use classes from regions. I think photutils has enough users that we wouldn’t want to break something so fundamental.
Thanks, @sushobhana. Yes, the plan has been to migrate the general features of aperture-photometry functionality from
photutils
toregions
(and thenregions
toastropy
core). This has been on my to-do list, but hasn’t been high priority (I’ve also been hopingregions
would go intoastropy
sooner than later). Thanks for your work on improvingregions
!I think all of the general functionality of aperture-photometry has already been moved to
regions
, including the low-level Cythongeometry
functions and theMask
andBoundingBox
classes (although with some small differences). However, I am strongly not in favor of deprecating thephotutils
Aperture classes to be replaced by theregions
PixelRegion/SkyRegions classes or changing theaperture_photometry
function. Instead, I was envisioning that theregions
classes would be used as Mixin classes in the Aperture classes to replace the methods in common (i.e. the underlying geometry/Mask machinery), but keeping the Aperture-specific methods. One huge difference between them (beside API differences) is the Aperture classes are usually used to define multiple apertures, all with the same shape but different positions, within one object (i.e.positions
is an array of positions). Removing that functionality doesn’t make any sense to me. IIRC, it was decided long ago that theregions
objects would be singular (one shape, one position).Some other quick thoughts:
Changing to the regions
geometry
classes is a trivial change of the imports (they are identical copies)The
ApertureMask
class is calledMask
in regions. IMHO,Mask
seems too general a name (perhapsRegionMask
is better?)The
BoundingBox
class in photutils has a very usefulplot
convenience method that I would very much like to keep (for interactive work) that is currently not inregions
.CC: @astrofrog, @keflavich