skimage.morphology.watershed приводит к смерти 32-битного ядра - PullRequest
Новая
       39

skimage.morphology.watershed приводит к смерти 32-битного ядра

0 голосов
/ 08 июня 2018

При использовании Python 3.6.4 32-Bit с версией Skimage 0.13.1 следующий код приводит к умирающему ядру: 

from scipy.io import loadmat
import skimage.morphology
import skimage.feature
import scipy
import numpy as np
import psutil
import os

process = psutil.Process(os.getpid())
print('Mem usage %4.1f MB after imports\n'%(process.memory_info().vms / float(2 ** 20)))
data = loadmat('demoData.mat')
print('Mem usage %4.1f MB after loading the data'%(process.memory_info().vms / float(2 ** 20)))
print('Mem available: %4.1f MB\n'%(psutil.virtual_memory().available/float(2 ** 20)))

#Just show the input data
#import matplotlib.pyplot as plt
#plt.figure('Watershed')
#plt.clf()
#plt.imshow(data['pic'])


#%%Do some Calculations
l = 10 # hysteresis for Canny edge detector lower limit
h = 20 # hysteresis for Canny edge detector high limit
sigma = 0.1

gradient = skimage.filters.sobel(data['pic'])
# find forground and background
l,h = 10, 20 # hysteresis for Canny edge detector

cannyPic = skimage.feature.canny(data['pic'], sigma = sigma, low_threshold=l, high_threshold=h)
print('Mem usage %4.1f MB after CannyPic'%(process.memory_info().vms / float(2 ** 20)))
print('Mem available: %4.1f MB\n'%(psutil.virtual_memory().available/float(2 ** 20)))

markers = cannyPic == 0
print('Mem usage %4.1f MB after markers'%(process.memory_info().vms / float(2 ** 20)))
print('Mem available: %4.1f MB\n'%(psutil.virtual_memory().available/float(2 ** 20)))

seg = np.ones((3,3))
markers, numFeatures = scipy.ndimage.measurements.label(markers, seg)
print('Mem usage %4.1f MB after label'%(process.memory_info().vms / float(2 ** 20)))
print('Mem available: %4.1f MB\n'%(psutil.virtual_memory().available/float(2 ** 20)))

#***** Crash occurs in the line below ****
labels = skimage.morphology.watershed(gradient, markers)
print('Mem usage %4.1f MB after watershed'%(process.memory_info().vms / float(2 ** 20)))
print('Mem available: %4.1f MB\n'%(psutil.virtual_memory().available/float(2 ** 20)))

Он отлично работает с 64-битной версией иэто прекрасно работает для небольших изображений.Поэтому я догадался, что может быть проблема с памятью.Но, судя по выводам более ранних вызовов sobel, canny и маркеров, использование памяти не является критически высоким, и остается много доступной памяти.Вывод выглядит следующим образом:

Python 3.6.4 | Anaconda custom (32-bit) |(по умолчанию, 16 января 2018 г., 10:21:59) [MSC v.1900 32 бит (Intel)]
IPython 6.2.1 - улучшенный интерактивный Python.
runfile ('H: / CVS / python/171213Koexexperimente/32BitCrashWatershedExample.py ', wdir =' H: / CVS / python / 171213Koexexperimente ')
Использование памяти 180,1 МБ после импорта

Использование памяти 262,7 МБ после загрузки данных
Доступно памяти:2790,7 МБ

Память используется 355,6 МБ после CannyPic
Память доступна: 2723,8 МБ

Память используется 365,9 МБ после маркеров
Память доступна: 2717,2 МБ

Память используется396,8 МБ после метки
Память доступна: 2682,6 МБ


Ядро умерло, перезапуск

Просто переключиться на 64-битную версию сложно, так как этот код должен использоватьсяв библиотеке, вызываемой другим 32-разрядным программным обеспечением, которое нельзя легко перенести в 64-разрядное.И разделение большого изображения на меньшие изображения и их обработка тоже не были полностью стабильными.Для различных установок использование изображений размером 1000 на 1000 пикселей работало большую часть времени, но не обязательно, если вызывалось повторно.

Вопросы:
1. Как найти основную причину умирающего ядра?
2Может быть, это неуклюжее использование памяти в водоразделе, если это вообще память?
3. У кого-нибудь есть идеи, как заставить это работать?

Все советы приветствуются.

Демонстрационные данные и код можно найти в http://ascona -cloud.de / index.php / s / hFaqbEkv5PUW820

...