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

Homogenize Regularizer Interface #66

Open
JakobAsslaender opened this issue Dec 5, 2023 · 3 comments
Open

Homogenize Regularizer Interface #66

JakobAsslaender opened this issue Dec 5, 2023 · 3 comments

Comments

@JakobAsslaender
Copy link
Member

Just to keep track of things: There are a few inconsistencies between regularizers that we should maybe fix. To get a list started:

  • LLRRegularization takes the image size as the parameter shape, i.e. without extra (time) dimension. In contrast, TVRegularization takes the full matrix size.
  • LLRRegularization is applied along the last dimension, while TVRegularization takes dims as a parameter.
@nHackel
Copy link
Member

nHackel commented Dec 5, 2023

One idea we had in regards to the shape/size keyword is to move it out of the regularization terms and into the solvers.

Then the prox! call can be invoked with a reshaped array. For the reg. terms that just perform element-wise this has no effect and the other terms we have atm would apply the reshape anyways.

A default value for the shape could then be size(A,2) or size(AHA, 1) respectively and if multidimensional solutions are wanted then a user can supply the (for example image) size

@JakobAsslaender
Copy link
Member Author

Interesting idea. But I do think there is some logic to keeping the shape in the regularizers. E.g., if you have 5D data, say, 3 spatial and 2 other dimensions, it might make sense to have the flexibility to have a 2D TV along those extra dimensions, or, instead, do an LLR along the last to concatenate. I had in mind to change the LLR code to take the full reshape size and a dims::Number keyword.

@tknopp
Copy link
Member

tknopp commented Dec 5, 2023

yes, if only a subset of dimensions is to be considered, we should use the dims keyword, which can not only be a number but also a range or a vector.

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

No branches or pull requests

3 participants