[Octave-patch-tracker] [patch #8058] [image package new function] rgb2lab.m

[Patrick Noffke]

Follow-up Comment #1, patch #8058 (project octave):

I have several major issues with this submission:

1. You should compute the indexes once.  For example, when you compute L, you
have
L = Y;
L(L > 0.008856) = 116 * L(L > 0.008856).^(1/3) - 16;
L(L<= 0.008856) = 903.3 * L(L<= 0.008856) ;

Instead, compute Li = (L > 0.008856), then use Li or ~Li for all times you
need it.  Or really, you should compute Xi, Yi, and Zi (e.g. Yi = (Y >
0.008856)) first, then continue on.

2.  You are converting signed values (a* and b*) to uint8.  What good is this?
 If you wish to encode the a* and b* values using 8-bits (or 16-bits), follow
the ICC spec.  But this function should not automatically do that encoding
(that should be a separate function).  Just return the values as
double-precision.

3.  You are assuming the RGB data is a 3-dimensional array.  What if you
wanted to convert a single RGB value to L*a*b*?

4.  This does not conform with the standard for converting sRGB to L*a*b*. 
You should really try to match that standard.

5.  This should be part of the effort to add the color management functions to
octave (i.e. makecform, applycform, etc.).  The conversion from sRGB to L*a*b*
should be added as part of those (to-be-added) functions.

Also, in your example, you suggest you can use imshow to display your (uint8)
L*a*b* image.  That is bogus - imshow expects RGB images.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8058>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/