bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2015-08-18T16:18:46Zhttps://gitlab.idiap.ch/bob/bob/-/issues/164Nose tests are not uniform2015-08-18T16:18:46ZAndré AnjosNose tests are not uniform*Created by: siebenkopf*
I just noticed that the usage of nose tests is not uniform. Sometimes, the unittest framework is used, and sometimes the nose framework.
After discussion with anjos we found that the nose tests have more pros, ...*Created by: siebenkopf*
I just noticed that the usage of nose tests is not uniform. Sometimes, the unittest framework is used, and sometimes the nose framework.
After discussion with anjos we found that the nose tests have more pros, and hence, we should try to port all nose tests to nose (removing the dependence to the unittest.TestCase class).
This bug has low priority since it is just a unification of tests.https://gitlab.idiap.ch/bob/bob/-/issues/165Can't write one-element ndarray in HDF52017-01-27T15:49:13ZAndré AnjosCan't write one-element ndarray in HDF5*Created by: siebenkopf*
When I try to write a single-element numpy.ndarray to HDF5File, and read it again, the type of the variable changes:
```
> import bob, numpy
> f = bob.io.HDF5File("t.hdf5", "w")
> a = numpy.ndarray((1,),...*Created by: siebenkopf*
When I try to write a single-element numpy.ndarray to HDF5File, and read it again, the type of the variable changes:
```
> import bob, numpy
> f = bob.io.HDF5File("t.hdf5", "w")
> a = numpy.ndarray((1,), dtype=numpy.int)
> type(a)
type 'numpy.ndarray'
> f.set("a", a)
> b = f.read("a")
> type(b)
type 'int'
```
The point is that it works well with 2-element arrays, and I want to write ndarrays of different sizes (also with a single element). Currently, this is not supported.https://gitlab.idiap.ch/bob/bob.extension/-/issues/1mr.developer is run before 'setup_requires' is evaluated2018-06-04T12:44:45ZAndré Anjosmr.developer is run before 'setup_requires' is evaluated*Created by: siebenkopf*
I created a package to implement functionality in C++. For this package (xbob.boosting) I used xbob.extension to enable the C++ compilation. This works fine.
Now, to use this package, I created another packag...*Created by: siebenkopf*
I created a package to implement functionality in C++. For this package (xbob.boosting) I used xbob.extension to enable the C++ compilation. This works fine.
Now, to use this package, I created another package that imports xbob.boosting using mr.developer. When I try to call 'bin/buildout', I get the error message:
from xbob.extension import Extension
ImportError: No module named extension
Obviously, it cannot find xbob.extension. So, I tried to put the 'setup_requires = ["xbob.extension"]' into the setup.py and the 'xbob.boosting' section into the buildout.cfg of my new package, but without success.
It seems that mr.developer is run and tries to update external packages BEFORE the setup.py is interpreted.
P.S. I had the same issue, when I put used the mr.developer in the original xbob.boosting package. Disabling mr.developer, the original package worked fine. https://gitlab.idiap.ch/bob/bob.extension/-/issues/2Enabling debug mode2018-06-04T12:44:45ZAndré AnjosEnabling debug mode*Created by: siebenkopf*
When I write C++ code, I couldn't find an option to enable DEBUG mode. Specifically, I want to write some 'assert' statements, which should be checked in debug mode.
There is the option parameter "extra_compi...*Created by: siebenkopf*
When I write C++ code, I couldn't find an option to enable DEBUG mode. Specifically, I want to write some 'assert' statements, which should be checked in debug mode.
There is the option parameter "extra_compile_args" in the setup.py, but even after setting 'extra_compile_args = ["-ggdb"]', the assertion
assert (1 == 2);
passes. I think, this is due to the fact that by default the '-DNDEBUG' macro is enabled, which disables 'assert' to be evaluated.
https://gitlab.idiap.ch/bob/bob/-/issues/166Problems installing bob2016-08-04T09:32:10ZAndré AnjosProblems installing bob*Created by: mgbarrero*
Hi,
I've installed bob on mac os x lion. Apparently everything was ok... but when I run python, and wrote import bob, I got the following error>
Traceback (most recent call last):
File "<stdin>", line 1,...*Created by: mgbarrero*
Hi,
I've installed bob on mac os x lion. Apparently everything was ok... but when I run python, and wrote import bob, I got the following error>
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named bob
When I check the boost port installed, I get:
boost @1.54.0_0+no_single+no_static+python27 (active)
So I think there should be no incompatibilities, since both Bob and Boost use the same python version: python27, right? Does anyone know what could be happening for python not to find Bob?
Thanks!!
Martahttps://gitlab.idiap.ch/bob/bob/-/issues/167PLDA machine save and load problem2019-04-19T22:41:24ZAndré AnjosPLDA machine save and load problem*Created by: zongyuange*
Hi Laurent,
It is me again. I have found an issue with PLDA machine.
After a bob.machine.PLDAMachine is trained, I saved it with
save_file = bob.io.HDF5File('/home/test.hdf5','w');
plda_machine.save(sa...*Created by: zongyuange*
Hi Laurent,
It is me again. I have found an issue with PLDA machine.
After a bob.machine.PLDAMachine is trained, I saved it with
save_file = bob.io.HDF5File('/home/test.hdf5','w');
plda_machine.save(save_file)
when I am trying to load it again with
file = bob.io.HDF5File('/home/test.hdf5','r');
plda = bob.machine.PLDAMachine();
plda.load(file)
Then I typed the command
'plda.dim_d '
will cause segmentation error.
You can try it with the any example.
Thanks,
Rehards,
ZongYuan
v2.0https://gitlab.idiap.ch/bob/bob/-/issues/168Question about GMM statistics and UBM2016-08-04T09:32:14ZAndré AnjosQuestion about GMM statistics and UBM*Created by: mgbarrero*
Hi,
I'm trying to use a ISV system, and I got stuck with the GMM statistics necessary for ISVtrainer. According to the tutorials (and what I understood reading them), I've got this code:
gmm = bob.mach...*Created by: mgbarrero*
Hi,
I'm trying to use a ISV system, and I got stuck with the GMM statistics necessary for ISVtrainer. According to the tutorials (and what I understood reading them), I've got this code:
gmm = bob.machine.GMMMachine(DIMENSION, NGAUSSIANS)
isv_base = bob.machine.ISVBase(gmm,DIMENSION)
isv_trainer = bob.trainer.ISVTrainer(10, 4.)
isv_trainer.train(isv_base, TRAINING_STATS)
DIMENSION and NGAUSSIANS are the number of dimension of U and the number of gaussians that I have in the facereclib.Tools.ISV definition.
I think the training data should be used to compute the GMM statistics for TRAINING_STATS... but I don't know how. Could you please help me with that point?
And then, I'm not quite sure either how to add the facereclib tool for ISV to that machine and trainer... how to train it, enroll the models and compute scores.
Thanks!!
Martahttps://gitlab.idiap.ch/bob/bob/-/issues/169bob.core.random has many classes for different data types2016-08-04T09:32:16ZAndré Anjosbob.core.random has many classes for different data types*Created by: siebenkopf*
Having a look at the bob.core.random module, I can find several bindings of classes for different data types. Instead of having all these classes, I would suggest two solutions:
1. We have one class for each ...*Created by: siebenkopf*
Having a look at the bob.core.random module, I can find several bindings of classes for different data types. Instead of having all these classes, I would suggest two solutions:
1. We have one class for each distribution type and a dtype-like parameter for the constructor.
2. We have only one class *overall*, having the dtype and the distribution type as parameters.
Either of the solutions will break the API, but I think we should avoid these data type specific classes and functions. In C++, these classes are templated, anyways...v2.0https://gitlab.idiap.ch/bob/bob/-/issues/170mincllr calibration code crashing with list index out of range2019-04-19T22:41:24ZAndré Anjosmincllr calibration code crashing with list index out of range*Created by: khoury*
In the file python/bob/measure/calibration.py, when the `p` list index of the list `pos` reached the value `P` (length of the `pos` list), the conditional test
```python
if n == N or neg[n] > pos[p]:
```
will ...*Created by: khoury*
In the file python/bob/measure/calibration.py, when the `p` list index of the list `pos` reached the value `P` (length of the `pos` list), the conditional test
```python
if n == N or neg[n] > pos[p]:
```
will crash as follows:
```python
Traceback (most recent call last):
...
min_cllr = bob.measure.calibration.min_cllr(scores_dev[i][0], scores_dev[i][1])
File "/usr/lib/python2.7/site-packages/bob/measure/calibration.py", line 51, in min_cllr
if (n == N or neg[n] > pos[p]):
IndexError: list index out of range
```
A solution seems to be:
```python
if not (p == P) and (n == N or neg[n] > pos[p]):
```v2.0https://gitlab.idiap.ch/bob/bob/-/issues/171SVD is failing on some matrices because of LAPACK dgesdd2016-08-04T09:32:20ZAndré AnjosSVD is failing on some matrices because of LAPACK dgesdd*Created by: laurentes*
The svd implementation is failing on some matrices, no convergence occuring. The sample matrix is available [here](http://www.idiap.ch/~ichingo/to_download/data_svd_fail.hdf5).
Similarly to NumPy, bob relies o...*Created by: laurentes*
The svd implementation is failing on some matrices, no convergence occuring. The sample matrix is available [here](http://www.idiap.ch/~ichingo/to_download/data_svd_fail.hdf5).
Similarly to NumPy, bob relies on the LAPACK function called dgesdd, as recommended by Netlib maintainers [here](https://groups.google.com/forum/#!topic/julia-dev/mmgO65i6-fA). Using NumPy leads to the exact same issue, whereas matlab implementation seems to work. This is a known problem previously reported [here](http://mail.scipy.org/pipermail/numpy-discussion/2009-February/040212.html). It seems that the slower alternative function from LAPACK called dgesvd is not affected by this problem. One possible solution would be to support both functions.
v2.0https://gitlab.idiap.ch/bob/bob/-/issues/172Multi-class SVM: predict_class_and_scores is failing2019-04-19T22:41:25ZAndré AnjosMulti-class SVM: predict_class_and_scores is failing*Created by: khoury*
The function "predict_class_and_scores" in the SVM Machine is failing for Multi-Class SVM (segmentation fault) while you iterate over many probes. However, "predict class" alone is working fine.
(https://github.c...*Created by: khoury*
The function "predict_class_and_scores" in the SVM Machine is failing for Multi-Class SVM (segmentation fault) while you iterate over many probes. However, "predict class" alone is working fine.
(https://github.com/idiap/bob/blob/master/src/machine/python/svm.cc)
This is not working:
```python
import bob
machine=bob.machine.SupportVector(bob.io.HDF5File('svm.hdf5'))
probe = bob.io.load('probe.hdf5').flatten()
cl, score = machine.predict_class_and_scores(probe)
cl, score = machine.predict_class_and_scores(probe)
```
However, this one is working:
```python
import bob
machine=bob.machine.SupportVector(bob.io.HDF5File('svm.hdf5'))
probe = bob.io.load('probe.hdf5').flatten()
cl = machine.predict_class(probe)
cl = machine.predict_class(probe)
```
To reproduce the error, you can find the SVM machine [here] (http://www.elie-khoury.fr/svm.hdf5), and a probe file [here] (http://www.elie-khoury.fr/probe.hdf5).
Thanks,https://gitlab.idiap.ch/bob/bob/-/issues/173bob.io.load('image.jpg') crashes when image.jpg is not in JPEG format2019-04-19T22:41:24ZAndré Anjosbob.io.load('image.jpg') crashes when image.jpg is not in JPEG format*Created by: siebenkopf*
When I try to load an image file with filename extension '.jpg' using bob.io.load, where the image itself is *not* encoded as JPEG (in this case it is actually a .bmp file) , the program writes:
> Not a JPEG ...*Created by: siebenkopf*
When I try to load an image file with filename extension '.jpg' using bob.io.load, where the image itself is *not* encoded as JPEG (in this case it is actually a .bmp file) , the program writes:
> Not a JPEG file: starts with 0x42 0x4d
and exits.
It seems the JPEG error handling is not implemented properly.https://gitlab.idiap.ch/bob/bob/-/issues/174bob.ip.draw_... methods take arguments in wrong order2013-11-15T19:55:28ZAndré Anjosbob.ip.draw_... methods take arguments in wrong order*Created by: siebenkopf*
Usually, points in Bob are given in (y,x) order, and functions always take (y,x) as arguments (in this order). Having a look at the documentation of the bob.ip.draw_point (and similar) functions, they take argum...*Created by: siebenkopf*
Usually, points in Bob are given in (y,x) order, and functions always take (y,x) as arguments (in this order). Having a look at the documentation of the bob.ip.draw_point (and similar) functions, they take arguments in order (x,y).
A fix of this would be nice, to have a consistent order of arguments in Bob.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/175xbob.db.aggregator nosetests need more time with python32015-08-18T16:12:09ZAndré Anjosxbob.db.aggregator nosetests need more time with python3*Created by: siebenkopf*
For some reason, the nose tests for the external packages, which are run during the nightly or incremental builds on BuildBot, need much more time with python3 compared to python2, and also the network load is m...*Created by: siebenkopf*
For some reason, the nose tests for the external packages, which are run during the nightly or incremental builds on BuildBot, need much more time with python3 compared to python2, and also the network load is much higher.
As one possible problem I have pointed out sqlite3, which is used in most of our database packages. Running some preliminary profiling tests, I got:
python2:
ncalls tottime percall cumtime percall filename:lineno(function)
205 0.710 0.003 0.710 0.003 {method 'execute' of 'sqlite3.Cursor' objects}
python3:
ncalls tottime percall cumtime percall filename:lineno(function)
205 35.832 0.175 35.832 0.175 {method 'execute' of 'sqlite3.Cursor' objects}
Maybe, sqlite3 is badly compiled for python3 (e.g., in debug mode). In this case, this is just an issue in our current environment, and this might be fixed automatically after the system upgrade.https://gitlab.idiap.ch/bob/bob/-/issues/176Shift to a non-GPL library for FFT/DCT computation2016-08-04T09:32:26ZAndré AnjosShift to a non-GPL library for FFT/DCT computation*Created by: laurentes*
Bob (1.2.x) currently relies on FFTW for FFT/DCT computation. FFTW has a GPL license. We are now considering to turn the license of Bob from GPL to BSD. This would imply that we should not link any more against G...*Created by: laurentes*
Bob (1.2.x) currently relies on FFTW for FFT/DCT computation. FFTW has a GPL license. We are now considering to turn the license of Bob from GPL to BSD. This would imply that we should not link any more against GPL libraries. FFTW is the only GPL dependence that we have.
Furthermore, we are looking for alternatives to FFTW. There are already naive implementations of DFT/DCT in bob, which are used for testing purposes. But there are really slow for large arrays. We are hence looking for more optimized source code. I have performed few tests to rely on two different BSD-like FFT libraries:
1. Kiss FFT (C and C++ implementation): I was not able to make the C implementation working with 'double' instead of default 'float'. This just provides wrong outputs. And the documentation is quite poor. The C++ implementation is working with 'double', but it does only support 1D FFT (No nD FFT or DCT computation). However, I still had to tweak/fix the code to make it compatible with all the platforms we are supporting.
2. NumPy's FFT implementation (C code based on former FFTPACK fortran's implementation [P.S.: Note that SciPy also provides a different FFT implementation based on the original FFTPACK fortran's code]:. NumPy's implementation only provide FFT (not DCT). The code is much larger than the one of kiss FFT (2k lines vs 200 lines), but is probably more reliable, since it has been used for several years by this wide deployed library.
For both solutions, we won't add a new dependence, but instead we would just cannibalize the FFT source code into bob central repository (There is no Ubuntu/OS X packages for kiss FFT any way). I have pushed FFT/DCT implementations in the master branch that rely on both libraries (separately), to keep track of all the tests I did. Solution 2. is my favourite so far. If we go for it, I will just remove the FFTW and kiss FFT-based implementations, and renamed the FFT1DNumpy (2D/DCT, etc.) classes into FFT1D. The documentation should then be carefully updated. As the underlying implementation's will be different, this may slightly affect the outputs/features/results generated with FFTW.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/177.gif image read fails on some images2016-08-04T09:32:28ZAndré Anjos.gif image read fails on some images*Created by: siebenkopf*
Running some tests on old image databases I found that bob.io.load("image.gif") might fail reading the image without raising any exceptions. For the test file "TestSetA/voyager2.gif" of the MIT-CMU database, bob...*Created by: siebenkopf*
Running some tests on old image databases I found that bob.io.load("image.gif") might fail reading the image without raising any exceptions. For the test file "TestSetA/voyager2.gif" of the MIT-CMU database, bob.io.load() will return an array of the right shape (3, 805, 623), but completely made out of the value 19, while the original image is containing real image data.
It might be the case that the original image is corrupted, but I can display the image correctly with, e.g., eog ("eye of gnome"). Anyways, even for corrupted images it would be better to raise an exception instead of returning wrong data.
https://gitlab.idiap.ch/bob/bob/-/issues/178ROC and DET plots have wrong axis2016-08-04T09:32:30ZAndré AnjosROC and DET plots have wrong axis*Created by: siebenkopf*
I always found the way, ROC and DET plots are plotted using ``bob.measure.plot.roc`` and ``bob.measure.plot.det``, wrong. For some reason, someone has decided to plot the FRR axis in the abscissa and the FAR in ...*Created by: siebenkopf*
I always found the way, ROC and DET plots are plotted using ``bob.measure.plot.roc`` and ``bob.measure.plot.det``, wrong. For some reason, someone has decided to plot the FRR axis in the abscissa and the FAR in the ordinate. I have never seen plots like this before, and also the "Handbook of Biometrics" shows ROC and DET plots with the FAR in the abscissa (page 9). Also wikipedia pages show DET and ROC plots this way.
Normally, I would not consider the way the ROC is plotted as a bug. But in fact, I was using the function ``bob.measure.det``, and I blindly expected getting FAR and FRR in this order. Unfortunately, this was not the case, which lead my plots to be reverted (FAR was FRR and vice versa).
To be conform with the god of Biometrics, we should change both:
- the axis of the ROC / DET plots
- the order in which ``bob.measure.roc`` and ``bob.measure.det`` return the results.https://gitlab.idiap.ch/bob/bob.ip.flandmark/-/issues/4The returned landmarks are not in the default order of Bob2017-10-21T02:48:13ZAndré AnjosThe returned landmarks are not in the default order of Bob*Created by: siebenkopf*
The landmarks that are returned by the ``localize()`` function are given in (x,y) order, while the order in Bob is usually (y,x).
Interestingly, the second ``localizer(top, left, height, width)`` function acce...*Created by: siebenkopf*
The landmarks that are returned by the ``localize()`` function are given in (x,y) order, while the order in Bob is usually (y,x).
Interestingly, the second ``localizer(top, left, height, width)`` function accepts the parameters in the right order, but return landmarks in non-Bob-conform order.https://gitlab.idiap.ch/bob/bob/-/issues/179No support of log determinant2014-01-04T16:02:46ZAndré AnjosNo support of log determinant*Created by: laurentes*
As said [here](http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.det.html), determinant computation is subject to underflow/overflow.
When computing log determinant, this might be avoided by dir...*Created by: laurentes*
As said [here](http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.det.html), determinant computation is subject to underflow/overflow.
When computing log determinant, this might be avoided by directly working in the log domain. In the python universe, we may rely on numpy.linalg.slogdet(). We should consider to provide such a function in the C++ universe.
Currently, the PLDAMachine class may be subject to underflow/overflow.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/180bob nosetest fails on Mac OS 10.8.52016-08-04T09:32:33ZAndré Anjosbob nosetest fails on Mac OS 10.8.5*Created by: tcgeophysics*
I am running into an error with the ``` make nosetests ``` step of the compiling from source process.
I am using a Mac OS Mountain Lion 10.8.5 (64bits) and installing bob with homebrew.
The following is in...*Created by: tcgeophysics*
I am running into an error with the ``` make nosetests ``` step of the compiling from source process.
I am using a Mac OS Mountain Lion 10.8.5 (64bits) and installing bob with homebrew.
The following is installed:
Homebrew
HOMEBREW_VERSION: 0.9.5
CPU: 8-core 64-bit ivybridge
OS X: 10.8.5-x86_64
Xcode: 5.0.2
CLT: 5.0.1.0.1.1377666378
X11: 2.7.5
Python: 2.7.6
Nose: 1.3.0
VLFEAT is not installed and ``` -DWITH_VLFEAT=OFF ``` is specified
I wrote a homebrew formula to install bob and it seems to work for now without the nosetests step. [bob.q formula here](https://gist.github.com/tcgeophysics/8156717)
To repeat the problem
1 - install homebrew,
2 - Create a bob formula: ```brew create http://www.idiap.ch/software/bob/packages/bob-1.2.2.tar.gz```
3 - Edit the bob formula: ```brew edit bob```
delete everything and paste the contents of the [bob.q formula here](https://gist.github.com/tcgeophysics/8156717)
4 - Run ```brew install -v bob``` to install in debug mode
The install process does not complete with nosetests and exit with the following message:
```
======================================================================
ERROR: bob.io.test.test_video.test_frameskip_format_mov_codec_wmv1
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/test/utils.py", line 108, in wrapper
return test(*args, **kwargs)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/io/test/test_video.py", line 71, in check_format_codec
orig, framerate, encoded = function(shape, framerate, format, codec, fname)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/io/utils.py", line 145, in frameskip_detection
fontsize = estimate_fontsize(height, width, text_format)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/io/utils.py", line 32, in estimate_fontsize
font = ImageFont.truetype(DEFAULT_FONT, best_size)
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/ImageFont.py", line 218, in truetype
return FreeTypeFont(filename, size, index, encoding)
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/ImageFont.py", line 134, in __init__
self.font = core.getfont(file, size, index, encoding)
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/ImageFont.py", line 34, in __getattr__
raise ImportError("The _imagingft C module is not installed")
ImportError: The _imagingft C module is not installed
======================================================================
FAIL: test01_plda_EM_vs_Python (bob.trainer.test.test_plda.PLDATrainerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/trainer/test/test_plda.py", line 391, in test01_plda_EM_vs_Python
self.assertTrue(numpy.allclose(m.f, m_py.f))
AssertionError: False is not true
-------------------- >> begin captured logging << --------------------
bob.c++: INFO: # EMTrainer:
bob.c++: INFO: # Iteration 1
bob.c++: INFO: # Iteration 2
bob.c++: INFO: # Iteration 3
bob.c++: INFO: # Iteration 4
bob.c++: INFO: # Iteration 5
bob.c++: INFO: # Iteration 6
bob.c++: INFO: # Iteration 7
bob.c++: INFO: # Iteration 8
bob.c++: INFO: # Iteration 9
bob.c++: INFO: # Iteration 10
bob.c++: INFO: # EM terminated: maximum number of iterations reached.
--------------------- >> end captured logging << ---------------------
----------------------------------------------------------------------
Ran 467 tests in 133.735s
FAILED (SKIP=4, errors=100, failures=1)
make[3]: *** [python/CMakeFiles/nosetests] Error 1
make[2]: *** [python/CMakeFiles/nosetests.dir/all] Error 2
make[1]: *** [python/CMakeFiles/nosetests.dir/rule] Error 2
make: *** [nosetests] Error 2
```
The full nosetests output can be found on this gist:
https://gist.github.com/tcgeophysics/8286521
Any advices on how to solves the issues pointed out by the nose output? Are they critical for bob?
It seems there is a problem with PIL which might not be maintained anymore.
Could PILLOW work instead?