LINUX.ORG.RU

GNU Guile-CV 0.2.0

 , , , ,


1

1

  Guile-CV — это библиотека компьютерного зрения для языка программирования GNU Guile, являющаяся привязкой к библиотеке Vigra, написанной на C++, и работающая через прослойку Vigra C. Guile — реализация языка Scheme, диалекта Lisp.

Изменения в новой версии:

  • Изменения пути установки

      Теперь они таковы:

    $(datadir)/guile-cv
    $(libdir)/guile-cv/guile/$(GUILE_EFFECTIVE_VERSION)/site-ccache
      Где $(datadir) соответствует /usr/share/share, а $(libdir)/usr/share/lib; если указан ключ --prefix]/ваш/префикс/share и /ваш/префикс/lib соответственно. $(GUILE_EFFECTIVE_VERSION) заменяется на номер стабильной версии Guile, с которой собирается Guile-CV — например, 2.2.

      Это изменение делает GNU Guile-CV совместимой со Стандартами Кодирования GNU, но оно также подразумевает, что, если не использовать описанные ниже опции конфигурации — придётся дополнить переменные %load-path и %load-compiled-path двумя вышеуказанными путями соответственно, чтобы Guile нашёл установленные модули исходников и скомпилированные файлы Guile-CV (подробности см. в руководстве по установке Guile-CV).

  • Новые опции конфигурации

      Добавлена опция конфигурации --with-guile-site, использующаяся для явного указания необходимости установки исходных модулей Foliot в директорию site Guile-Gnome, а скомпилированных файлов — в директорию site-ccache (подробности см. в руководстве по установке Foliot).

      Опция будет учтена, только если указана в виде:

    --with-guile-site=yes

    (в таком случае, разумеется, нет нужды расширять переменные Guile %load-path и %load-compiled-path)

  • Интерфейсные изменения

      Матричная версия метода im-multiply сделана процедурой im-mtimes. Скалярная версия переименована в im-times и оставлена методом. То же самое произошло с методом im-multiply: он разбит на матричную процедуру im-mtimes-channel и скалярный метод im-times-channel. Матричные методы im-divide и im-divide-channel преобразованы в процедуры im-mdivide и im-mdivide-channel соответственно.

  • Новые интерфейсы:
    • im-times (поэлементный)
    • im-times-channel
    • im-divide (поэлементный)
    • im-divide-channel
    • im-texture
    • im-glcp
    • im-glcm
  • Улучшения производительности:
    • im-mtimes
    • im-mtimes-channel
    • im-mdivide
    • im-mdivide-channel
    • im-invert
    • im-invert-channel

      Эти матричные операции (точнее говоря, соответствующая функциональность ядра f32vector-*) вынесены в libguile-cv. Учтите, что все выделения памяти — не считая некоторых локальных переменных в функциях — до сих пор происходят через Scheme.

      Благодаря этому выносу умножение маленькой чёрно-белой матрицы с изображением 515x515 самой на себя стала выполняться за 0.028 секунд вместо 29.51 — в 134 раза быстрее.

>>> Источник



Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 1)

 Guile-CV — это библиотека компьютерного зрения для языка программирования GNU Guile, являющаяся привязкой к библиотеке Vigra, написанной на C++, и работающая через прослойку Vigra C

И о б этом целая новость? Про прослойку сделанную через прослойку?

anonymous
()

Она может конкурировать с OpenCV/dlib?

dnb ★★★★
()

к библиотеке Vigra

Интересно.

Deleted
()
Ответ на: комментарий от ados

Прокладка между клитором тхинкпада и Пифагоровыми штанами.

bodqhrohro_promo
() автор топика
Ответ на: комментарий от gpyra

Априори — да. Но у первых шкафов-калькуляторов не было и того, чем располагают нонешни. А то ли ещё будет. Сегодня на векторные шрифты во все поля ресурсов хватает, завтра на шебню, послезавтра на компьютерное зрение.

bodqhrohro_promo
() автор топика

28ms на такой матмал - прощай риалтайм

yoghurt ★★★★★
()
Ответ на: комментарий от gpyra

Нет уж, давайте без априори, что значит «слеп»?

A-234 ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Глифы кешируются. Без кэширования никакой мощности не хватит для комфортной работы.

anonymous
()
Ответ на: комментарий от anonymous

Я про избыточные вычисления (привет макакенам) не говорил. Смотри, тебе даже чтобы сгенерировать полный кэш хрюникодного шрифта на каком-нибудь Z80, да ещё под много размеров — понадобилось бы несколько часов. А если не генерировать, пришлось бы где-то хранить — где, когда ценен каждый мегабайт? Да и хрюникода не было, чего уж там, кек. И пикселы были такие огромные, что уж лучше сделать красивый растровый шрифт, чем пытаться хитрожопыми техниками сгладить векторный.

bodqhrohro_promo
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.