Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс июн 25, 2017 8:28 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 65 сообщений ]  На страницу 1 2 3 4 5 След.
Автор Сообщение
 Заголовок сообщения: libimg
СообщениеДобавлено: Пн май 02, 2011 8:28 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
Доброго всем времени суток!

Решил создать для libimg отдельную тему по следующим причинам:
  • libimg используется далеко не только в kiv, разумно продолжать разговоры о ней в данной теме, а не в теме kiv
  • добавил возможность чтения формата xcf (собственно, повод для поста)

Теперь подробнее. Xcf - родной формат для GIMP. Он поддерживает, кроме всего прочего, слои и режимы смешивания. Таким образом, в libimg теперь есть функции для слияния слоёв. Кроме того, для некоторых режимов смешивания понадобились преобразования цветовых пространств RGB<->HSV и RGB<->HSL. Эти функции в дальнейшем имеет смысл перенести в libimg.asm, но xcf - это первый многослойный формат, с которым я близко познакомился, и поэтому я не стал спешить. Когда будет добавляться поддержка другого многослойного формата, будет лучше видно, что и в каком виде следует туда перенести.

Поддержка формата не полная (нет текстовых слоёв), но остальное должно работать. Например, маски и невидимые слои:
Изображение

Поддерживаются изображения с палитрой, в оттенках серого, rgb. Вот то, ради чего это всё затевалось (kolibri_wallpaper_release.xcf):
Изображение

Функции слияния пикселей с учётом альфа-канала написаны и использованием MMX. Впервые работал с MMX, сильно не бейте если что. Понимаю, что есть компьютеры, не поддерживающие эту технологию (а есть и с sse*), поэтому все подобные функции вынесены в отдельный файл composite_mmx.inc, подключаемый условной компиляцией
Код:
COMPOSITE_MODE      equ     MMX
...
match =MMX,COMPOSITE_MODE{include 'composite_mmx.inc'}
Потом можно добавить, например, composite_none.inc и composite_sse.inc и подключать при надобности их. Что-то вроде ключей компиляции)


Теперь у меня пара вопросов:
  1. Влияет ли на производительность смешивание MMX инструкций с обычными? Или MMX только с FPU не дружит? (читал, что регистры MMX хранят мантиссы чисел при операциях с FPU, поэтому предполагаю ответ нет)
  2. Критичен ли для скорости вызов небольшой функции при обработке каждого пикселя? Имеет ли смысл дублировать небольшие куски кода во избежание лишних call'ов?

Размер libimg.obj увеличился на 6170 байт в несжатом виде. Ревизия 1921.
Если на каких-то изображениях вылетает или показывает неправильно - прикрепляйте, постараюсь исправить.


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Пн май 02, 2011 10:18 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн окт 27, 2008 10:10 pm
Сообщения: 740
Есть страница на вики http://wiki.kolibrios.org/wiki/Libimg/ru
на которой пример использования libimg, возможно есть смысл добавить туда (хотя бы краткую) информацию о функциях библиотеки и их описание?


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Пн май 02, 2011 10:43 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
IgorA писал(а):
Есть страница на вики http://wiki.kolibrios.org/wiki/Libimg/ru
на которой пример использования libimg, возможно есть смысл добавить туда (хотя бы краткую) информацию о функциях библиотеки и их описание?

Да, я уже давно art_zh обещал это сделать. Я держу в голове.


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Вт май 03, 2011 3:27 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1593
"Влияет ли на производительность смешивание MMX инструкций с обычными?" - нет.
"Или MMX только с FPU не дружит?" - регистры MMX физически являются частями регистров FPU, поэтому одновременная работа с MMX и FPU невозможна архитектурно - независимо от вопросов производительности - и любые команды MMX делают невозможным использование FPU вплоть до команды очистки emms.
"Критичен ли для скорости вызов небольшой функции при обработке каждого пикселя? Имеет ли смысл дублировать небольшие куски кода во избежание лишних call'ов?" - Да. Да. На критичных по скорости участках можно и раздуть код по размеру, если это обеспечит выигрыш в скорости.

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Пт фев 24, 2012 2:57 am 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
Поддержка форматов: tiff (baseline), wbmp, pnm (pbm/pgm/ppm).
Функции слияния слоёв (xcf) теперь и на sse (опционально, включается в xcf.asm; по умолчанию, как и раньше, mmx).


Из tiff поддерживается только baseline. Это означает, что многие файлы могут не открываться. Но baseline он на то и BASEline, что сначала он, а расширения, возможно, потом.

Пока делал tiff и сдавал сессию, наткнулся на wbmp и pnm. Решил, что проще написать их, чем убеждать себя, что они не нужны.

Wbmp почти ничего не умеет, поэтому поддерживается полностью. О нём как-то писал на форуме Gluk.

Pnm поддерживается для глубины канала не больше 8 бит, т.к. 16-битный цвет libimg не умеет.

С sse работал впервые, код не блещет, но по крайней мере работает.


Коммиты, касающиеся wbmp, сделаны отдельно от остальных, чтобы по "svn diff -c 2392" можно было получить пример минимального кода, необходимого для добавления поддержки нового формата в libimg. Это шаг к документации по libimg, насчёт которой art_zh писал мне ещё 25.08.2010. А так как обещанного два года ждут, то у меня ещё есть пара месяцев в запасе).

Да, совсем забыл. Оказывается, GIMP сохраняет текстовые слои в xcf ещё и в виде растра. Получается, что они тоже поддерживаются для просмотра без всяких freetype ещё с прошлой серии коммитов.


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Чт май 24, 2012 11:01 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
По многочисленным просьбам трудящихся, набросал API для кодирования изображений. Планируется к реализации для начала на каком-нибудь pnm или pcx.
Код:
;;================================================================================================;;
proc img.encode _img, _common, _specific ;////////////////////////////////////////////////////////;;
;;------------------------------------------------------------------------------------------------;;
;? encode image to some format                                                                    ;;
;;------------------------------------------------------------------------------------------------;;
;> [_img]      = pointer to input image                                                           ;;
;> [_common]   = some most important options                                                      ;;
;     0x00 :  byte : format id (defined in libimg.inc)                                            ;;
;     0x01 :  byte : fast encoding (0) / best compress ratio (255)                                ;;
;                    0 : store uncompressed data (if supported both by the format and libimg)     ;;
;                    1 - 255 : use compression, if supported                                      ;;
;                    this option may be ignored if any format specific options are defined        ;;
;                    i.e. the 0 here will be ignored if some compression algorithm is specified   ;;
;     0x02 :  byte : flags (bitfield)                                                             ;;
;                   0x01 : return an error if format specific conditions cannot be met            ;;
;                   0x02 : preserve current bit depth. means 8bpp/16bpp/24bpp and so on           ;;
;                   0x04 : allow changing bit depth without quality loss (i.e. 8bpp to 24bpp)     ;;
;                   0x08 : delete alpha channel, if any                                           ;;
;                   0x10 : flush alpha channel with 0xff, if any; add it if none                  ;;
;     0x03 :  byte : reserved, must be 0                                                          ;;
;> [_specific] = 0 / pointer to the structure of format specific options                          ;;
;                   see <format_name>.inc for description                                         ;;
;;------------------------------------------------------------------------------------------------;;
;< eax = 0 / pointer to encoded data                                                              ;;
;< ecx = error code / the size of encoded data                                                    ;;
;           0x01 : out ouf memory                                                                 ;;
;           --TBD--                                                                               ;;
;;================================================================================================;;

В тред призываются Mario и другие неравнодушные люди.

Предложения и замечания приветствуются. if any


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Чт май 24, 2012 11:05 pm 
Э? А я то тут причем? У меня вообще свой мопед и заголовок к нему давно лежит на SVN (root)/programs/media/zsea/Docs/ все плагины придерживаются этого заголовка.


Вернуться к началу
   
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Чт май 24, 2012 11:07 pm 
Не в сети
Just Flooding

Зарегистрирован: Сб янв 06, 2007 2:30 pm
Сообщения: 269
> format id
вроде ж, раньше были функции у каждого кодекаформата свои? В смысле, имя функции определяло то какой формат используется.


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Чт май 24, 2012 11:20 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
Mario, ты тут при том, что за время работы над своим, как ты выразился, велосипедом у тебя могли появиться полезные мысли по интересующему меня вопросу. Возможно, ты делал что-то похожее и встретил в моём предыдущем посте знакомые грабли.

Nable, сейчас libimg читает больше десяти форматов; так что, вызовы всех этих функций хардкодить в прикладной программе? Есть функция-обёртка img.decode, которая пробегает по таблице форматов, вызывает последовательно функции img.is для разных форматов и, если некоторая img.is.fmt возвращает не ноль, вызывает img.decode.fmt. Как-то так.


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Чт май 24, 2012 11:37 pm 
Не в сети
Just Flooding

Зарегистрирован: Сб янв 06, 2007 2:30 pm
Сообщения: 269
Точки в именах уже не располагают к использованию в других программах. Понабежало жавашников, ё-моё.


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Сб май 26, 2012 2:26 am 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
Сделал кодирование в pnm (raw) и пример в /programs/develop/libraries/libs-dev/.test/003.

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

Пример выглядит вот так:
Изображение
Сохранённое изображение затем можно открыть тем же kiv'ом:
Изображение


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Сб май 26, 2012 2:50 am 
Я думаю PNM не будет пользоваться широким спросом. К примеру в zSea давно мог уже сделать сохранение в RAW, но мне не нужно, а остальным и подавно.
Имеет смысл хотя бы 24 битовый BMP делать. Формат там не сложный, у меня самого для zSea это стояло и стоит в планах.


Вернуться к началу
   
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Сб май 26, 2012 6:44 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
Mario, когда я пришёл в проект, bmp уже поддерживался, и поэтому я с ним не знаком, в отличие от pnm. Да и pnm был, скорее, для демонстрации API.

С другой стороны, сохранил только что гимпом своё стандартное 3х5 тестовое изображение в bmp -- и что ты думаешь? Libimg его не открывает. InfoHeader не такого размера. Похоже, пришло время познакомиться с bmp поближе.


Вернуться к началу
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Сб май 26, 2012 6:48 pm 
Хмм... а zSea открывает?


Вернуться к началу
   
 Заголовок сообщения: Re: libimg
СообщениеДобавлено: Сб май 26, 2012 6:59 pm 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Пн окт 19, 2009 10:58 am
Сообщения: 329
Mario писал(а):
Хмм... а zSea открывает?
Да, открывает.

Я посмотрел код libimg/bmp.asm, там идёт проверка на размер InfoHeader'а: 12, 40 или 56 байт. Видимо, так различаются версии формата. А т.к. в майкрософте нормальную полную спецификацию написать не удосужились, всегда можно ожидать чего-то нового.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 65 сообщений ]  На страницу 1 2 3 4 5 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB