Wed 02 Apr 2014 04:06:08 PM UTC, comment #10:
After talks on IRC, the bug reported said this was, after all, a bug on their code, and not on the image package.
Closing as invalid.
|
Mon 24 Mar 2014 10:37:16 PM UTC, comment #9:
Hello Jordi,
> ... (and I still can't tell what's the output you consider correct)
The results we consider correct are:
3.6 - 2.0.0-3:
...
stats(1).BoundingBox
ans = 0.50000 36.50000 39.00000 64.00000
The results we consider incorrect are:
3.8 - 2.2.1-1: stats(1).BoundingBox
ans = 0.50000 70.50000 32.00000 50.00000
Please note that we do not rely on any bwlabel order in our use it, it just happens that in both octave sessions I ran, the [same] object[*] we refer to to expose the problem is at the same position, 1, in the structure
returned by regionprops:
[*] in sm-mask2.png [attached], it is the first top left object,
which looks like an inverted triangle as you probably understood by
now, but just to clarify in case...
Cheers,
David
|
Mon 24 Mar 2014 09:51:05 PM UTC, comment #8:
> Since this is critical, I can send you a fix within 24 hours. Can you
> pay in bitcoins? 0.2 BTC seems like a reasonable price. If not, I can
> accept Paypal or bank transfers.
Hello Jordi,
Thank you for your message [and ping on irc], sorry not having responded yet, I'm extremely busy, overloaded actually, with our next release and deadline. We do not hope [the lab I'm working for] to get a patch before our deadline anymore. I will block updates on all but one machines [to test future releases] until fixed.
[ I'll answer coment #6 asap ]
Cheers,
David
|
Mon 24 Mar 2014 08:07:39 PM UTC, comment #7:
Dear all
I have been following this discussion and it affects some of my own results. Something is not working correctly either in BWLabel and/or in RegionProps. When I extract a binary region from an image by using bwlabel and getting the bounding box coordinates from regionprops, the extracted region is not correct. It seems to be displaced to the right in relation to the correct coordinates. As it was mentioned that bwlabel changes between the recent versions, I wonder if there is a bug there that could be causing this behavior.
Thank you
Prof. Sidnei Paciornik
|
Mon 24 Mar 2014 12:31:44 AM UTC, comment #6:
I have done a preliminary analysis of the problem, pending your approval of my fees. I will wait
It appears to me that on 3.8 and the image package 2.2.0, the bounding box at least is correct. If you're seeing unexpected output (and I still can't tell what's the output you consider correct), then I suspect it's more likely that the problem lies in the image labelling of bwlabel. Note that the implementation of bwlabel changed between the two versions that you're testing, so the order of the labels may be different. I would need more information from you to determine if this is the problem you're experiencing.
|
Sun 23 Mar 2014 11:34:04 PM UTC, comment #5:
> and please, help us asap: it is a critical bug
Since this is critical, I can send you a fix within 24 hours. Can you pay in bitcoins? 0.2 BTC seems like a reasonable price.
If not, I can accept Paypal or bank transfers.
|
Fri 21 Mar 2014 08:58:55 PM UTC, comment #4:
No Carnë is not being silly!!
in your file you have:
addpath("/usr/lpdi/projects/octave/ocom")
addpath("/usr/lpdi/projects/octave/ocom/tests")
I certainly don't have want to add those paths!!
I spent 1 hr yesterday to get you software to run!!!
And then did not know what I was suppose to do or see.
So I really think you should listen to what is being said!
|
Fri 21 Mar 2014 06:27:11 PM UTC, comment #3:
Dear Carnë,
I am sorry but you're being silly here, and loose my time, which believe me, is
as precious as yours: did you just even read it? It is not really a 'script',
just a collection of elementary steps, for your own convinience, at least I
thought so:
though in order for you not to blindly complain about our scrap, which
is not the cause of the problem anyway, I uploaded a new version of the
already scrapped image, and the 'script' :)
So please save us some precious time here, it should not take more then a minute
to save it, save the image, then:
chmod a+x bb-test2.sh
./bb-test2.sh . sm-mask2 png
Or copy paste these elementary steps in your prefered octave session... and
please, help us asap: it is a critical bug [I know your are busy, but since it
is a critical bug, we hope that the time you allocate to octave, as a hobby,
will grab your attention until solved, and with the highest possible priority].
Many thanks in advance,
Cheers,
David
ps: why don't you do that with an image or a mat of yours then, and compare the
results between 2.0.0 and 2.2.1? Did you [the team I mean] tested regionprops
before to release? Do you [the team] have a strong test case for every
octave-image function that you run before every release? Are you telling me that
running logical and bwlabel could possibly be the problem?
(file #30992, file #30993)
|
Fri 21 Mar 2014 12:55:03 PM UTC, comment #2:
Any chance you could give us the exact input required to pass to regionprops to replicate this bug?
Not a script, that reads a separate image, that calls a separate function, where in its middle gives a result that you were not expecting. Can you provide us with a file (maybe a mat file) with the matrix L so that we only have to run regionprops (L, "BoundingBox").
Also, did you try Octave 3.8.0 with the image package 2.0.0? And Octave 3.6 with the image package 2.2.0?
|
Fri 21 Mar 2014 04:31:34 AM UTC, comment #1:
regionprops is not a part of core Octave, but rather the image package from Octave Forge. Marking the bug as "Octave Forge".
|
Thu 20 Mar 2014 10:49:26 PM UTC, original submission:
Dear maintainer,
I believe there is serious [critical, imo] bug in regionprops 'boudingbox'. Here is a sample test
case:
save the attach script, chmod a+x;
save the small test mask image and
run:
bb-test . sm-mask png
the results speak for themselves.
Here below the set of values per octave/octave-image version [availble in the debug session,
copied here to help
#{
3.6 - 2.0.0-3: stats(i).BoundingBox
ans = 0.50000 36.50000 39.00000 64.00000
x1 = 1
x2 = 39
y1 = 37
y2 = 100
3.8 - 2.2.1-1: stats(i).BoundingBox
ans = 0.50000 70.50000 32.00000 50.00000
x1 = 1
x2 = 32
y1 = 71
y2 = 120
}#
|