LINUX.ORG.RU

python-lcms2 v0.1

 ,


2

3

sK1 Project выпустил первую стабильную версию привязки библиотеки для управления цветом LittleCMS2 к Python.

Пакет python-lcms2 позволяет написанным на Python приложениям конвертировать цвета из одного цветового пространства в другое с помощью функций LittleCMS2, используя ICC-профили. На текущий момент поддерживаются цветовые пространства RGB, CMYK, Gray, Lab и XYZ и глубина цвета 8-bit, 16-bit и дробные двойной точности (double).

Причина появления такого минипроекта — отсутствие официальной привязки. На текущий момент Марти Мария, автор LCMS2, рекомендует использовать системную libcolord через интерфейс GObjectIntrospection, что ограничивает портируемость ПО пределами Linux-десктопа.

В sK1/UniConvertor привязка к LCMS2 была написана еще в 2012 году. Но по просьбе разработчика SwatchBooker был выполнен рефакторинг с целью выделения кода в отдельный проект, который может использоваться другими приложениями так же, как ранее использовался пакет python-lcms (официальная привязка к LCMS1).

>>> Подробности

кто на ком стоял? потрудитесь изъясняться точнее.

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

Поясняю: LittleCMS де-факто основная библиотека для управления цветом в опенсурсе. LCMS1 имела привязку к питону. Потом автор подзабил на нее и предложил пользоваться питонистам опосредованно через libcolord. Поэтому для страждущих и сделали это сабжевое нативное расширение.

Linfan ★★★★★ ()

А изначальным толчком что было? Какие-то части sK1 Project написаны на питоне?

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

в sK1/UniConvertor логика на питоне, числодробилки на сцях. Питон позволил почти завершить разработку малыми силами за относительно приемлимое время. Полностью нативный код можно было бы пилить еще лет пять.

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

Когда Марти выпустил LittleCMS v2, привязки он обновлять не стал. И все приложения на Пайтоне сразу отвалились.

AP ★★★★★ ()
svn checkout https://github.com/sk1project/python-lcms2 python-lcms2


ШТОА? :)

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

А зачем функционал DVCS подавляемому большинству пользователей? У гитхаба есть svn-морда. Для взятия сорцов ее более чем. А локальная ветка репозитория нафик не нужна трудящимся.

Кстати, большинству проектов тоже это не уперлось - когда один-полтора разраба, работа идет в режиме SVN и функционал распределенного вершинкотрола не используется.

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

А зачем функционал DVCS подавляемому большинству пользователей?

Кем оно подавляется? :)

Кстати, большинству проектов тоже это не уперлось

Я лично не знаком с большинством проектов, а ты, видно, все пересмотрел. Придётся поверить тебе на слово :)

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

Кем оно подавляется? :)

Знамо дело - масонами, мировой закулисой и рептилоидами :)

Linfan ★★★★★ ()

Если там только матан, зачем писать на медленном питоне?

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

Полностью нативный код можно было бы пилить еще лет пять.

Так нужно было на Qt клепать, а не на гтк с сишкой.

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

как раз таки матана в GUI аппликухах очень и очень мало. В основном логика.

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

Насколько я знаю Qt, описание на нем интерфейса будет в 2-3 раза больше просто по объему кода, чем на питоне с Widgetset Abstraction Layer. Сейчас в репе ~2Mb питонского кода. На кутях будет 4-6 метров. Это по объему в районе ПСС дедушги Ленина :)

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

Там вообще ничего не нужно описывать, ибо можно клепать .ui файлы. Всяко лучше долбатни с wxWidgets.

Код в мегабайтах - это что-то странное. Насчитал 75к строк кода в /src. Не густо конечно, но вам виднее.

В остальном вкусовщина: нравится питон - страдайте. Ну или как минимум PyQt используйте.

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

Насчитал 75к строк кода в /src.

Как считал? Просто интересна метода.

Кстати, 75к это на питоне. На крестецах будет ~200к. Но дело не в пузомерках. Главное довести до релиза проект.

Там вообще ничего не нужно описывать, ибо можно клепать .ui файлы.

Это подходит только для статичных диалогов. И опять же - сгенерированный код залог качественных тормозов :)

Ну или как минимум PyQt используйте.

Не, пасиб. Widgetset Abstraction Layer (это не wxWidgets) как-то надежнее.

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

Как считал? Просто интересна метода.

https://github.com/Aaronepower/tokei

Это подходит только для статичных диалогов.

И что под этим подразумевается?

И опять же - сгенерированный код залог качественных тормозов

Только в ваших фантазиях.

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

Только в ваших фантазиях.

На хеллоуворлдах не проявляется, эт верно :)

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

В репах болтается прототип sK1 на pyqt. По нему оценивал и ресурсы и сгенеренные окошки и отказался от этого пути. Подтормаживать начало весьма быстро. Правда сейчас он уже нерабочий - базовая часть (UniConvertor) ушла далеко вперед и несовместима со старым прототипом.

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

Подтормаживать может только при создании окон. На работу это никак не влияет.

И это при условии, что текущая версия на wxWidget всё равно сильно тормозит.

По нему оценивал и ресурсы

Смысл оценить ресурсы в приложении на python? Он не для этого предназначен.

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

Подтормаживать может только при создании окон.

Об этом и речь. Бонусом - большее потребление памяти. В нонешнее время вроде и не принято ее экономить. Но как-то неприятно когда прототип на Qt жрет на старте 40-50 метров вместо 20 метров как у прототипа на gtk.

Кроме того, ui-файлы это жесткое прикручивание к Qt. Эт из личной фобии, связанной с tk - весь GUI пришлось переписывать из-за проблем с виджетсетом.

текущая версия на wxWidget всё равно сильно тормозит

Что конкретно тормозит?

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

Бонусом - большее потребление памяти.

ui не увеличивают потребление памяти.

40-50 метров вместо 20 метров как у прототипа на gtk.

Зависит от того, как вы измеряли. У меня hello world жрёт 3МБ + 30МБ shared memory. Проект посерьезней, 30К строк кода, 8МБ + 42МБ shared.

Кроме того, ui-файлы это жесткое прикручивание к Qt.

То есть написанные руками формочки легко можно перенести на новый фреймворк, а ui - нет?

Что конкретно тормозит?

Всё.

В общем все симптомы тулкитофоба.

RazrFalcon ★★★★★ ()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

ui не увеличивают потребление памяти.

Увеличивают, но не существенно, если сравнивать с самим тулкитом.

У меня hello world жрёт 3МБ + 30МБ shared memory. Проект посерьезней, 30К строк кода, 8МБ + 42МБ shared.

Если десктоп не кде, это проявляется в полный рост. Те же тормоза на старте аппликухи.

Всё

угу, понятно - вэиксфобия :) Если что-то и тормозит, то только канва. И ее скорость работы не зависит от тулкита, а упирается в производительность cairo.

В общем все симптомы тулкитофоба.

Стопуд! Причем в отношении всех тулкитов :) Паттерн Widgetset Abstraction Layer позволяет использовать в бэкэнде и wx и kde и qt - короче любой зрелый тулкит. Причем без переписывания основной части кода.

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

Если десктоп не GNOME, это проявляется в полный рост. Те же тормоза на старте аппликухи.

fixed

И да, тормоза только на втором пне будут видны. Да и о каких тормозах может идти речь, есть прога на питоне?

И ее скорость работы не зависит от тулкита, а упирается в производительность cairo.

А там есть что-то кроме канвы?

RazrFalcon ★★★★★ ()
Последнее исправление: RazrFalcon (всего исправлений: 2)
Ответ на: комментарий от RazrFalcon

Если десктоп не GNOME, это проявляется в полный рост. Те же тормоза на старте аппликухи.

fixed

Неа, не фиксед. Я по венде обычно сужу. Для чистоты экперименту )))

Да и о каких тормозах может идти речь, есть прога на питоне?

Нууу... пейсателям всегда пистон мешает.

А там есть что-то кроме канвы?

)))) https://youtu.be/1qDRClemtuI?t=345

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

Нууу... пейсателям всегда пистон мешает.

То есть wxWidgets быстрее и легче Qt, но в то же время и python быстрее и легче C++? Странные вещи вы пишете.

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

но в то же время и python быстрее и легче C++?

Питон безусловно медленнее крестцов. Глупо утверждать обратное, равно как и глупо нагружать питон задачами, которые требуют скорость.

Взаимодействие юзьверя с UI весьма медленное. Получить и обработать логику эвента может и питон. А рендеринг канвы - совершенно не питонская задача. В sK1 это на сцях решается по-большей части. И виджетсет тут никаким боком. Только в самом конце итерации рендеринга происходит выгрузка изображения на окно, предоставляемое виджетсетом.

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

Ты, кстати, не заглядывал в код тулкита «mlib»? (На котором написан AzPainter 2.x.x).

За счет чего там такая высокая скорость рендеринга канвы?

Может, испытал бы «mlib» в качестве GUI?

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

Еще раз: рендеринг канвы от тулкита не зависит. Совсем не зависит. Ваапще не зависит.

За счет чего там такая высокая скорость рендеринга канвы?

Скорее всего за счет кеширования. В растровом редакторе только один вид объектов - слой битмапа.

Может, испытал бы «mlib» в качестве GUI?

)))) Предлагаешь переписать заново все? Хочешь смерти со смеху для AP? )))))

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

Да! )))))))

P.S.: sK1 должен быть портирован на все возможные тулкиты. Я так считаю ;-)

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

В растровом редакторе только один вид объектов - слой битмапа.

А как же рамки выделения и инструменты кривых в окне AzPainter? По логике, это должны быть векторные объекты

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

А как же рамки выделения и инструменты кривых в окне AzPainter? По логике, это должны быть векторные объекты

Рамка выделения векторная? Только на том основании, что у неё есть координаты? :)

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

В растровом редакторе только один вид объектов - слой битмапа.

Парни, вы меня оба решили смехом убить? :)

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

AzPainter вектор не саппортит. А на гимп не ссылайся - он уже комбинированный редактор, а не чисто растровый.

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

Ну тогда sK1 — тоже комбинированный редактор, потому что позволяет делать простые вещи с битмапами :) Или не позволяет? :)

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

Пока еще нет - простое редактирование битмапов запланировано (обрезка, простенькое затирание и т.п.) но не реализовано еще. Сейчас это по сути ректангл с заливкой битмапом.

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

Но всё же, одно из первых что хотелось бы для битмапов, так это настройка DPI для монитора и для экспорта в PNG

https://github.com/sk1project/sk1-wx/issues/22

https://github.com/sk1project/sk1-wx/issues/42

P.S.: набросал тут шаблон ROADMAP для wiki

https://github.com/sk1project/sk1-wx/wiki/ROADMAP

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

что хотелось бы для битмапов, так это настройка DPI для монитора

Зачем настройка DPI для монитора? Какой сакральный смысл в этом?

для экспорта в PNG

Изменение в размерах экспортируемого битмапа нужная вещь, позже добавим.

набросал тут шаблон ROADMAP для wiki

Эт мы сами справимся после релиза :) Сейчас не стоит распыляться на вангование или описание в роадмапе того, что уже сделано.

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

Кстати, как называется фон, на этом скриншоте серый без шахматки, в рабочем окне? (ниже канваса; типа «стол»,«скатерть») Нужно для перевода

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