Consider providing a way to provide 'background subtracted flux' for structures

[astrofrog]

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)

[tomr-stargazer]

@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

[tomr-stargazer]

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?).

[astrofrog]

@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!

[low-sky]

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?

[tomr-stargazer]

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.

[tomr-stargazer]

@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.

[astrofrog]

@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?

[ChrisBeaumont]

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

---