The current undertakings summarized in the big picture document show a large diversity of approaches when performing Compressed Sensing or Compressive Sensing. And yet, if one were new to the field, what would be required to design a specific means for acquiring compressed samples ?
One would first have to know the domain specific characteristics of the dataset, that is we take for granted that it is understood that the domain specific signals are sparse in some basis. Given that information, one would then perform some type of trade studies on how the processes for measurement and reconstruction are eventually yielding satisfactory data. But here lies a problem that has also plagued wavelets a decade ago: too much choice and a predisposition to always deal with 1-d information.
On the measurement side, we have about 26 ways of performing compressed measurements. On the reconstruction side, we have 17 different algorithms. I am not saying they are a good fit to one another, but we are facing, today, a potential of about 442 different implementations for the same problem. Let us not even talk about the fact that several dictionaries of sparse functions could be used in the reconstruction of one test case. Obviously, a hardware solution will remove many of the measurement and reconstruction schemes either based on engineering trade-offs or because of the nature of the signal. Yet, it would seem that a more automated evaluation of the phase space of possibilities might be helped by a general framework like the one implemented in Sparco. The richness of potential combinations for a specific signal type seem painless to implement. After I mentioned some installation issues, Michael P. Friedlander and Ewout van den Berg have written some work-around and it now works flawlessly after a clean install. They just released that version (v.1.1.3) on the Sparco website. They are also looking for feedbacks and users.
Michael and Ewout mentioned that they wanted Sparco to be relatively agnostic in terms of the solver used, but it would seem to me that there should also be a similar concern with regards to measurement means. In particular, one should probably think of a way to add measurements and solvers at once so that it can be run directly within Sparco.
Credit: NASA/JPL/Space Science Institute, Janus one of Saturn's moon, photograph released today.
One would first have to know the domain specific characteristics of the dataset, that is we take for granted that it is understood that the domain specific signals are sparse in some basis. Given that information, one would then perform some type of trade studies on how the processes for measurement and reconstruction are eventually yielding satisfactory data. But here lies a problem that has also plagued wavelets a decade ago: too much choice and a predisposition to always deal with 1-d information.
On the measurement side, we have about 26 ways of performing compressed measurements. On the reconstruction side, we have 17 different algorithms. I am not saying they are a good fit to one another, but we are facing, today, a potential of about 442 different implementations for the same problem. Let us not even talk about the fact that several dictionaries of sparse functions could be used in the reconstruction of one test case. Obviously, a hardware solution will remove many of the measurement and reconstruction schemes either based on engineering trade-offs or because of the nature of the signal. Yet, it would seem that a more automated evaluation of the phase space of possibilities might be helped by a general framework like the one implemented in Sparco. The richness of potential combinations for a specific signal type seem painless to implement. After I mentioned some installation issues, Michael P. Friedlander and Ewout van den Berg have written some work-around and it now works flawlessly after a clean install. They just released that version (v.1.1.3) on the Sparco website. They are also looking for feedbacks and users.
Michael and Ewout mentioned that they wanted Sparco to be relatively agnostic in terms of the solver used, but it would seem to me that there should also be a similar concern with regards to measurement means. In particular, one should probably think of a way to add measurements and solvers at once so that it can be run directly within Sparco.
Credit: NASA/JPL/Space Science Institute, Janus one of Saturn's moon, photograph released today.
No comments:
Post a Comment