Thanks guys.  I pushed

http://hg.code.sf.net/p/octave/image/rev/f3f77f701848

http://hg.code.sf.net/p/octave/image/rev/b7fdda6a49a1

http://hg.code.sf.net/p/octave/image/rev/03cf78c6c0d6

Support for ND images is kind of there.  If imfilter ever gets around to support it, imsharpen will automatically support it too.

When I test the latest version of imsharpen (see comment #5) and add the "double" command to the call to rgb2lab (as proposed in comment #6), then I still see the very same tests failing. But many more tests also fail, and the failing test fail by a much bigger amount (bigger than just a value of 1).

The reason for this is: Using the "double" command on an uint8 image gives you floating point numbers, but still in the range of 0...255. This is not the kind of input values that rgb2lab wants to have. So I think it will not treat the values >1 properly and just use a very, very dark input image. I think this is no bug of rgb2lab (I expect Matlab does the very same), it's just that you should better use the "im2double" command for this type conversion. (But even this is unnecessary in this case, since rgb2lab does this conversion itself if necessary.)

I would assume that the remaing failing tests (failing by a difference of 1) are due to some slight discrepancy between the calculation methond in Avinoam's imsharpen.m and the Matlab version. I would guess that Matlab adds the number 1 somewhere explicitly in the code. (But I would love to be proven wrong, Avinoam. So go ahead and double check this.) If this turns out to be the case, then I am not sure if I really want to copy the Matlab behavior, or instead better stick to the "text book" version, that Avinoam's code properly mimics. We could then make a small note of this in the help string.

I first made a bunch of style changes (see inlined comments):

https://bitbucket.org/carandraug/octave-image/commits/da6638b3ce30000abbd148d5f64b82ff7f29cb17

And then this for reduced memory usage and performance

https://bitbucket.org/carandraug/octave-image/commits/447fa23083a2187e88aad4672b6d87504319e339

Reuse existing variables with inplace operators (less memory and faster operations). Also, instead of multiplying by a logical matrix to set elements to zero, it's better to just use the logical matrix to index and assign values to zero.

The failing tests are all for rgb images. Does the Matlab incompatibilities come from rgb2lab or maybe lab2rgb?  Sounded like it from comment #3.  Could we make those failing tests there too?

Attached a better version, fixed according to comment #1 (Thanks Hartmut).

• I changed the tolerance of the failing test to 1, so it will not fail, but still, there is 1 gray level difference between my results and Matlab results.

• texinfo was fixed.

 

• Line 54: copy/paste error was fixed.

• I removed the clipping. I did not find differences after the removal.

• More example were added for uint8 input.

• Wrong indentation was fixed.

• I added more tests for few values of "Amount". I hope it checks the Gaussian size.

And more more problem: I have tried to change

 Lab = rgb2lab (I);

to

 Lab = rgb2lab (double(I));

 
It fixed one test, but in made other test to fail. Any idea about this?

Please review the attached new version. Thanks.



(file #39973)

Thanks for this new function.

Some comments from my side:

• One test is (slightly) failing. Should we make it an xtest? (This depends on Carne's preference how to deal with those cases.)

• I get some texinfo errors on "help imsharpen": The "item" bullet points seem to be used outside of their intended context. And there might also be some missing curly brackets in the help text.

• line 54: There seems to be a copy and paste error, this error messages claims to be throughn by "impyramid".

• line 106,107: Is this clipping of L to the interval [0,100] Matlab compatible? (My experience from implementing the color conversion functions is, that Matlab normally does not clip, but just returns useless results. But I haven't checked the Matlab behavior in this very case.)

• some (one?) additional test with useful input images of class uint8 might be good. For example: A=zeros(7,7,'unit8'); A(4,4)=30; imsharpen(A);

• I am no expert on coding guidelines in the image package. But the missing identation of function blocks (2 space signes per line) popped to my eye. There might be more code style issues.

• line 62-65: The calculation of imsharpen_size looks funny. Is this Matlab compatible? Could you add a test for this (somehow)?