Обработка изображений, в Python? [закрытый]
Хорошо - существуют некоторые очень хорошие ответы здесь, но почти все они, кажется, делают ту же ошибку, и это - то, которое проникает в общее использование.
Неофициально, мы пишем, что f (n) = O (g (n)), если, до масштабного коэффициента и для всех n больше, чем некоторый n0, g (n) больше , чем f (n). Таким образом, f (n) не выращивает более быстрого , чем или ограничены от вышеупомянутого , g (n). Это ничего не говорит нам о том, как быстро f (n) растет, сохраните для того, что он, как гарантируют, не будет немного хуже, чем g (n).
пример бетона А: n = O (2^n). Все мы знаем, что n растет намного менее быстро, чем 2^n, так, чтобы дал право нам говорить, что он ограничен вышеупомянутым показательной функцией. Существует много комнаты между n и 2^n, таким образом, это не очень трудно связанный, но это - все еще связанное законное.
, Почему, мы (программисты) используем границы вместо того, чтобы быть точными? Поскольку a) границы часто легче доказать и b) это дает нам стенографию для выражения свойств алгоритмов. Если я говорю, что мой новый алгоритм является O (n.log n), который означает, что в худшем случае его время выполнения будет ограничено сверху n.log n на исходных данных n для достаточно большого n (хотя видят мои комментарии ниже о том, когда я не мог бы иметь в виду худший случай).
, Если вместо этого, мы хотим сказать, что функция растет точно так же быстро как некоторая другая функция, мы используем тета для высказывания того мнения (я запишу T (f (n)) для значения \Theta f (n) в скидке с цены). T (g (n)) стенография для того, чтобы быть ограниченным от [1 120] выше и ниже g (n), снова, до масштабного коэффициента и асимптотически.
, Который является f (n) = T (g (n)) < => f (n) = O (g (n)) и g (n) = O (f (n)). В нашем примере мы видим это n! = T (2^n), потому что 2^n! = O (n).
, Почему касаются этого? Поскольку в Вашем вопросе Вы пишете, 'был бы, кто-то должен курить трещину для записи O (x!)?' Ответ нет - потому что в основном все, что Вы пишете, будет ограничено сверху функцией факториала. Время выполнения quicksort является O (n!) - это - просто не связанное трудное.
существует также другой размер тонкости здесь. Обычно мы говорим о , худший случай ввел , когда мы используем O (g (n)) нотация, так, чтобы мы сделали составной оператор: в худшее время выполнения случая это не будет немного хуже, чем алгоритм, который берет g (n) шаги, снова масштабирование по модулю и для достаточно большого n. Но иногда мы хотим говорить о времени выполнения среднее число и даже лучший случаи.
Ваниль quicksort является, как всегда, хорошим примером. Это - T (n^2) в худшем случае (это на самом деле сделает, по крайней мере, шаги n^2, но не значительно больше), но T (n.log n) в среднем случае, который должен сказать, что ожидаемое количество шагов пропорционально n.log n. В лучшем случае это также T (n.log n) - но Вы могли улучшить это для примером, проверив, был ли массив уже отсортирован, в этом случае, лучшее время выполнения случая было бы T (n).
, Как это касается Вашего вопроса о практической реализации этих границ? Ну, к сожалению, O () нотация скрывает константы, с которыми должны иметь дело реальные реализации. Таким образом, хотя мы можем сказать, что, например, для T (n^2) операция должны посетить каждую возможную пару элементов, мы не знаем, сколько раз мы должны посетить их (за исключением того, что это не функция n). Таким образом, нам придется посетить каждую пару 10 раз, или 10^10 времена, и T (n^2) оператор не делает различия. Функции более низкоуровневые также скрыты - нам придется посетить каждую пару элементов однажды, и каждый отдельный элемент 100 раз, потому что n^2 + 100n = T (n^2). Идея позади O () нотация - то, что для достаточно большого n, это не имеет значения вообще, потому что n^2 становится настолько больше, чем 100n, что мы даже не замечаем влияние 100n на времени выполнения. Однако мы часто имеем дело с 'достаточно маленьким' n, таким образом, что постоянные множители и так далее имеют реальное, значительное значение.
, Например, quicksort (средняя стоимость T (n.log n)) и пирамидальная сортировка (средняя стоимость T (n.log n)) оба сортируют алгоритмы с той же средней стоимостью - все же quicksort, обычно намного быстрее, чем пирамидальная сортировка. Это вызвано тем, что пирамидальная сортировка делает еще несколько сравнений на элемент, чем quicksort.
Нельзя сказать, что O () нотация бесполезен, просто неточен. Это - настоящий тупой инструмент для владения для маленького n.
(Как заключительное примечание к этому трактату, помните, что O () нотация просто описывает рост любой функции - должно не обязательно быть время, это могла быть память, сообщения, которыми обмениваются в распределенной системе или количестве центральных процессоров, требуемых для параллельного алгоритма.)
2 ответа
There's also pycairo, which might be more suitable depending on your needs.
У вас также есть подход к обработке изображений, основанный на "стандартных" научных модулях: SciPy имеет целый пакет, посвященный обработке изображений: scipy.ndimage . Scipy - это, по сути, стандартный пакет общих численных расчетов; он основан на де-факто стандартном модуле манипулирования массивами NumPy : изображениями также можно манипулировать как массивы чисел. Что касается отображения изображений, то Matplotlib (также часть «научной трилогии») упрощает отображение изображений .
SciPy все еще активно поддерживается, так что это хорошее вложение в будущее. Кроме того, SciPy в настоящее время также работает с Python 3, а Python Imaging Library (PIL) - нет.