borevitzlab / timestreamlib

DEPRECATED. Please use the current version of the TimeStream tools at https://gitlab.com/appf-anu/pyts2.
https://gitlab.com/appf-anu/pyts2
GNU General Public License v3.0
7 stars 4 forks source link

Windows error on resize #145

Open Joelgranados opened 9 years ago

Joelgranados commented 9 years ago

This error only happens for a few images. The rest of the images are resized correctly. here is the traceback:

Traceback (most recent call last):
  File ".\run-pipeline.py", line 300, in run
    self._pl, self._log, prsig=self._prsig, stsig=self._stsig)
  File ".\run-pipeline.py", line 244, in runPipeline
    result = pl.process(ctx, [img], plConf.general.visualise)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\timestream-ddfae7d-py2.7.egg\timestream\manipulate\pipeline.py", line 96, in pr
ocess
    res = elem(contArgs, *res)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\timestream-ddfae7d-py2.7.egg\timestream\manipulate\pipecomponents.py", line 109
, in __call__
    retVal = self.__exec__(context, *args)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\timestream-ddfae7d-py2.7.egg\timestream\manipulate\pipecomponents.py", line 109
1, in __exec__
    img.pixels = skimage.transform.resize(img.pixels, self.resolution)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\timestream-ddfae7d-py2.7.egg\timestream\__init__.py", line 925, in pixels
    self.read(fpath=self._path)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\timestream-ddfae7d-py2.7.egg\timestream\__init__.py", line 809, in read
    self._pixels = read_image(fpath)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\timestream-ddfae7d-py2.7.egg\timestream\parse\__init__.py", line 370, in read_i
mage
    return skimage.io.imread(path, plugin="freeimage")
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\skimage\io\_io.py", line 97, in imread
    img = call_plugin('imread', fname, plugin=plugin, **plugin_args)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\skimage\io\manage_plugins.py", line 209, in call_plugin
    return func(*args, **kwargs)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\skimage\io\_plugins\freeimage_plugin.py", line 678, in imread
    img = read(filename)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\skimage\io\_plugins\freeimage_plugin.py", line 400, in read
    return _process_bitmap(filename, flags, _array_from_bitmap)
  File "C:\Users\Phenocam Admin\Desktop\virtenvs\timestreamlib\lib\site-packages
\skimage\io\_plugins\freeimage_plugin.py", line 382, in _process_bitmap
    bitmap = _FI.FreeImage_Load(ftype, filename, flags)
WindowsError: exception: access violation writing 0x0000000000000019
kdm9 commented 9 years ago

Joel,,

I think this is related to the segfault I found in their freeimage wrapper. I'm not sure of what we can do on windows to fix it, currently we pip install from the upstream git repo as they haven't done a release since I fixed that bug. I assume the Golkhe guy hasn't recompiled from git on windows, so we're stuck with the broken version.

K

Joelgranados commented 9 years ago

Are you referring to 144 in timestream? if you are, what suggests this is the same bug?

1) This is a bug from phenocam.anu.edu.au and that server does not have the corrupted image from 144. The corrupted image occurred when I copied images from the server and one "didn't make it" 2) The traceback that I pasted here only happens on windows. I tested with the same configuration and I did not see it in my linux box 3) I have only seen 144 on my linux machine. It probably is triggered on Windows as well but I have not tested.

Additionally, if this was a segfault, the execution would stop. For my tests the resizing continued despite the traceback. I think this traceback is happening on one of the qt threads from pipeline -g, but am not 100% sure.

kdm9 commented 9 years ago

Actually I was referring to https://github.com/scikit-image/scikit-image/issues/1037

But your points still stand. It's not that.

However, #144 may be the result of that bug.

Cheers, K

On Sun, Nov 30, 2014 at 11:02:56PM -0800, Joel Andres Granados wrote:

Are you referring to 144 in timestream? if you are, what suggests this is the same bug?

1) This is a bug from phenocam.anu.edu.au and that server does not have the corrupted image from 144. The corrupted image occurred when I copied images from the server and one "didn't make it" 2) The traceback that I pasted here only happens on windows. I tested with the same configuration and I did not see it in my linux box 3) I have only seen 144 on my linux machine. It probably is triggered on Windows as well but I have not tested.

Additionally, if this was a segfault, the execution would stop. For my tests the resizing continued despite the traceback. I think this traceback is happening on one of the qt threads from pipeline -g, but am not 100% sure.


Reply to this email directly or view it on GitHub: https://github.com/borevitzlab/timestreamlib/issues/145#issuecomment-65027316