-
Notifications
You must be signed in to change notification settings - Fork 11
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
TV/TSV regularizer is not equivalent to source #153
Comments
Thanks for catching this. I guess the difference between our implementations is how edges should be handled. In the EHT implementation, I think this would be equivalent to saying there is a penalty if the edge of the image isn't close to 0. We should discuss if that behavior in the TV/TSV regularizers is important to us (and possibly change). We've mostly been working with images that have edge values close to 0, so we've sort of side-stepped this issue, I think. It probably makes sense to adopt the EHT definition (and cite their codebase in this routine, specifically). |
…rch adaptation, but still distinct from eht imaging.
In fe9c786 I implemented your updates using The definition of TV in EHT IV is So from a given reference pixel, it's a right pixel minus current and a bottom pixel minus current. There's a question of what to do when l=L and m=M and l+1 and m+1 would be off the image entirely. You could pad the image with zeros, but then you're assuming that as a reference value. I.e., a constant-valued image should in spirit have a TV score of 0. But under this definition there would be a penalty between the last constant-value and the padded 0. In practice this is a good thing, since you always want to be imaging all of your flux in a dataset anyway, so your image boundaries should be 0, otherwise you have bigger problems. Whereas in our implementation we only compute TV between valid pixels in the array. This is fine, but results in One other potential solution is to calculate diff_mm and diff_ll as we do, then append a row of zeros (i.e., diff is zero) to augment each array to make them the same shape. This is technically more correct as regards the definition since it treats the extra image edge as extrapolated nearest-neighbor (i.e., diff = 0), but as I previously commented, the push towards 0 at edges is probably diserable anyway. @kadri-nizam |
While profiling for bottlenecks in the code, I happened to inspect the implementation of the TV regularizer and noticed that it is slightly different from the way it is implemented in the cited source.
I don't think the difference will affect the results very much, but I thought I'd point it out. Feel free to close this if it's not an issue.
Comparison
Here's an MWE that illustrates this. First I'll define the variables we need.
MPoL Implementation
After refactoring the code to use built-in torch functions to facilitate easier comparison, the current MPoL implementation is:
eht-imaging Implementation
The biggest difference lies in the way that the finite difference is taken. Here, they add a zero-padding to the end of the tensor in the dimension that they are taking the difference.
Loss Values
The EHT implementation results in a larger loss compared to the implementation of MPoL.
The text was updated successfully, but these errors were encountered: