Open astrofrog opened 10 years ago
@astrofrog I am interested in this - if anyone has thought about how to implement it I'm interested, otherwise I may go ahead and do it myself this week
This image from Rosolowsky 2008 :
indicates we've been providing the "bijection" paradigm for flux extraction, but we're missing "clipping" and "extrapolation". So the suggestion is to implement "clipping" here ("extrapolation" would require more algorithm work, I think, whereas I assume that the "background flux" level is simple to access for a given structure?).
@tomr-stargazer - as far as I'm aware, none of us have worked on this yet, but indeed it should be relatively straightforward (at least for the 'clipping', the 'extrapolation' would be harder). I think Structures indeed have access to a background (I guess Structure.vmin
? or we might have to save the merge level of a structure). Please do give this a shot if you can!
The implementation is pretty simple. All you do is subtract off the minimum of the weights for a given level. For example in this line
return [np.nansum(i * self.values) / m0 for i in self.indices]
you'd change to
return [np.nansum(i * (self.values-np.min(self.values))) / m0 for i in self.indices]
I'm sure there's a deeply pythonic way of changing this code that I don't know. A clean way is have the value you subtract off default to zero for the bijection paradigm, and with appropriate flagging, become the minimum. Maybe pass in a zerolevel
function argument that defaults to np.zeros_like
and then becomes np.min
for bijection?
Great, @low-sky - thanks for zeroing in on the line of code I'd need to change.
A point of clarification: is there not a risk of subtracting a little too much flux if I simply use the minimum value contained inside the contour? e.g., if the contour is set at 0.5 K (representing the background emission level), and the lowest-valued pixel inside the contour is 0.55 K, then the above code would subtract 0.05 K too much from each pixel and underpredict the clipped flux? (For large dendrogram features this is likely not to be a problem, but in the regime below ~20 pixels per structure this may be significant?)
Let me know if I misunderstand something here.
@astrofrog A struct does have access to a Struct.vmin
but it appears to be computed as min(Struct.values())
, which wouldn't address my (possibly irrelevant) concern above.
@tomr-stargazer - no, you are right and we technically probably want to use the next pixel value down that links the structure to another structure. I thought we saved this at some point (the merge level) but I need to dig back through the code to understand if/why we removed it. Maybe @ChrisBeaumont remembers?
Hmm I'm not sure we save this (at least in the exported files). During construction we pass that data around
On Tuesday, February 24, 2015, Thomas Robitaille notifications@github.com wrote:
@tomr-stargazer https://github.com/tomr-stargazer - no, you are right and we technically probably want to use the next pixel value down that links the structure to another structure. I thought we saved this at some point (the merge level) but I need to dig back through the code to understand if/why we removed it. Maybe @ChrisBeaumont https://github.com/ChrisBeaumont remembers?
— Reply to this email directly or view it on GitHub https://github.com/dendrograms/astrodendro/issues/89#issuecomment-75838427 .
Chris Beaumont Senior Software Engineer Harvard Center for Astrophysics 60 Garden Street, MS 42 Cambridge, MA 02138 chrisbeaumont.org
Can we use the same kind of approach as in
height
to find the 'background' of a structure and compute a background-subtracted flux? (in addition to a raw total flux)