patchGNU Octave - Patches: patch #8713, image package: new color...


patch #8713: image package: new color conversion functions: rgb2lab etc.

Submitter:  Hartmut <hardy>
Submitted:  Mon 10 Aug 2015 06:18:46 PM UTC
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Tue 05 Jul 2016 07:55:23 PM UTC, comment #10: 

Thanks for pushing the patch.

regarding 2) The only place where I intentionally broke perfect Matlab compatibility, are the functions rgb2xyz and xyz2rgb. This is noted in the corresponding help strings (rgb2xyz and rgb2lab), as well as in the source code (rgb2xyz and xyz2rgb). In those two cases, the alternative and fully Matlab compatible transformation matrix is even written down in the source code, but currently not used. I intentionally sticked to the transformation matrices from the quoted book, they also gave better roundtrip accuracy for RGB -> XYZ -> RGB and RGB -> LAB -> RGB. NOTE: While this patch was waiting to be accepted, Matlab changed the behavior of their color conversion functions (with release R2016a, "improved precision and numerical accuracy"). I have not checked what this change was, but I could imagine that our color conversion functions in Octave are now even more Matlab compatible than before.

regarding 1,4,5) I agree those would be good code improvements. Should I find time for this, I might do this. But currently it doesn't look like it. So anyone should feel free to improve the code in the mentioned manner.

regarding 3) I am not sure how tests would look like, that use "computed values" instead of the current decimal values. The only idea I have there, would result in massive code duplication. The current numbers are the result of extensive Matlab testing, so that all of those test do pass on Matlab (before R2016a) and on Octave simultanously (except for the mentioned exceptions under point 2).

Hartmut <hardy>
Fri 17 Jun 2016 01:48:35 PM UTC, comment #9: 

Yes. I'm sorry for the high delay. Thank you for the patch.

There are a couple of nitpicks things I would prefer though which you may want to address:

1) I would prefer to use a whitepoint function (missing function) instead of hard coded whitepoint values (this would also allow to implement the illuminant option in this functions)

2) I'm not super familiar with this topic so I can't evaluate the differences you made on purpose from Matlab.

3) I would prefer that the tests compared the results with computed values instead of 3 decimal numbers. So that future changes that heavily change the precision of results.

4) Avoiding many temporary variables would increase performance. For example, when converting rgb 2 lab, there is a time where Octave has the image in rgb, xyz, and lab colorspace in memory at the same time.

5) In the conversions where matrix multiplication is not used, the logic in colorspace_conversion_input_check can be simplified and a permute removed. That further reduces computation (see for an example).

Carnë Draug <carandraug>
Group Member
Tue 31 May 2016 06:10:39 PM UTC, comment #8: 

I've just now realized, that all the new color conversion functions have already arrived in the image repo today.

So if there aren't any more wishes for fine tuning or code corrections, then this ticket can be closed.

Hartmut <hardy>
Tue 31 May 2016 06:06:41 PM UTC, comment #7: 

Thanks for looking into this. I do like the approach of using a private copy of iscolormap, until the image package will depend on Octave 4.2.

Sorry for the confusion, I think I always also used the iscolormap function from the dev branch (since I was envolved in its generation, see bug #45456). I just mixed this up in my comment #2 (which was written 2 months after my actual coding...).

Any more comments about the functionality of those new color conversion functions?

Hartmut <hardy>
Mon 30 May 2016 10:23:21 PM UTC, comment #6: 

I took another look at this and the tests still fail. The reason is simple. Several of the tests convert a colourmap back and forth between colourspaces, some of which do have outside the interval [0 1]. The private functions make use of iscolormap which in octave 4.0 will return false for values outside the [0 1] range.

That explains why Avinoam tests pass in Octave development sources. It does not explain how they pass on your system Harmut. I'm guessing you have patched your own Octave installation.

I have added a copy of iscolormap into private from the current core development sources which means the tests now pass:

Carnë Draug <carandraug>
Group Member
Tue 26 Apr 2016 02:08:28 PM UTC, comment #5: 

I have tested again:

>> test lab2rgb
PASSES 24 out of 24 tests
>>  test lab2xyz
PASSES 24 out of 24 tests

@Carnë: Could you please check this again?

Avinoam Kalma <avinoam>
Group Member
Wed 04 Nov 2015 12:30:19 PM UTC, comment #4: 

> [...]
> How can we make sure that the function from the image PACKAGE subfolder "inst/private/" and not the function from the Octave CORE folder "scripts/image/private" is used by my new functions?
> [...]

Stuff inside a directory named private will only be seen by the functions on its parent directory. This cannot be the reason for why the tests failed on my system. I look into this again.

Carnë Draug <carandraug>
Group Member
Tue 27 Oct 2015 11:00:53 AM UTC, comment #3: 

I have tested these 6 six functions with latest versions of
Octave (dev branch) and image package (2.5.0, not yet released),
under Win-7 and all 6 tests passed.

Avinoam Kalma <avinoam>
Group Member
Mon 12 Oct 2015 06:50:00 PM UTC, comment #2: 

I have written and tested this bundle of functions with Octave 4.0.0 (release version), and the dev version of the image package (directly from the hg repository, at the time of the patch creation, several weeks ago now.) And, as you probably expected, I have NOT seen any test fail.

I suspect that maybe the two versions of colorspace_conversion_input_check.m became mixed up. You, Carne, submitted ONE version into Octave core some month ago. And I have submitted ANOTHER slightly changed version of the very same function into the "private" subdirectory of the image package. And the "Carne version" will make some tests of my new functions fail!

So if you are using the dev version of Octave as well as the dev version of the image package, then Octave might mix up which of those two version of colorspace_conversion_input_check.m it should use.

Or do I need to "publish" the private function inside the image package somewhere? I think this narrows down to the question: How can we make sure that the function from the image PACKAGE subfolder "inst/private/" and not the function from the Octave CORE folder "scripts/image/private" is used by my new functions? Or should I better rename my new versions of those two private helper functions in order to make this work?

Hartmut <hardy>
Mon 12 Oct 2015 03:37:22 PM UTC, comment #1: 

I'm adding this functions to the image package now but they fail the tests.

What version of Octave did you use to write this functions and tests?

octave> test lab2xyz
***** test
 lab_map = rand (64, 3);
 lab_map(:,1) = lab_map(:,1) .* 100;
 lab_map(:,2) = lab_map(:,2) .* 254 - 127;
 lab_map(:,3) = lab_map(:,3) .* 254 - 127;
 assert (xyz2lab (lab2xyz (lab_map)), lab_map, 1e-5);
!!!!! test failed
lab2xyz: LAB must be a colormap or LAB image

octave> test lab2rgb
***** test
 lab_map = rand (64, 3);
 lab_map(:,1) = lab_map(:,1) .* 100;
 lab_map(:,2) = lab_map(:,2) .* 254 - 127;
 lab_map(:,3) = lab_map(:,3) .* 254 - 127;
 assert (rgb2lab (lab2rgb (lab_map)), lab_map, 5e-3);
!!!!! test failed
lab2rgb: LAB must be a colormap or LAB image

Carnë Draug <carandraug>
Group Member
Mon 10 Aug 2015 06:18:46 PM UTC, original submission:  

Here is a patch with several new color conversion functions:

rgb2xyz, xyz2rgb
xyz2lab, lab2xyz
rgb2lab, lab2rgb

Those functions are all new to Octave. I am the author and the algorithms are taken from the (cited) book of Burger and Burge "Digitale Bildverarbeitung" (2015). (There is an english version of the book as well.)

The functions are reasonably Matlab compatible. At some points in the code I intentionally took a slightly less Matlab compatible approach, in order to better fulfill the CIE standards with those functions. But for practical purposes those functions are Matlab compatible.

All those functions use (a slightly adapted version of) the private funtions

colorspace_conversion_input_check.m and colorspace_conversion_revert.m

that Carne introduced recently to the color conversion functions in Octave core. I have duplicated those two helper functions into the image package. You have a more clever approach to this, just let me know.

I tried to follow the Octave coding styles, but I'm not sure I succeded with it everywhere. Ther are also help texts, source references and a bunch of tests included.

I would appreciate any feedback and would be happy to see those new functions in the image package at some time :)


Hartmut <hardy>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #34620:  new_colorconversion_functions_rgb2lab_etc.patch added by hardy (37KiB - text/x-diff - patch with new color conversion functions)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-06-17 carandraug StatusNone Done
        Open/ClosedOpen Closed
    2015-08-10 hardy Attached File- Added new_colorconversion_functions_rgb2lab_etc.patch, #34620

    Back to the top

    Powered by Savane 3.12