bugGNU Octave - Bugs: bug #43505, build gm with quantum-depth=16 in...

 
 

bug #43505: build gm with quantum-depth=16 in mxe octave

Submitted by:  Markus Bergholz <markuman>
Submitted on:  Thu 30 Oct 2014 04:50:58 PM UTC  
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  other Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 25 May 2016 07:55:42 PM UTC, comment #63: 

works on 64 as well so pushed for mxe-octave:

http://hg.octave.org/mxe-octave/rev/5e57f06cd77f

John Donoghue <lostbard>
Project Member
Wed 25 May 2016 07:08:11 PM UTC, comment #62: 

running on the 4.0.2 official gui, it crashes doing the clear all, which I believe was documented as on issue elsewhere.

running on the official 4.0.2 no gui,

>> test imwrite
PASSES 19 out of 19 tests
>> clear all
>> test imwrite
***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 1, "uint8");
r  = write_and_read (".tif", gray);
assert (r, gray)
!!!!! test failed
'is_valid_index_option' undefined near line 76 column 11
>>

John Donoghue <lostbard>
Project Member
Wed 25 May 2016 06:54:42 PM UTC, comment #61: 

>> test imwrite
PASSES 19 out of 19 tests
>> clear all
>> test imwrite
***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 1, "uint8");
r  = write_and_read (".tif", gray);
assert (r, gray)
!!!!! test failed
'is_valid_index_option' undefined near line 76 column 11
>>

I saw that back on comment #39, but then could not reproduce it.

The clear all clears out private functions, and then doesn't know how to reload them ?

John Donoghue <lostbard>
Project Member
Wed 25 May 2016 06:32:33 PM UTC, comment #60: 

Could you please also check this:

>> test imwrite
PASSES 20 out of 20 tests
>> clear all
>> test imwrite
***** testif HAVE_MAGICK
gray = randi (255, 10, 10, 1, "uint8");
r = write_and_read (".tif", gray);
assert (r, gray);
!!!!! test failed
'is_valid_index_option' undefined near line 70 column 11

Avinoam Kalma <avinoam>
Project Member
Wed 25 May 2016 06:15:55 PM UTC, comment #59: 

I am currently compiling a w64 version just to verify it runs and then will push the patch up

John Donoghue <lostbard>
Project Member
Wed 25 May 2016 06:13:59 PM UTC, comment #58: 

The patch https://savannah.gnu.org/bugs/download.php?file_id=32344 should be applied to mxe-octave

Avinoam Kalma <avinoam>
Project Member
Wed 25 May 2016 03:52:53 PM UTC, comment #57: 

Since John's tests was successful I'm marking this as fixed and closing.

Rik <rik5>
Project Administrator
Wed 25 May 2016 12:18:40 PM UTC, comment #56: 

Rebuild worked:

test imwrite
PASSES 19 out of 19 tests

John Donoghue <lostbard>
Project Member
Tue 24 May 2016 09:03:44 PM UTC, comment #55: 

tip of stable branch

There might have been crud around, so will do a new rebuild and see if it works then

John Donoghue <lostbard>
Project Member
Tue 24 May 2016 08:56:13 PM UTC, comment #54: 

Stable meaning released 4.0.2 version, or tip of the stable branch? After 4.0.2 it was moved into liboctinterp so there shouldn't be an oct-file with that name anymore.

Mike Miller <mtmiller>
Project Administrator
Tue 24 May 2016 08:44:31 PM UTC, comment #53: 

And

>> _magick_read_

error: library open failed: C:\Octave\Octave-4.0.2\lib\octave\4.0.2\oct\x86_64-w64-mingw32\__magick_read__.oct

John Donoghue <lostbard>
Project Member
Tue 24 May 2016 08:35:22 PM UTC, comment #52: 

On mine with a stable build:

>> test imwrite
***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 1, "uint8");
r  = write_and_read (".tif", gray);
assert (r, gray)
!!!!! test failed
library open failed: C:\Octave\Octave-4.0.2\lib\octave\4.0.2\oct\i686-w64-mingw32\__magick_read__.oct

Maybe my build wasn't clean

John Donoghue <lostbard>
Project Member
Tue 24 May 2016 04:58:21 AM UTC, comment #51: 

As in comment #48, imwrite and imread passes all the tests. Tested with patch from bug #47968, on 32 bit Octave on Win-7, with qm=16.

Avinoam Kalma <avinoam>
Project Member
Mon 23 May 2016 08:05:07 PM UTC, comment #50: 

I hadn't tried 64 bit, but will try a new build and verify

John Donoghue <lostbard>
Project Member
Mon 23 May 2016 05:57:34 PM UTC, comment #49: 

So this can be committed now? AFAICT the failing tests were the only thing holding this up. The stable branch has the fix for bug #47746, so please test that everything works there (both 32-bit and 64-bit would be nice, since I had different behavior on Debian 32-bit vs 64-bit).

Mike Miller <mtmiller>
Project Administrator
Sun 22 May 2016 06:55:14 PM UTC, comment #48: 

passed 20/20 for imwrite with the patch on bug #47746 applied

John Donoghue <lostbard>
Project Member
Thu 19 May 2016 04:32:50 PM UTC, comment #47: 

I will take a look

John Donoghue <lostbard>
Project Member
Thu 19 May 2016 03:58:56 PM UTC, comment #46: 

I've also submitted a patch on bug #47746, you can test it and see if it changes/fixes anything in the Windows build.

Mike Miller <mtmiller>
Project Administrator
Thu 19 May 2016 03:45:20 PM UTC, comment #45: 

I don't know if this will make a difference, but I cleaned up imread.m and it's private implementation in _imread_.m.  See this cset http://hg.savannah.gnu.org/hgweb/octave/rev/c86cacc3aaf4.

One of the things I re-coded was the parsing of the Index option.

Rik <rik5>
Project Administrator
Wed 18 May 2016 09:04:53 PM UTC, comment #44: 

For the test that fails, its not the magick_read.cc:1113, but magick_read.cc:1147.

John Donoghue <lostbard>
Project Member
Wed 18 May 2016 06:48:05 PM UTC, comment #43: 

and I just noticed that the 'gray' prints don't occur for the test that fails, which I guess is why I don't see any issues with the values that are printed.

John Donoghue <lostbard>
Project Member
Wed 18 May 2016 06:40:06 PM UTC, comment #42: 

I will take back comment #40 - running the full  _run_tests_ and the issue reappears.

However, looking at all of the printouts of gray, and none seem to have anything except lots of 0s after the decimal point.

John Donoghue <lostbard>
Project Member
Wed 18 May 2016 05:10:16 PM UTC, comment #41: 

Ok, I don't know what is going on here, but it looks very different from bug #47746. The is_valid_index_option is a subfunction of _imread_.m, not sure how that can be undefined.

Mike Miller <mtmiller>
Project Administrator
Wed 18 May 2016 04:59:46 PM UTC, comment #40: 

And if I comment out any calls to is_valid_index_option within _imread_.m, then  test imwrite passes 20 out of 20 tests.

John Donoghue <lostbard>
Project Member
Tue 17 May 2016 09:00:07 PM UTC, comment #39: 

If I manually run the test code that fails, when I get the imread in write_and_read_format, I get:

>> [r, cmap, a] = imread ("test.tif", "Index", "all");
error: 'is_valid_index_option' undefined near line 76 column 11
error: called from
    __imread__ at line 76 column 5
    imageIO at line 117 column 26
    imread at line 106 column 30

If I run the command without Index all - no error:

>> [r, cmap, a] = imread ("test.tif");

And if I run the test without the Index all options in it, that test passes,

however then on another test:

***** testif HAVE_MAGICK
gray = randi (255, 10, 10, 1, 5, "uint8");
r    = write_and_read (".tif", gray);
assert (r, gray);
!!!!! test failed
ASSERT errors for:  assert (r,gray)

  Location  |  Observed  |  Expected  |  Reason
     .         O(10x10)   E(10x10x1x5)   Dimensions don't match
>>

John Donoghue <lostbard>
Project Member
Tue 17 May 2016 08:49:34 PM UTC, comment #38: 

precision added, but I don't see any decimals other than 0s.

When I run test imwrite it still fals though, but still what was printed out in the debug didn't show any decimals.

***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 3, 5, "uint8");
alpha = randi (255, 10, 10, 1, 5, "uint8");
[r, ~, a] = write_and_read (".tif", gray, "Alpha", alpha);
assert (r, gray);
assert (a, alpha);
!!!!! test failed
ASSERT errors for:  assert (r,gray)

  Location  |  Observed  |  Expected  |  Reason
(1,1,1,1)       212          213        Abs err 1 exceeds tol 0
(2,1,1,1)        35           36        Abs err 1 exceeds tol 0
(3,1,1,1)        64           65        Abs err 1 exceeds tol 0
(4,1,1,1)       140          141        Abs err 1 exceeds tol 0
(5,1,1,1)       173          174        Abs err 1 exceeds tol 0
(6,1,1,1)        19           20        Abs err 1 exceeds tol 0
(7,1,1,1)       251          252        Abs err 1 exceeds tol 0
(8,1,1,1)        49           50        Abs err 1 exceeds tol 0
(9,1,1,1)       229          230        Abs err 1 exceeds tol 0
(10,1,1,1)       28           29        Abs err 1 exceeds tol 0
(1,2,1,1)       199          200        Abs err 1 exceeds tol 0
(2,2,1,1)       160          161        Abs err 1 exceeds tol 0
(3,2,1,1)       149          150        Abs err 1 exceeds tol 0
(4,2,1,1)       171          172        Abs err 1 exceeds tol 0
(5,2,1,1)       137          138        Abs err 1 exceeds tol 0
(6,2,1,1)       145          146        Abs err 1 exceeds tol 0
(7,2,1,1)       148          149        Abs err 1 exceeds tol 0

John Donoghue <lostbard>
Project Member
Tue 17 May 2016 03:10:44 PM UTC, comment #37: 

Ok, you might need to add some more precision to this method of debugging, maybe "%.16lf". And show the values before and after calling a Java function that triggers the test failures in Windows.

The value I see on 32-bit Linux when this fails is something like 256.999999999998 rather than 257.

Mike Miller <mtmiller>
Project Administrator
Tue 17 May 2016 11:51:52 AM UTC, comment #36: 

Added to _magick_read_.cc

                for (octave_idx_type row = 0; row < nRows; row++)
                   {
                     const double grey = double (*img_fvec) / divisor;
+printf("gray %d %lf\n", (int)row, grey);
                     Magick::Color c (grey, grey, grey);
                     pix[GM_idx] = c;
                     img_fvec++

When running imwrite (uint8(0:255), "test.tif") :

>> imwrite (uint8(0:255), "test.tif")
gray 0 0.000000
gray 0 257.000000
gray 0 514.000000
gray 0 771.000000
gray 0 1028.000000
gray 0 1285.000000
gray 0 1542.000000
gray 0 1799.000000
gray 0 2056.000000
gray 0 2313.000000
gray 0 2570.000000
gray 0 2827.000000
gray 0 3084.000000
gray 0 3341.000000
gray 0 3598.000000
gray 0 3855.000000
gray 0 4112.000000
gray 0 4369.000000
gray 0 4626.000000
gray 0 4883.000000
gray 0 5140.000000
gray 0 5397.000000
gray 0 5654.000000
gray 0 5911.000000
gray 0 6168.000000
gray 0 6425.000000
gray 0 6682.000000
gray 0 6939.000000
gray 0 7196.000000
gray 0 7453.000000
gray 0 7710.000000
gray 0 7967.000000
gray 0 8224.000000
gray 0 8481.000000
gray 0 8738.000000
gray 0 8995.000000
gray 0 9252.000000
gray 0 9509.000000
gray 0 9766.000000
gray 0 10023.000000
gray 0 10280.000000
gray 0 10537.000000
gray 0 10794.000000
gray 0 11051.000000
gray 0 11308.000000
gray 0 11565.000000
gray 0 11822.000000
gray 0 12079.000000
gray 0 12336.000000
gray 0 12593.000000
gray 0 12850.000000
gray 0 13107.000000
gray 0 13364.000000
gray 0 13621.000000
gray 0 13878.000000
gray 0 14135.000000
gray 0 14392.000000
gray 0 14649.000000
gray 0 14906.000000
gray 0 15163.000000
gray 0 15420.000000
gray 0 15677.000000
gray 0 15934.000000
gray 0 16191.000000
gray 0 16448.000000
gray 0 16705.000000
gray 0 16962.000000
gray 0 17219.000000
gray 0 17476.000000
gray 0 17733.000000
gray 0 17990.000000
gray 0 18247.000000
gray 0 18504.000000
gray 0 18761.000000
gray 0 19018.000000
gray 0 19275.000000
gray 0 19532.000000
gray 0 19789.000000
gray 0 20046.000000
gray 0 20303.000000
gray 0 20560.000000
gray 0 20817.000000
gray 0 21074.000000
gray 0 21331.000000
gray 0 21588.000000
gray 0 21845.000000
gray 0 22102.000000
gray 0 22359.000000
gray 0 22616.000000
gray 0 22873.000000
gray 0 23130.000000
gray 0 23387.000000
gray 0 23644.000000
gray 0 23901.000000
gray 0 24158.000000
gray 0 24415.000000
gray 0 24672.000000
gray 0 24929.000000
gray 0 25186.000000
gray 0 25443.000000
gray 0 25700.000000
gray 0 25957.000000
gray 0 26214.000000
gray 0 26471.000000
gray 0 26728.000000
gray 0 26985.000000
gray 0 27242.000000
gray 0 27499.000000
gray 0 27756.000000
gray 0 28013.000000
gray 0 28270.000000
gray 0 28527.000000
gray 0 28784.000000
gray 0 29041.000000
gray 0 29298.000000
gray 0 29555.000000
gray 0 29812.000000
gray 0 30069.000000
gray 0 30326.000000
gray 0 30583.000000
gray 0 30840.000000
gray 0 31097.000000
gray 0 31354.000000
gray 0 31611.000000
gray 0 31868.000000
gray 0 32125.000000
gray 0 32382.000000
gray 0 32639.000000
gray 0 32896.000000
gray 0 33153.000000
gray 0 33410.000000
gray 0 33667.000000
gray 0 33924.000000
gray 0 34181.000000
gray 0 34438.000000
gray 0 34695.000000
gray 0 34952.000000
gray 0 35209.000000
gray 0 35466.000000
gray 0 35723.000000
gray 0 35980.000000
gray 0 36237.000000
gray 0 36494.000000
gray 0 36751.000000
gray 0 37008.000000
gray 0 37265.000000
gray 0 37522.000000
gray 0 37779.000000
gray 0 38036.000000
gray 0 38293.000000
gray 0 38550.000000
gray 0 38807.000000
gray 0 39064.000000
gray 0 39321.000000
gray 0 39578.000000
gray 0 39835.000000
gray 0 40092.000000
gray 0 40349.000000
gray 0 40606.000000
gray 0 40863.000000
gray 0 41120.000000
gray 0 41377.000000
gray 0 41634.000000
gray 0 41891.000000
gray 0 42148.000000
gray 0 42405.000000
gray 0 42662.000000
gray 0 42919.000000
gray 0 43176.000000
gray 0 43433.000000
gray 0 43690.000000
gray 0 43947.000000
gray 0 44204.000000
gray 0 44461.000000
gray 0 44718.000000
gray 0 44975.000000
gray 0 45232.000000
gray 0 45489.000000
gray 0 45746.000000
gray 0 46003.000000
gray 0 46260.000000
gray 0 46517.000000
gray 0 46774.000000
gray 0 47031.000000
gray 0 47288.000000
gray 0 47545.000000
gray 0 47802.000000
gray 0 48059.000000
gray 0 48316.000000
gray 0 48573.000000
gray 0 48830.000000
gray 0 49087.000000
gray 0 49344.000000
gray 0 49601.000000
gray 0 49858.000000
gray 0 50115.000000
gray 0 50372.000000
gray 0 50629.000000
gray 0 50886.000000
gray 0 51143.000000
gray 0 51400.000000
gray 0 51657.000000
gray 0 51914.000000
gray 0 52171.000000
gray 0 52428.000000
gray 0 52685.000000
gray 0 52942.000000
gray 0 53199.000000
gray 0 53456.000000
gray 0 53713.000000
gray 0 53970.000000
gray 0 54227.000000
gray 0 54484.000000
gray 0 54741.000000
gray 0 54998.000000
gray 0 55255.000000
gray 0 55512.000000
gray 0 55769.000000
gray 0 56026.000000
gray 0 56283.000000
gray 0 56540.000000
gray 0 56797.000000
gray 0 57054.000000
gray 0 57311.000000
gray 0 57568.000000
gray 0 57825.000000
gray 0 58082.000000
gray 0 58339.000000
gray 0 58596.000000
gray 0 58853.000000
gray 0 59110.000000
gray 0 59367.000000
gray 0 59624.000000
gray 0 59881.000000
gray 0 60138.000000
gray 0 60395.000000
gray 0 60652.000000
gray 0 60909.000000
gray 0 61166.000000
gray 0 61423.000000
gray 0 61680.000000
gray 0 61937.000000
gray 0 62194.000000
gray 0 62451.000000
gray 0 62708.000000
gray 0 62965.000000
gray 0 63222.000000
gray 0 63479.000000
gray 0 63736.000000
gray 0 63993.000000
gray 0 64250.000000
gray 0 64507.000000
gray 0 64764.000000
gray 0 65021.000000
gray 0 65278.000000
gray 0 65535.000000
>>

John Donoghue <lostbard>
Project Member
Mon 16 May 2016 06:37:21 AM UTC, comment #35: 

I normally answer "y" to that question and it works for me once Octave has loaded its shared libraries.

Mike Miller <mtmiller>
Project Administrator
Mon 16 May 2016 01:16:48 AM UTC, comment #34: 

I know am missing something ....

(gdb) break _magick_read_.cc:1113
No source file named _magick_read_.cc.
Make breakpoint pending on future shared library load? (y or [n])

John Donoghue <lostbard>
Project Member
Thu 12 May 2016 08:30:16 AM UTC, comment #33: 

A patch will be good for me, but it will take me some time to build it...

Avinoam Kalma <avinoam>
Project Member
Thu 12 May 2016 12:38:09 AM UTC, comment #32: 

Yeah, no rush. I may even have a patch for you to test by then.

If it's the same I'm seeing on Debian, then we want to look at this value each time through the loop:

(gdb) break __magick_read__.cc:1113
(gdb) run
## breakpoint hit
(gdb) print grey
(gdb) continue
## breakpoint hit
(gdb) print grey

This would be with any of the tests of imwrite that are failing, or with a simple example like

imwrite (uint8(0:255), "test.tif")

May need to also build with -O0, in my testing some important values were optimized out so I couldn't inspect them with -O2.

Mike Miller <mtmiller>
Project Administrator
Wed 11 May 2016 11:18:29 PM UTC, comment #31: 

I can build a dev version this weekend if you are willing to wait that long

what do i need look for in gdb?

John Donoghue <lostbard>
Project Member
Wed 11 May 2016 10:22:50 PM UTC, comment #30: 

Or I can provide a patch that you will have to apply to Octave for testing, in addition to the patch here of course to enable GraphicsMagick with 16-bit quantization, if building with a patch is easier for you than using a debugger.

Mike Miller <mtmiller>
Project Administrator
Wed 11 May 2016 09:44:24 PM UTC, comment #29: 

Are there any Windows users or developers willing to do some testing of this with gdb? I believe this may be the same as bug #47746 on GNU/Linux. Moving to a 16-bit quantization introduces a potential for round-off error in the Octave routines when working with 8-bit images. If you have an mxe-octave build of the default branch with debug symbols not stripped and gdb available, I can tell you what to look for.

Mike Miller <mtmiller>
Project Administrator
Thu 26 Nov 2015 07:23:55 PM UTC, comment #28: 

ok. After checking, the problem appears from imwrite.

After using java, the image saved by imwrite has all elements lower by one value. I have no idea where this may come from though.

Carnë Draug <carandraug>
Project Member
Wed 25 Nov 2015 09:51:16 PM UTC, comment #27: 

last file

(file #35555)

Avinoam Kalma <avinoam>
Project Member
Wed 25 Nov 2015 09:50:00 PM UTC, comment #26: 

Results:

>> gray  = randi (255, 10, 10, 1, "uint8");
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be
truncated to requested type.
warning: called from
    randi at line 109 column 7
>> save ("data-beforejava-written.dat", "gray");
>> imwrite (gray, "data-beforejava.tif");
warning: your version of GraphicsMagick limits images to 16 bits per pixel
>> [r, cmap, a] = imread ("data-beforejava.tif", "Index", "all");
>> save ("data-before-read.mat", "r", "cmap", "a");
>> isequal (gray, r)
ans =  1
>> jobj = javaObject ("java.lang.StringBuffer");
>> imwrite (gray, "data-afterjava.tif");
>> [r, cmap, a] = imread ("data-afterjava.tif", "Index", "all");
>> save ("data-afterjava-read.mat", "r", "cmap", "a");
>> isequal (gray, r)
ans = 0

files attached

(file #35551, file #35552, file #35553, file #35554)

Avinoam Kalma <avinoam>
Project Member
Wed 25 Nov 2015 09:38:39 PM UTC, comment #25: 

I'm curious if the problem is on the reading or writing of the image. Could you run the following code:

gray  = randi (255, 10, 10, 1, "uint8");

save ("data-beforejava-written.dat", "gray");
imwrite (gray, "data-beforejava.tif");
[r, cmap, a] = imread ("data-beforejava.tif", "Index", "all");
save ("data-before-read.mat", "r", "cmap", "a");
isequal (gray, r)

jobj = javaObject ("java.lang.StringBuffer");

imwrite (gray, "data-afterjava.tif");
[r, cmap, a] = imread ("data-afterjava.tif", "Index", "all");
save ("data-afterjava-read.mat", "r", "cmap", "a");
isequal (gray, r)

And show the output and attach the tif and dat files generated?

By the way, I have fixed the warnings you are getting from randi on my own tree, and I'm just waiting from Kai to review it before pushing.

Carnë Draug <carandraug>
Project Member
Wed 25 Nov 2015 09:20:42 PM UTC, comment #24: 

With official 4.0.0 version (compiled with quantum-depth=8)

>> test imread
warning: your version of GraphicsMagick limits images to 8 bits per pixel
PASSES 4 out of 4 tests
>> test imwrite
PASSES 19 out of 19 tests
>> jobj = javaObject ("java.lang.StringBuffer")
jobj =

<Java object: java.lang.StringBuffer>

>> test imread
PASSES 4 out of 4 tests
>> test imwrite
PASSES 19 out of 19 tests

Avinoam Kalma <avinoam>
Project Member
Wed 25 Nov 2015 09:16:51 PM UTC, comment #23: 

Unfortunately, I have problems building last dev branch.
But I could build it two weeks ago, so here is the result:

>> test imread
warning: your version of GraphicsMagick limits images to 16 bits per pixel
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be truncated to requested type.
PASSES 5 out of 5 tests
>> test imwrite
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be truncated to requested type.
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be truncated to requested type.
...
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be truncated to requested type.
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be truncated to requested type.
PASSES 20 out of 20 tests
>> jobj = javaObject ("java.lang.StringBuffer")
jobj =

<Java object: java.lang.StringBuffer>

>> test imread
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be truncated to requested type.
***** testif HAVE_MAGICK
w = randi (255, 100, 100, "uint8");
[r, cmap, a] = write_and_read (w, "tif", "PixelRegion", {[50 70] [20 40]});
assert (r, w(50:70, 20:40))
[r, cmap, a] = write_and_read (w, "tif", "PixelRegion", {[50 2 70] [20 3 40]});
assert (r, w(50:2:70, 20:3:40))
!!!!! test failed
ASSERT errors for:  assert (r,w (50:70, 20:40))

  Location  |  Observed  |  Expected  |  Reason
   (1,1)          70           71        Abs err 1 exceeds tol 0
   (2,1)         243          244        Abs err 1 exceeds tol 0
   (3,1)         112          113        Abs err 1 exceeds tol 0
   (4,1)         198          199        Abs err 1 exceeds tol 0
   (5,1)         124          125        Abs err 1 exceeds tol 0
..............................
  (19,21)         58           59        Abs err 1 exceeds tol 0
  (20,21)         3            4         Abs err 1 exceeds tol 0
  (21,21)        230          231        Abs err 1 exceeds tol 0
>> test imwrite
warning: randi: maximum integer IMAX or range exceeds requested type.  Values might be truncated to requested type.
***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 1, "uint8");
r  = write_and_read (".tif", gray);
assert (r, gray)
!!!!! test failed
ASSERT errors for:  assert (r,gray)

  Location  |  Observed  |  Expected  |  Reason
   (1,1)         191          192        Abs err 1 exceeds tol 0
   (2,1)         144          145        Abs err 1 exceeds tol 0
.........................................
   (7,10)        148          149        Abs err 1 exceeds tol 0
   (8,10)        184          185        Abs err 1 exceeds tol 0
   (9,10)         61           62        Abs err 1 exceeds tol 0
  (10,10)        173          174        Abs err 1 exceeds tol 0
>> quit

Avinoam Kalma <avinoam>
Project Member
Wed 25 Nov 2015 04:31:51 PM UTC, comment #22: 

Regarding comment #21, there have been odd interactions between Java and the rest of Octave before.  In the end they have often indicated some place where Octave was sloppy about memory initialization or new/delete calls were unpaired.  It's been a long time since I've run Octave under valgrind, but I bet there are still a few memory leaks.

It would be good for Avinoam to re-test a recent version of the dev branch to see if there is still a problem.  I'm hoping that the extensive changes to the core code to use exceptions may have altered the problem behavior.

Rik <rik5>
Project Administrator
Wed 25 Nov 2015 01:06:38 PM UTC, comment #21: 

@John Donoghue:

> So do we want quantum 16 ?


We definitely want quantum depth 16. Maybe not for 4.0.1 since that's a patch release but we will want it for 4.2. It should have been quantum depth 16 since the beginning.

@Avinoam:

Can you confirm the behaviour you saw again? About the image tests failing after the javaObject call? Is that always reproducible? I don't understand how these can be related. I specially don't understand how it can be related to quantum depth. Can you show:

test imread
test imwrite
jobj = javaObject ("java.lang.StringBuffer")
test imread
test imwrite

With and without this patch?

Carnë Draug <carandraug>
Project Member
Wed 25 Nov 2015 12:23:39 PM UTC, comment #20: 

We do want quantum 16, but we can't do it because imread/imwrite failure.

please see comment #17, the command

jobj = javaObject ("java.lang.StringBuffer");

is the reason for the failure. How can we fix this?

Avinoam Kalma <avinoam>
Project Member
Wed 25 Nov 2015 01:13:17 AM UTC, comment #19: 

Currently mxe does not use quantum 16.

With quantum 16, the tests fail, without, they do not.

So do we want quantum 16 ?

John Donoghue <lostbard>
Project Member
Wed 25 Nov 2015 12:38:16 AM UTC, comment #18: 

Doesn't the development branch now use quantum-depth=16 for MXE Octave?  Can this report be closed?

Rik <rik5>
Project Administrator
Fri 01 May 2015 12:32:00 PM UTC, comment #17: 

Revisiting this bug, I have compiled MXE_octave rc4 with quantum-depth=16, and check with run_test_suite.
Again, I got failures in imread and in imwrite.

If I check imread and imwrite before run_test_suite they pass.

I have found that:

test imread -> pass
test imwrite -> pass

jobj = javaObject ("java.lang.StringBuffer");

test imread -> fail
test imwrite -> fail

In run_test_suite the command with javaObject appears in test ov-class.cc-tst, before test imread & imwrite

Any explanation?

Avinoam Kalma <avinoam>
Project Member
Tue 02 Dec 2014 07:53:23 PM UTC, comment #16: 

Hi,

strange results:

I have reproduced the bug that John Donoghue saw (comemnt #1)
in octave-cli version, but it did not appear in
octave-gui version.

Any explanation for such behaviour?

Avinoam

Avinoam Kalma <avinoam>
Project Member
Fri 21 Nov 2014 10:28:40 PM UTC, comment #15: 

Hi,

I run the two versions, the one with quantum-depth=8 and that of
quantum-depth=16.

I got the same failure in both runs, but I didn't get the failures in imwrite that that John Donoghue experienced and Carnë Draug explained.

Avinoam

Avinoam Kalma <avinoam>
Project Member
Thu 20 Nov 2014 03:34:46 PM UTC, comment #14: 

@Carnë Draug,

It seems that all the errors I got are not related
to  quantum-depth=16.
I have sent them to answer John Donoghue's question.

I will run the quantum-depth=8 version and see if I get the same errors.

Thanks,

Avinoam

Avinoam Kalma <avinoam>
Project Member
Thu 20 Nov 2014 02:28:44 PM UTC, comment #13: 

@Avinoam

I am unsure of the problem you are getting. Did you had more errors after building with quantum-depth=16? Or were those errors already there? My explanation was for the errors that John Donoghue experienced and which you do not.

Carnë Draug <carandraug>
Project Member
Wed 19 Nov 2014 09:15:39 PM UTC, comment #12: 

The failures I got are:

>> __run_test_suite__
............
  general\chop.m ......................................... PASS    1/10   FAIL 9
............
  plot\appearance\axis.m ................................. PASS    2/3    FAIL 1
............
  sparse\svds.m .......................................... PASS    5/6    FAIL 1
............
  statistics\distributions\normpdf.m ..................... PASS   14/18   FAIL 4
............
  testfun\assert.m ....................................... PASS   91/92   FAIL 1
............

Fixed test scripts:

Summary:

  PASS     11526
  FAIL        16
  XFAIL        8
  SKIPPED     55

............

>> __run_test_suite__
............
  general\chop.m ......................................... PASS    1/10   FAIL 9
............
  plot\appearance\axis.m ................................. PASS    2/3    FAIL 1
............
  sparse\svds.m .......................................... PASS    5/6    FAIL 1
............
  statistics\distributions\normpdf.m ..................... PASS   14/18   FAIL 4
............
  testfun\assert.m ....................................... PASS   91/92   FAIL 1
............

Fixed test scripts:

  ctor-vs-method.tst ..................................... PASS    1/4    FAIL 3

Summary:

  PASS     11523
  FAIL        19
  XFAIL        7
  SKIPPED     55

note that 2nd  run has 3 more failures (all in ctor-vs-method.tst ).

Avinoam

Avinoam Kalma <avinoam>
Project Member
Wed 19 Nov 2014 09:06:31 PM UTC, comment #11: 

Carnë Draug, thanks for the detailed explanation.

What do you recommend to do now?

Avinoam

Avinoam Kalma <avinoam>
Project Member
Wed 19 Nov 2014 05:24:18 PM UTC, comment #10: 

The failing test is real, I have seen it reported a few times (I don't remember if ever happened to me though). The reason is the following:

  • imwrite and imread are tested by creating random images. These are always uint8 because if the user does have GM installed, all builds will support this.
  • the whole reason why quantum depth is a build option is because then GM will ONLY handle images of that bitdepth. What this means is that when it reads an uint8 and is built with quantum depth 16, it will read them scaled in the 16bit range. Example, if the file has uint8 values but GM was built with quantum depth 16, then GM will give the value 65535. The same happens for writing, i.e., you must give a value of 65535 when you actually want to write a 255 uint8.
  • this means that rounding errors can creep but I don't know where (and I can't replicate). I'll guess that some autoconf macros would be required to modify how the rounding is done depending on the system where it is built.

Alternatives are: 1) live with the error, 2) ditch GM.

Carnë Draug <carandraug>
Project Member
Wed 19 Nov 2014 12:50:43 AM UTC, comment #9: 

What are the errors that occur when running  run_test_suite  ?

John Donoghue <lostbard>
Project Member
Tue 18 Nov 2014 10:18:50 PM UTC, comment #8: 

Hi again,

I have found "fntest.log", as you said (the "/test" should be removed).

after _run_test_suite_

>> test imwrite
PASSES 17 out of 17 tests

strange. How can we debug this?

Avinoam

Avinoam Kalma <avinoam>
Project Member
Tue 18 Nov 2014 10:00:52 PM UTC, comment #7: 

Sorry, I meant _run_test_suite_

fntests.log will be in the directory you started in when running _run_test_suite_.

After running the test suite, also then try running test imwrite

John Donoghue <lostbard>
Project Member
Tue 18 Nov 2014 09:45:17 PM UTC, comment #6: 

Hi,

I did not find the run_tests script, so I run

>> __run_test_suite__
...
Summary:

  PASS     11526
  FAIL        16
  XFAIL        8
  SKIPPED     55

See the file test/fntests.log for additional details.

>> test imwrite
PASSES 17 out of 17 tests

There were 16 fails, (none of them was imwrite).
The version I have used is the mxe-octave + gm-mxe.patch.
BTW, I did not find the file test/fntests.log.

Avinoam

Avinoam Kalma <avinoam>
Project Member
Tue 18 Nov 2014 02:31:45 PM UTC, comment #5: 

On my machine, it passes on running standalone:

>> test imwrite
PASSES 17 out of 17 tests

However running it with _run_tests_ OR after running it after running _run_tests_, it fails:

>> uname
ans =
  scalar structure containing the fields:
    sysname = MINGW32_NT-6.1
    nodename = JYRW4S1
    release = Windows 7
    version = Service Pack 1
    machine = i686
>> test imwrite
  ***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 1, "uint8");
r  = write_and_read (gray);
assert (r, gray)
!!!!! test failed
ASSERT errors for:  assert (r,gray)

  Location  |  Observed  |  Expected  |  Reason
   (1,1)         237          238        Abs err 1 exceeds tol 0
   (2,1)          42           43        Abs err 1 exceeds tol 0
   (3,1)         238          239        Abs err 1 exceeds tol 0
   (4,1)          44           45        Abs err 1 exceeds tol 0
   (5,1)          59           60        Abs err 1 exceeds tol 0
   (6,1)         152          153        Abs err 1 exceeds tol 0
   (7,1)         169          170        Abs err 1 exceeds tol 0
(segment of output only)

John Donoghue <lostbard>
Project Member
Sun 16 Nov 2014 09:13:42 PM UTC, comment #4: 

Thanks andy.

I run this command, using last Octave version from http://hg.octave.org/mxe-octave/ with gm-mxe.patch

>> test imwrite
PASSES 17 out of 17 tests
>> test imread
PASSES 1 out of 1 test
>> uname
ans =

  scalar structure containing the fields:

    sysname = MINGW32_NT-6.1
    nodename = Kalma-PC
    release = Windows 7
    version = Service Pack 1
    machine = i686

@lostbard: can you check again? how can we debug this problem?

Thanks,

Avinoam

Avinoam Kalma <avinoam>
Project Member
Sat 15 Nov 2014 08:32:45 PM UTC, comment #3: 

@Avinoam: In this case at the end of imwrite.m. The %!test blocks.

You can run the tests with "test imwrite" from within Octave.

Andreas Weber <andy1978>
Project Member
Sat 15 Nov 2014 06:36:05 PM UTC, comment #2: 

Hi,

Where can I find imwrite tests?

Thanks,

Avinoam

Avinoam Kalma <avinoam>
Project Member
Mon 10 Nov 2014 10:03:48 PM UTC, comment #1: 

On applying this patch,and running the test suite, I get failures when running imwrite tests:

>>>>> processing C:\Octave\Octave-3.8.2\share\octave\3.8.2\m\image\imwrite.m
  ***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 1, "uint8");
r  = write_and_read (gray);
assert (r, gray)
!!!!! test failed
ASSERT errors for:  assert (r,gray)

  Location  |  Observed  |  Expected  |  Reason
   (1,1)          61           62        Abs err 1 exceeds tol 0
   (2,1)         101          102        Abs err 1 exceeds tol 0
   (3,1)         188          189        Abs err 1 exceeds tol 0
   (4,1)         237          238        Abs err 1 exceeds tol 0
   (5,1)          2            3         Abs err 1 exceeds tol 0
   (6,1)         207          208        Abs err 1 exceeds tol 0
   (7,1)         174          175        Abs err 1 exceeds tol 0
   (8,1)          11           12        Abs err 1 exceeds tol 0
   (9,1)         126          127        Abs err 1 exceeds tol 0
   (10,1)        246          247        Abs err 1 exceeds tol 0
   (1,2)         254          255        Abs err 1 exceeds tol 0
   (2,2)         103          104        Abs err 1 exceeds tol 0
   (3,2)         141          142        Abs err 1 exceeds tol 0
   (4,2)         188          189        Abs err 1 exceeds tol 0
   (5,2)          46           47        Abs err 1 exceeds tol 0
   (6,2)         137          138        Abs err 1 exceeds tol 0
   (7,2)         248          249        Abs err 1 exceeds tol 0
   (8,2)          27           28        Abs err 1 exceeds tol 0
   (9,2)          2            3         Abs err 1 exceeds tol 0
   (10,2)        120          121        Abs err 1 exceeds tol 0
   (1,3)         145          146        Abs err 1 exceeds tol 0
   (2,3)         196          197        Abs err 1 exceeds tol 0
   (3,3)         206          207        Abs err 1 exceeds tol 0
   (4,3)          78           79        Abs err 1 exceeds tol 0
   (5,3)         191          192        Abs err 1 exceeds tol 0
   (6,3)         211          212        Abs err 1 exceeds tol 0
   (7,3)         163          164        Abs err 1 exceeds tol 0
   (8,3)          91           92        Abs err 1 exceeds tol 0
   (9,3)          25           26        Abs err 1 exceeds tol 0
   (10,3)        249          250        Abs err 1 exceeds tol 0
   (1,4)         100          101        Abs err 1 exceeds tol 0
   (2,4)          4            5         Abs err 1 exceeds tol 0
   (3,4)         233          234        Abs err 1 exceeds tol 0
   (4,4)         198          199        Abs err 1 exceeds tol 0
   (5,4)         139          140        Abs err 1 exceeds tol 0
   (6,4)          75           76        Abs err 1 exceeds tol 0
   (7,4)         120          121        Abs err 1 exceeds tol 0
   (8,4)         189          190        Abs err 1 exceeds tol 0
   (9,4)         196          197        Abs err 1 exceeds tol 0
   (10,4)         54           55        Abs err 1 exceeds tol 0
   (1,5)         244          245        Abs err 1 exceeds tol 0
   (2,5)          85           86        Abs err 1 exceeds tol 0
   (3,5)         135          136        Abs err 1 exceeds tol 0
   (4,5)         154          155        Abs err 1 exceeds tol 0
   (5,5)         195          196        Abs err 1 exceeds tol 0
   (6,5)         229          230        Abs err 1 exceeds tol 0
   (7,5)         162          163        Abs err 1 exceeds tol 0
   (8,5)          66           67        Abs err 1 exceeds tol 0
   (9,5)          11           12        Abs err 1 exceeds tol 0
   (10,5)        141          142        Abs err 1 exceeds tol 0
   (1,6)         108          109        Abs err 1 exceeds tol 0
   (2,6)         240          241        Abs err 1 exceeds tol 0
   (3,6)         102          103        Abs err 1 exceeds tol 0
   (4,6)         193          194        Abs err 1 exceeds tol 0
   (5,6)          43           44        Abs err 1 exceeds tol 0
   (6,6)         219          220        Abs err 1 exceeds tol 0
   (7,6)          13           14        Abs err 1 exceeds tol 0
   (8,6)          65           66        Abs err 1 exceeds tol 0
   (9,6)         162          163        Abs err 1 exceeds tol 0
   (10,6)         14           15        Abs err 1 exceeds tol 0
   (1,7)         136          137        Abs err 1 exceeds tol 0
   (2,7)         151          152        Abs err 1 exceeds tol 0
   (3,7)          41           42        Abs err 1 exceeds tol 0
   (4,7)         130          131        Abs err 1 exceeds tol 0
   (5,7)         114          115        Abs err 1 exceeds tol 0
   (6,7)         107          108        Abs err 1 exceeds tol 0
   (7,7)         189          190        Abs err 1 exceeds tol 0
   (8,7)         192          193        Abs err 1 exceeds tol 0
   (9,7)          79           80        Abs err 1 exceeds tol 0
   (10,7)        233          234        Abs err 1 exceeds tol 0
   (1,8)          62           63        Abs err 1 exceeds tol 0
   (2,8)         178          179        Abs err 1 exceeds tol 0
   (3,8)         215          216        Abs err 1 exceeds tol 0
   (4,8)          86           87        Abs err 1 exceeds tol 0
   (5,8)         178          179        Abs err 1 exceeds tol 0
   (6,8)         217          218        Abs err 1 exceeds tol 0
   (7,8)         102          103        Abs err 1 exceeds tol 0
   (8,8)         234          235        Abs err 1 exceeds tol 0
   (9,8)         142          143        Abs err 1 exceeds tol 0
   (10,8)        166          167        Abs err 1 exceeds tol 0
   (1,9)          57           58        Abs err 1 exceeds tol 0
   (2,9)         124          125        Abs err 1 exceeds tol 0
   (3,9)          75           76        Abs err 1 exceeds tol 0
   (4,9)         141          142        Abs err 1 exceeds tol 0
   (5,9)          54           55        Abs err 1 exceeds tol 0
   (6,9)         208          209        Abs err 1 exceeds tol 0
   (7,9)         128          129        Abs err 1 exceeds tol 0
   (8,9)         143          144        Abs err 1 exceeds tol 0
   (9,9)          10           11        Abs err 1 exceeds tol 0
   (10,9)        251          252        Abs err 1 exceeds tol 0
   (1,10)        147          148        Abs err 1 exceeds tol 0
   (2,10)        246          247        Abs err 1 exceeds tol 0
   (3,10)        240          241        Abs err 1 exceeds tol 0
   (4,10)         53           54        Abs err 1 exceeds tol 0
   (5,10)        238          239        Abs err 1 exceeds tol 0
   (6,10)         85           86        Abs err 1 exceeds tol 0
   (7,10)         55           56        Abs err 1 exceeds tol 0
   (8,10)        120          121        Abs err 1 exceeds tol 0
   (9,10)         28           29        Abs err 1 exceeds tol 0
  (10,10)         28           29        Abs err 1 exceeds tol 0
  ***** testif HAVE_MAGICK
gray  = randi (255, 10, 10, 1, "uint8");
alpha = randi (255, 10, 10, 1, "uint8");
[r, ~, a] = write_and_read (gray, "Alpha", alpha);
assert (r, gray)
assert (a, alpha)

John Donoghue <lostbard>
Project Member
Thu 30 Oct 2014 04:50:58 PM UTC, original submission:  

Graphicsmagick is not build with quantum-depth=16 in mxe octave...patch attached

Markus Bergholz <markuman>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #35555:  data-before-read.mat added by avinoam (821B - application/octet-stream)
file #35551:  data-afterjava.tif added by avinoam (370B - image/tiff)
file #35552:  data-beforejava.tif added by avinoam (370B - image/tiff)
file #35553:  data-afterjava-read.mat added by avinoam (820B - application/octet-stream)
file #35554:  data-beforejava-written.dat added by avinoam (709B - application/octet-stream)
file #32344:  gm-mxe.patch added by markuman (808B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by avinoam
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by markuman (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-25 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2015-11-25 avinoam Attached File- => Added data-before-read.mat, #35555
    2015-11-25 avinoam Attached File- => Added data-afterjava.tif, #35551
        Attached File- => Added data-beforejava.tif, #35552
        Attached File- => Added data-afterjava-read.mat, #35553
        Attached File- => Added data-beforejava-written.dat, #35554
    2015-11-25 rik5 StatusNone => In Progress
    2015-11-25 carandraug Release3.8.2 => other
    2014-11-13 avinoam Carbon-Copy- => Added avinoam
    2014-10-30 markuman Attached File- => Added gm-mxe.patch, #32344

    Back to the top


    Powered by Savane 3.5