[Octave-bug-tracker] [bug #50708] [octave forge] (image) add demosaic.m

[Hartmut]

Follow-up Comment #13, bug #50708 (project octave):

I have reviewed the patch mentioned in comment #8. And I have started reading
some scientific literature about different demosaicing algorithms.

As a result, I would tend to NOT include this patch into the image package,
yet. I would very much prefer to use a better algorithm instead (but one that
is not patent encumbered), e.g. the Pei-Tam algorithm, as mentioned in
commment #11. For completeness I will also add my comments on the current
patch file near the bottom of this post.

1. Why not the bilinear algorithm?

The current patch (from comment #8) uses the bilinear interpolation method to
do the deomosaicing. When reading the literature, it seems to me that this
algorithm is the first and easiest thing one can do to achieve some kind of
demosaicing. But is seems to also have major drawbacks, since it generates
comparably strong artefacts. When we include this algorithm into the Octave
image package, and users use it to run Matlab code they found somewhere, then
they will get visibly worse results and probably complain about this in a bug
report sooner or later. Yes, having the current demosaic.m included into the
image package is a bit better than having no function for this at all. But it
is also a bit worse than having no function for this job (and honestly saying
this) because people excpect the function to work at least in a similar
quality than in Matlab. So in the long run we would just exchange one bug
report with another. And people using the (bilinear) demosaic function in the
meantime are also dissapointed because we need to break the compatibility of
our Octave code at some future time to introduce a better algorithm (as
Avinoam also seems to forsee in comment #9).

2. Why not the Malvar-He-Cutler algorithm?

Because it is somehow patent encoumbered. And the Octave team as not at all
the means to effectivly deal with this law topic.

3. Why the Pei-Tam algorithm (for example)?

This algorithm was suggested (by "anonymous") in comment #11. And after
reading the literature, it seems to me that it is
* not much more computational difficult than the simple bilinear method
* produces much better results that the simple bilinear method
* produces almost as good results as the Malvar-He-Cutler method that Matlab
claims to use. In the original Halvar-He-Cutler paper those authors also say
"Compared to Pei-Tam linear filters, our method produces slightly less visible
color fringing distortion, as well as a lower PSNR, at a slightly reduced
computational complexity." So it seems to do 90% of the job.
* I have (so far) not found any hint that it would also be patent
encoumbered.

The original paper of Pei-Tam can for example be found here:
https://pdfs.semanticscholar.org/8d68/4a67ae27a177a592baf96008d919b16d867b.pdf

4. Sorry

It must feel akward to only get this feedback more than 3 years after the
original submission of the patch. I fear this is also demotivating for Timothy
as original author. It is due to chronic shortage of manpower in our voluntary
project.

5. My comments on the current patch (from comment #8)

Here is nevertheless my detailed feedback on the current patch file:

* The copyright text should probably be adapted. The first line normally
mentions the author and his email address. The other three lines (after the
GPL text) with the author information could then be deleted.
* line 34: the use of size(size(I)) could be substituted by ndims(I) for
better readibility.
* There are a couple of places, where the (coding style) space sign after a
comma is missing. E.g. line 38.
* line 41: Couldn't we use isstring() instead of class=='str' ?
* All strings should be in double quotes (") and not single quotes ('), if I
remember the coding style right.
* The help string should also tell which algorithm is used (it currently does
this), that it is different from Matlab (it currently does this) but
comparably good in outcome (if it really is). And it should probably tell the
minimum size of the input image (for Pei-Tam this would also be 5x5, as in
Matlab, then).

6. How do we proceed?

Can anyone follow my argumentation? It feels sad to me to not use a decent
piece of code (as given in the current patch file), but I think it wouldn't be
good in the long run.

Is there a chance that someone (Avinoam? Timothy?) adapts the current patch
file, to properly use the Pei-Tam algorithm (or some other algorithm with
comparably performance)? I gave a link to the paper above. Literature says its
computational burden is similar to the bilinear algorithm. But it would still
need a major re-write of the algorithm part of this patch.

If anyone takes up this task, I would then be willing to again review the
code, and hopefully then include a demosaic function (with a decent algorithm)
into the image package.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?50708>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/