Guile-CV: Not a GRAY, RGB nor an RGBA image "sand.tif"

[Daniele]

Hello, I've installed guile-cv on debian buster following the
instructions in the manual, when I try to use it I get this error
though:

scheme@(guile-user)> ,use (cv)
scheme@(guile-user)> (im-load "sand.tif")
ERROR: In procedure scm-error:
ERROR: Not a GRAY, RGB nor an RGBA image "sand.tif"

Any idea what might be the cause?

Daniele

[David Pirotte]

Hi Daniele,

Post by Daniele
ERROR: Not a GRAY, RGB nor an RGBA image "sand.tif"
Any idea what might be the cause?

Yes: your are not in the right directory wrt guile, and this flename 'does not
exists', it does not exists in the directory your are trying to load this image, see:

scheme@(guile-user)> (getcwd)
$5 = "/usr/alto/projects/guile-cv/images"

In my cae, the sand.tiff is (also) in a subdir called 'lpdi':

(im-load "lpdi/sand.tif")
$4 = (512 512 1 (#f32(125.0 128.0 124.0 118.0 108.0 95.0 90.0 80.0 75.0 76.0 # 
)))

but if I try to load an image that does not exists, bang:

scheme@(guile-user)> (im-load "lpdi/sa1nd.tif")
ERROR: In procedure scm-error:
ERROR: Not a GRAY, RGB nor an RGBA image "lpdi/sa1nd.tif"

Good you succeed at installing!
David

[Daniele]

Hi David,

Post by David Pirotte
Yes: your are not in the right directory wrt guile, and this flename 'does not
$5 = "/usr/alto/projects/guile-cv/images"

unfortunately that's not the problem, I am in the right directory and
the image is there. I still get that error.

Daniele

[David Pirotte]

Hi Daniele,

Post by Daniele

Post by David Pirotte
Yes: your are not in the right directory wrt guile, and this flename 'does not
$5 = "/usr/alto/projects/guile-cv/images"

unfortunately that's not the problem, I am in the right directory and
the image is there. I still get that error.

This is impossible :), you think you are in the right directory, but you most
likely you are not.

You can try (getcwd), then (system "ls") and compare ... till you are convinced
this is the source of your problem (or proved me wrong, then I'll pay you a pack of
beers :)

unless you would have inadvertently replaced the file content with something
else then a tif image... I very much doubt but just in case, you can run
'file sand.tif' in a terminal and double check... if the file is not a tif
file, although it would be in the directory, the same error you be
reported ...

Did you run 'make check' while you built guile-cv? Did all check pass? It checks
that im-load works fine ...

David

[Mark H Weaver]

Post by David Pirotte
Hi Daniele,

Post by Daniele

Post by David Pirotte
Yes: your are not in the right directory wrt guile, and this flename 'does not
$5 = "/usr/alto/projects/guile-cv/images"

unfortunately that's not the problem, I am in the right directory and
the image is there. I still get that error.

This is impossible :), you think you are in the right directory, but you most
likely you are not.

David, with all due respect, this last response to Daniele comes off as
very dismissive and presumptuous to me.

According to Wikipedia, TIFF supports image types other than GRAY, RGB,
and RGBA. Baseline TIFF also supports bilevel and palette-color images,
and there are extensions that support CMYK, YCbCr, CIE L*a*b* and
others.

https://en.wikipedia.org/wiki/TIFF#Image_types
https://en.wikipedia.org/wiki/TIFF#Image_types_2

The error message "Not a GRAY, RGB nor an RGBA image" would seem to
indicate that the image Daniele is attempting to load is not supported
by the image loading library, or at least that this is a possibility.

Your personal experience might be that this message always indicates
"file not found", but perhaps that's because you've never tried to load
an unsupported TIFF variant. I find it hard to believe that the
software developer who wrote this code would have written "Not a GRAY,
RGB nor an RGBA image" if it *always* meant "file not found".

Does that make sense?

Regards,
Mark

[David Pirotte]

Hello Mark,

Post by Mark H Weaver

Post by David Pirotte

Post by Daniele

Post by David Pirotte
Yes: your are not in the right directory wrt guile, and this flename 'does not
exists', it does not exists in the directory your are trying to load this
$5 = "/usr/alto/projects/guile-cv/images"

unfortunately that's not the problem, I am in the right directory and
the image is there. I still get that error.

This is impossible :), you think you are in the right directory, but you most
likely you are not.

David, with all due respect, this last response to Daniele comes off as
very dismissive and presumptuous to me.

I'm very sorry you did feel this way: that image is part of the images distributed
with Guile-CV, so it definitely loads, as shown in my pasted an example in the
previous, partially quoted message (by Daniele), quoted (partially) but missing the
working example lines ... Hence my 'this is impossible :)', a funny tone, in my
intention, while an invitation to try other (suggested) things to find out the cause
(which is not the image format).

Since that image is distributed with Guile-CV, unless the file was somehow corrupted
(which I also suggest a command to double check), the problem is really a path
problem.

Daniele,

Could you try to load the image specifying the full path name and report here
thanks:

,use (cv)
(im-load "/your-guile-cv-clone-path/doc/images/sand.tif")

Post by Mark H Weaver
The error message "Not a GRAY, RGB nor an RGBA image" would seem to
indicate that the image Daniele is attempting to load is not supported
by the image loading library, or at least that this is a possibility.

That message comes from Guile-CV itself, and intentionally covers both cases. I can
change that.

Post by Mark H Weaver
... I find it hard to believe that the software developer who wrote this code
would have written "Not a GRAY, RGB nor an RGBA image" if it *always* meant "file
not found".

I did, nobody is perfect :). It does not *always* mean "file not found", it covers
both this case and a 'wrong format' (or corrupted file) ... I'll change that and push
a fix asap.

Cheers,
David

Post by Mark H Weaver
According to Wikipedia, TIFF supports image types other than GRAY, RGB,
and RGBA. Baseline TIFF also supports bilevel and palette-color images,
and there are extensions that support CMYK, YCbCr, CIE L*a*b* and
others.

Guile-CV relies on Vigra for all image formats it allows, and Vigra depends on
third libraries (see Guile-CV and Vigra doc for more info on this) ... in this
particular case, it will accept and load any tiff file 'accepted' by libtiff.

[Mark H Weaver]

Post by David Pirotte
Hello Mark,

Post by Mark H Weaver

Post by David Pirotte

Post by Daniele

Post by David Pirotte
Yes: your are not in the right directory wrt guile, and this flename 'does not
exists', it does not exists in the directory your are trying to load this
$5 = "/usr/alto/projects/guile-cv/images"

unfortunately that's not the problem, I am in the right directory and
the image is there. I still get that error.

This is impossible :), you think you are in the right directory, but you most
likely you are not.

David, with all due respect, this last response to Daniele comes off as
very dismissive and presumptuous to me.

I'm very sorry you did feel this way: that image is part of the images distributed
with Guile-CV,

Ah, I didn't realize that. In that case, please disregard my message,
and sorry for the noise :)

Mark

[t***@tuxteam.de]

Post by David Pirotte
Hello Mark,

[...]

Post by David Pirotte

Post by Mark H Weaver
David, with all due respect, this last response to Daniele comes off as
very dismissive and presumptuous to me.

I'm very sorry you did feel this way: that image is part of the images distributed
with Guile-CV [...]

I must admit I read that as tongue-in-cheek too, especially given
the smiley. Kind of Don Knuth's "this can't happen" error mesage
(METAFONT, I think) while it is... obviously happening.

But then.. it can be read differently, as you, Mark, rightly point
out. Thank you (both) for teaching me something.

Written communication is hard, alas.

Cheers
- -- tomás

[Daniele]

Hi David,
I hadn't tried make check, and in fact it fails on a very similar
error (pp-17-bf.png is right there when is trying to find it and it
opens in an image viewer just fine):

test-impex failed: assert-equal: expected:
(85 95 1)

got:
(0 0 0)

test-features-2: exception in test: (misc-error #f "~A ~S" ("Not a
GRAY, RGB nor an RGBA image"
"/home/daniele/build/guile-cv/doc/images/pp-17-bf.png") #f)

20 run, 2 failed
FAIL: tests/cv.scm
=======================================
1 of 2 tests failed
Please report to david at altosw dot be
=======================================
Makefile:368: recipe for target 'check-TESTS' failed
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory '/home/daniele/build/guile-cv/test-suite'
Makefile:491: recipe for target 'check-am' failed
make[1]: *** [check-am] Error 2
make[1]: Leaving directory '/home/daniele/build/guile-cv/test-suite'
Makefile:649: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1

Post by David Pirotte
Hi Daniele,

Post by Daniele

Post by David Pirotte
Yes: your are not in the right directory wrt guile, and this flename 'does not
$5 = "/usr/alto/projects/guile-cv/images"

unfortunately that's not the problem, I am in the right directory and
the image is there. I still get that error.

This is impossible :), you think you are in the right directory, but you most
likely you are not.
You can try (getcwd), then (system "ls") and compare ... till you are convinced
this is the source of your problem (or proved me wrong, then I'll pay you a pack of
beers :)
unless you would have inadvertently replaced the file content with something
else then a tif image... I very much doubt but just in case, you can run
'file sand.tif' in a terminal and double check... if the file is not a tif
file, although it would be in the directory, the same error you be
reported ...
Did you run 'make check' while you built guile-cv? Did all check pass? It checks
that im-load works fine ...
David

[David Pirotte]

Hello Daniele,

Please let's keep technical discussion on the list, it i very important,
and once again don't be shy, we are working together to make things better,
others may benefit and/or help ...

Post by Daniele
I hadn't tried make check, and in fact it fails on a very similar
error (pp-17-bf.png is right there when is trying to find it and it
(85 95 1)
(0 0 0)

Something went wrong with the installation of either vigra and/or vigra_c

Did you install Vigra 'manually?
What is the version of Vigra?

What is the last commit of vigra_c on your side? (just go in the directory
where you cloned, run gilt log and grab the first line for me).

What is really weird here is that

,use (cv)

should not even work, because you are missing both libpng and libtiff, so for the
exact same reasons we were talking wrt your first message, dynlink should complain
and 'ldd libvigra_c.so' would report failng libs ...

could you check 'ldd libvigra_c.so' and paste the report here

David

[Daniele]

Hi David, everything seems to be alright

Post by David Pirotte
Did you install Vigra 'manually?
What is the version of Vigra?
What is the last commit of vigra_c on your side? (just go in the directory
where you cloned, run gilt log and grab the first line for me).

commit 691b189b05b0e0734376510cbdb256d30725ec96 (HEAD -> master,
origin/master, origin/HEAD)

Post by David Pirotte
What is really weird here is that
,use (cv)
should not even work, because you are missing both libpng and libtiff, so for the
exact same reasons we were talking wrt your first message, dynlink should complain
and 'ldd libvigra_c.so' would report failng libs ...
could you check 'ldd libvigra_c.so' and paste the report here
David

linux-vdso.so.1 (0x00007fffaefc0000)
libvigraimpex.so.11 => /usr/local/lib/libvigraimpex.so.11
(0x00007f67c6108000)
libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3
(0x00007f67c5d04000)
libfftw3f.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f.so.3
(0x00007f67c58f6000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62
(0x00007f67c568d000)
libhdf5_serial.so.100 =>
/usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100 (0x00007f67c5124000)
libhdf5_serial_hl.so.100 =>
/usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100
(0x00007f67c4f00000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f67c4ce6000)
libsz.so.2 => /usr/lib/x86_64-linux-gnu/libsz.so.2 (0x00007f67c4ae3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f67c4764000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f67c4451000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f67c423a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f67c3e97000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f67c3c79000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f67c3a75000)
libaec.so.0 => /usr/lib/x86_64-linux-gnu/libaec.so.0 (0x00007f67c386d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f67c6eb7000)

Daniele

[David Pirotte]

Hi Daniele,

this is a long answer, please read carefully, and apply all the steps
meticulously...

Post by Daniele

Post by David Pirotte
Did you install Vigra 'manually?
What is the version of Vigra?

You forgot to answer the above question, but I believe, because of the (incomplete)
'ldd libvigra_c.so' report you sent, that you installed Vigra manually, which is
perfect (and expected): debian buster still uses 1.10, and Guile-CV needs Vigra 1.11
(to be fully correct, the libvigra_c upon which Guile-CV depends needs Vigra 1.11):

It is also a lot better in the long run, debian, even buster, is far too
slow 'for us', as you can see (Vigra 1.11 has been released a while ago...).

However, when you install Vigra manually, you are responsible for the installation
of the image format libraries you intend to use, and you are missing practically all
of them, let's fix this, see below.

Post by Daniele

Post by David Pirotte
What is the last commit of vigra_c on your side? (just go in the
directory where you cloned, run gilt log and grab the first line for me).

commit 691b189b05b0e0734376510cbdb256d30725ec96 (HEAD -> master,
origin/master, origin/HEAD)

Perfect.

Post by Daniele

Post by David Pirotte
David

as an aside note, please configure your email so it does not wrap long lines
so you can copy paste 'terminal output', and manually ask for wrapping text
lines,,, thanks!

Post by Daniele
linux-vdso.so.1 (0x00007fffaefc0000)
libvigraimpex.so.11 => /usr/local/lib/libvigraimpex.so.11
...

This is largely incomplete. Let's 'trick' to solve this and try to save some time
as well, please try the following:

1- install libvigraimpex-dev

sudo apt-get install libvigraimpex-dev

this will install all Vigra dependencies as specified by the debian
team: it will install all image libraries development files for all
image format Vigra is capable of handling

2- recompile Vigra

cd /your-vigra-source-tree-location/
make clean
cmake \
-DCMAKE_INSTALL_PREFIX=/opt/vigra \
-DCMAKE_BUILD_TYPE=RELEASE

[ in the above steps, substitute the PREFIX as
[ appropriate ... I suggest you keep the one you had to
[ simplify (otherwise remember to (re)configure
[ in /etc/ld.so.conf.d//vigra.conf and run ldconfig as
[ root ...

at this point, cmake will list all format it will accept, so
you can double check ...

make
make install

3- recompile libvigra_c

make clean
cmake \
-DCMAKE_INSTALL_PREFIX=/opt/vigra_c \
-DCMAKE_BUILD_TYPE=RELEASE

[ in the above steps, substitute the PREFIX for the
[ one used above ... remember to (re)configure
[ in /etc/ld.so.conf.d//vigra_c.conf and run ldconfig as
[ root ...

make
make install

4- you may safely remove libvigraimpex-dev if you wish, we are not
using it anyway...

Then try make check in Guile-CV, then make install, and ... it should be fine.

David

[Daniele]

Post by David Pirotte
Then try make check in Guile-CV, then make install, and ... it should be fine.

Yes, it's fine now, thanks.

Daniele

Post by David Pirotte
Hi Daniele,
this is a long answer, please read carefully, and apply all the steps
meticulously...

Post by Daniele

Post by David Pirotte
Did you install Vigra 'manually?
What is the version of Vigra?

You forgot to answer the above question, but I believe, because of the (incomplete)
'ldd libvigra_c.so' report you sent, that you installed Vigra manually, which is
perfect (and expected): debian buster still uses 1.10, and Guile-CV needs Vigra 1.11
It is also a lot better in the long run, debian, even buster, is far too
slow 'for us', as you can see (Vigra 1.11 has been released a while ago...).
However, when you install Vigra manually, you are responsible for the installation
of the image format libraries you intend to use, and you are missing practically all
of them, let's fix this, see below.

Post by Daniele

Post by David Pirotte
What is the last commit of vigra_c on your side? (just go in the
directory where you cloned, run gilt log and grab the first line for me).

commit 691b189b05b0e0734376510cbdb256d30725ec96 (HEAD -> master,
origin/master, origin/HEAD)

Perfect.

Post by Daniele

Post by David Pirotte
David

as an aside note, please configure your email so it does not wrap long lines
so you can copy paste 'terminal output', and manually ask for wrapping text
lines,,, thanks!

Post by Daniele
linux-vdso.so.1 (0x00007fffaefc0000)
libvigraimpex.so.11 => /usr/local/lib/libvigraimpex.so.11
...

This is largely incomplete. Let's 'trick' to solve this and try to save some time
1- install libvigraimpex-dev
sudo apt-get install libvigraimpex-dev
this will install all Vigra dependencies as specified by the debian
team: it will install all image libraries development files for all
image format Vigra is capable of handling
2- recompile Vigra
cd /your-vigra-source-tree-location/
make clean
cmake \
-DCMAKE_INSTALL_PREFIX=/opt/vigra \
-DCMAKE_BUILD_TYPE=RELEASE
[ in the above steps, substitute the PREFIX as
[ appropriate ... I suggest you keep the one you had to
[ simplify (otherwise remember to (re)configure
[ in /etc/ld.so.conf.d//vigra.conf and run ldconfig as
[ root ...
at this point, cmake will list all format it will accept, so
you can double check ...
make
make install
3- recompile libvigra_c
make clean
cmake \
-DCMAKE_INSTALL_PREFIX=/opt/vigra_c \
-DCMAKE_BUILD_TYPE=RELEASE
[ in the above steps, substitute the PREFIX for the
[ one used above ... remember to (re)configure
[ in /etc/ld.so.conf.d//vigra_c.conf and run ldconfig as
[ root ...
make
make install
4- you may safely remove libvigraimpex-dev if you wish, we are not
using it anyway...
Then try make check in Guile-CV, then make install, and ... it should be fine.
David

[David Pirotte]

Hi Daniele,

Post by Daniele

Post by David Pirotte
Then try make check in Guile-CV, then make install, and ... it should be fine.

Yes, it's fine now, thanks.

Good to hear, welcome to Guile-CV!

And a big thank you for your patience and perseverance: this 'episode' pointed to a
few 'things' I will use - in a near future but not exactly now - to improve install
checks, the config.log and the im-load error messages.

David