LINUX.ORG.RU

В GIMP появилась обработка с точностью 16 и 32 разряда на канал

 ,


0

3

Сегодня в ходе конференции Libre Graphics Meeting 2012, проходящей в Вене, было сделано объявление исторического значения: в нестабильной версии GIMP появилась обработка изображений с точностью 16 и 32 разряда на цветовой канал, integer или float по выбору пользователя. Новшество станет частью следующей стабильной версии с номером 2.10.

Это объявление ставит жирную точку в вопросе о том, станет ли программа когда-либо пригодной для применения в сложных проектах, где техническое качество изображения имеет решающее значение.

На текущий момент в режиме 32 разряда с плавающей точкой на канал работают инструменты трансформации, цветокоррекции и рисования. Доступны загрузка и сохранение 16-разрядных PNG, сохранение EXR и HDR.

Максимальный приоритет сейчас имеет завершение порта GIMP на GEGL и перенос в основную ветку разработки проектов GSoC2011 — инструментов Warp Transform (интерактивный iWarp) и Seamless Paste (бесшовная вставка изображений с адаптацией цветностных и яркостных характеристик). На GSoC2012 запланирован порт функций на GEGL и завершение работы по созданию универсального инструмента трансформации, а также создание редактора на нодах для тестирования GEGL.

Окончательный набор функций в версии 2.10 пока не обсуждался, примерные сроки выпуска этой версии будут определены по мере дальнейшей работы. Более короткий цикл подготовки релизов будет обеспечен за счёт переноса крупных разработок в ветки Git.

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

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от Eddy_Em

А если требуется употребить в тексте слово на третьем языке или спецсимволы? А если с текстом на другом языке приходится иметь дело, то тебе так нравится играть в игру «угадай кодировку»?

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

Это крайне специфичная задача. И ее можно решить либо вставляя чужеродный текст как картинку, либо сделать инструкции для раздельной компиляции (чужеродная вставка компиляется в eps-файл, который затем вставляется в наш текст; ну, в общем как-то так).

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

Это крайне специфичная задача

Во многих энциклопедических статьях нужно.

И ее можно решить либо вставляя чужеродный текст как картинку, либо сделать инструкции для раздельной компиляции (чужеродная вставка компиляется в eps-файл, который затем вставляется в наш текст; ну, в общем как-то так).

А если нужен именнь plain text?

Ttt ☆☆☆☆☆ ()
Ответ на: комментарий от NoNameNoNumber

Так правильно, только GUI... к этому идут уже как лет пять... Всю работу с изображением берет на себя GEGL + BABL - как механизмы неразрушаемого редактирования с любой нужной точностью и любым цветовым пространством... В 2.10 вообще основным заявлялось завершение формирования libgimp... И это правильно! Заметьте, как только GIMP начал активный переход на GEGL, так и сам GEGL стал активно развиваться... а до этого он особо и не был ни кому нужен. GIMP вытащит GEGL, который в свою очередь вытащит GIMP освободив его от ненужных сущностей работы с внутренней кухней изображения, сосредоточившись на GUI и предоставив необходимый функционал для скриптов, плагинов и т.д.

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

Ну фидошники вместо русской «Н» писали латинскую «H». Ещё раньше вообще всё транслитом писали. Но это же не выход.

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

Ну и пользуйте в этих исключительных случаях UTF. Но не совать же этот скотский юникод везде!

А потом мучайся, понимаешь, с обработкой строк! Нет уж, нафиг-нафиг. 1 сивол == 1 байт, и точка!

Добавлю-таки офтопика: представьте себе, что «вдруг» все графические файлы стали бы пользоваться переменной цветовой глубиной, т.е. один пиксель кодируется одним байтом, а другой - шестью. И как потом быть?

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

А потом мучайся, понимаешь, с обработкой строк! Нет уж, нафиг-нафиг. 1 сивол == 1 байт, и точка!

Мучений уж точно меньше, чем с зоопарком кодировок (при условии, что стандартная библиотека поддерживает кодировки с переменным размером символа). Ну а не нравится — есть UTF-32, там каждый символ — 4 байта.

Ttt ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

Добавлю-таки офтопика: представьте себе, что «вдруг» все графические файлы стали бы пользоваться переменной цветовой глубиной, т.е. один пиксель кодируется одним байтом, а другой - шестью. И как потом быть?

Юникод описывает, какому числу соответствует какой символ, а способов кодирования чисел - несколько, есть и с постоянным числом байтов.

а графические файлы как правило кодируются куда хитрее, чем просто переменной цветовой глубиной - и ничего.

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

каждый символ — 4 байта

Ага, и библиотека будет занимать не с полгига, а целый двухгигабайтный жесткий диск…

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от encyrtid

А мне нравится. И нет проблем с внедрением сишного кода в языки более высокого уровня. Да и сколько этих языков-то? Кроме С++ ничего ведь и нет более-менее попсового!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Anonymous

Я говорю не о сжатии с потерями, а именно о представлении уже распакованных файлов.

Eddy_Em ☆☆☆☆☆ ()

Воистину, настали последние дни. Покайтеся, ибо грядёт!

Oleaster ★★★ ()
Ответ на: Академический интерес: от ist76

ist76

А вот сколько секунд занимает расчёт фильтра Gaussian Blur на 40-мегапиксельном 16-bit integer RGB изображении, на каком-нибудь i7? Хотя бы порядок цифр?

А ничё, что все ну оооочень зависит от размера ядра фильтра (коэф. размытия)?

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

Если через БПФ делать, то от σ почти не зависит.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от NoNameNoNumber

Потому что если написать всё-всё-всё, то и обсуждать будет нечего. И какой это будет ЛОР? :)

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

Вот такой отстой

марвелло-фаг детектед

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

Парни, вы в курсе, что означает буква T в UTF ? Сама по себе постановка вопроса: «а как же с этим работать ?!» бессмысленна, потому что работать с этим не нужно.

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

Ну ладно, раз даже ты не в состоянии ответить на простой вопрос о том как пользоваться ГИМПом, пойду я спать, пожалуй.

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

Если руки отрезать птице. Если ноги отрезать тоже. Эта птица умрёт от скуки. Потому что сидеть не сможет.

Прозреваю, что хард твой долгожитель. Сам на утф перешёл с покупкой нового ноута.

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

Ну очень приятная, позитивная новость. И да, CMYK и 16-32 нужны. Мне, например, нужны :)

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

32 и 16-битные файлы GIMP итак спокойно открывал. Я так понимаю трудность заключается в том, чтобы инструменты приспособить под эту битность.

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

Так он уже давно профессиональный инструмент.

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

Ну ты говоришь только на русском. Некоторые не только на русском говорят. Плюс чтобы текст не оказался корякозябрами - имеет смысл использовать двухбайтовую кодировку.

Quasar ★★★★★ ()

Знаменитый баг был датирован 2003 годом. Так что аккурат 10 лет понадобилось.

PSкапец близок!

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

Это исторический момент)

Алилуйя. Жаль ирси не дожил

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

Плюс чтобы текст не оказался корякозябрами - имеет смысл использовать двухбайтовую кодировку.

Это при выводе наружу, для внутрипрограммных информационных потоков 8 бит лучше, не нужно кормить лишние сущности.

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

хард твой долгожитель

Бэкапы тоже с КОИ. И каждый раз с переходом на новый дистрибутив я все равно выбираю КОИ.

Eddy_Em ☆☆☆☆☆ ()

о, появились два новых режима замедления и без того тормозного гимпа? отличная новость :)

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

Смотря что за потоки.

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

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

а GTK3 к 2.10 ждать?

Пока непонятно.

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

Человек, чтобы текст не был кракозябрами надо как минимум иметь шрифт. Далее кто там сказал про двухбайтовую кодировку? А 4-ёх байтовой не надо? Длина плавающая в UNICODE. первые биты определяют в очередном байте опреедляют каким по счёту в коде символа данный байт является.

alx_me ★★☆ ()

Охренеть О_О Я еще анонимусом помню эти холивары. Тут зашел случайно и такая новость. Даже дату проверил, не первое ли апреля сейчас.

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

Какой ты нетерпеливый. Может мне просто хочется отоспаться, прежде чем писать длинные ответы? :)

Суть управления цветом в том, чтобы максимальное количество приложений понимало характеристики цветопередачи всех устройств ввода и вывода и пересчитывало значения пикселов между ними.

Это значит, в частности, что вывод наружу должен пересчитываться в цветовое пространство устройства вывода, потому что если рабочее пространство у тебя — что-то широченное типа ProPhoto RGB, а пространство монитора скукожилось до размеров sRGB... :)

Соответственно, когда в программе управление цветом отключено, она просто херачит RGB наружу как есть — в надежде, что цветовое пространство монитора совпадает с рабочим цветовым пространством программы.

А вот если программе удалось прочитать профиль из атома _ICC_PROFILE, она корректирует вывод по нему. Если не удалось — вот тут и пригождается выбор профиля напрямую, из раскрывашки.

В общем-то, всё очень просто.

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