octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45456] hsv2rgb is too strict about its input


From: H. G.
Subject: [Octave-bug-tracker] [bug #45456] hsv2rgb is too strict about its input values
Date: Wed, 01 Jul 2015 18:05:21 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0

URL:
  <http://savannah.gnu.org/bugs/?45456>

                 Summary: hsv2rgb is too strict about its input values
                 Project: GNU Octave
            Submitted by: hardy
            Submitted on: Mi 01 Jul 2015 18:05:19 GMT
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.0.0
        Operating System: Any

    _______________________________________________________

Details:

Here is a little script to show the behavior (of "hsv2rgb.m") that I mean. It
also shows the context (using "imfilter" from the image package) where this
behavior disturbs the calculations:


pkg load image

H = 0.3.*ones(5);
S = 0.7.*ones(5);
V = 1.*ones(5);
HSV = cat(3, H, S, V);

f = fspecial('average',3);
V2 = imfilter(V, f);
overshoot = max(max(V2-1))
value_eps = eps
HSV2 = cat(3, H, S, V2);

RGB = hsv2rgb(HSV);
RGB2 = hsv2rgb(HSV2); % -> error


In the very last line, hsv2rgb throws an error, because its input values are
not in the expected (and formally  necessary) interval between 0 and 1. The V
value is slightly bigger than 1 (it is 1+eps in this example). This error is
formally correct behavior. Nevertheless I would like to consider this a BUG
because
* It disturbs the calculations (as shown in the more or less realistic
scenario in the script above.)
* Matlab does NOT throw an error here. I would guess, that Matlab just cuts
the V values down to 1.0 .

Notes:
* One might also argue that the bug is on the side of imfilter in this case.
Imfilter does return a slightly "wrong" result here (1+eps), it does not
conserve the "class" of its input values as claimed in its help text.
(Understanding "double value between 0 and 1" as a seperate "class" here.)
Along this line of argumentation the solution to this problem would be that
imfilter should strictly conserve its output values in the range 0..1. BUT:
Matlab decided to NOT solve it this way. The Matlab version of imfilter does
also return 1+eps for this example. So the Octave version of imfilter seems to
be fully Matlab compatible in this respect. Nevertheless the Matlab version of
hsv2rgb DOES cope with thoses slightly too big input values (and probably also
with slightly too small ones). Matlab also copes with 1+5*eps as input values,
for example.

* I used the imfilter function of image-2.4.0, but this is probably not
relevant here.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45456>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]