Bugs fixed in GIMP 2.2.3
========================
- fixed build problem in MIDI input controller (bug #163593)
- remember last used directory in file open and save dialogs (bug #162385)
- fixed crashed in DND of indexed drawables (bug #163879)
- removed bumpmap artifacts in Lighting Effects plug-in (bug #163877)
- fixed non-interactive mode of Retinex plug-in
- fixed undo of ink strokes (bug #163670)
- fixed expose event handling in Curve Bend plug-in (bug #164207)
- added a missing pressure sensitivity toggle to Airbrush tool (bug #164237)
- fixed loading of XJT images files from read-only folders (bug #164116)
- fixed bug in the Info dialog that crashed the Crop tool (bug #163617)
- fixed yet another entry problem in the Scale Image dialog (bug #163951)
- fixed serialization of binary parasites (bug #163131)
- correctly initialize the preview in the Bumpmap plug-in (bug #162285)
- give visual feedback if a dialog is already opened (bug #164156)
- fixed saving of JPEG images with large quality settings (bug #164087)
- update the menus when selecting a component in the Channels dialog
  (bug #164195)
- fixed issues with the save dialog in the Imagemap plug-in (bug #164864)
- update filesize in JPEG dialog if size of EXIF data changes (bug #164914)

У них довольно сильно скачет размер bz2:

gimp-2.2.2.tar.bz2 14098 KB 09.01.2005 23:11:00

gimp-2.2.3.tar.bz2 13487 KB 22.01.2005 17:30:00

К чему бы это?

Сжимали с разными опциями?

Нет. Просто в корзинке дырка и через неё баги высыпаются :)

> Сжимали с разными опциями?

Смысл? У нормальных людей это скрипт делает, а не руки.

Скачал и глазам не поверил: GIMP уже на порядок превосходит фотошоп !!!

:)))

Многие прочитают это и тоже не поверят глазам. Но есть ли нам до них дело? :)

@chucha: может расскажешь по каким именно параметрам? Интересно ведь, дам потом другу дизйанеру это почтать, авось проникнется.

Я немного поковырялся на их сайте в разделе плагинов. Обнаружил такую штуку:

-------------------------------------

Noise Remover This plugin remove noise from photo by blurring B and A channels in LAB colorspace, and selective gaussian blurring

-------------------------------------

Меня почему-то Description заинтересовал.

А также:

rawphoto

This plug-in reads and adjusts (in 16bit mode) the images in RAW format from many digital cameras. Many cameras are supported (all supported by D. Coffin) dcraw command line raw converter. This is for GIMP 2.0. The source code is located at: http://ptj.rozeta.com.pl/Soft/RawPhoto/

http://registry.gimp.org/list?baseVersion=6

Ну а толку? Внутри себя плагин может хоть в LAB работать, хоть в 32 бита, хоть с чертом лысым общаться. Ничего сложного тут нет, даже X-ы понимают Lab (Xcms* и т.д.).

Проблема в том, что между каждым эффектом и последующим находится узкое место с потерей разрядности. И _любой_ эффект обязательно сталкивается или в клиппингом, если он аддитивный, или с потерей младшего значащего бита, если он мультипликативный, или и с тем, и другим сразу.

Нормальная недорогая камера выдает 10-12 значащих бит на канал в raw, что позволяет произвести любые разумные преобразования с округлением результата до 8 бит без потерь. А если резать разрядность после каждого этапа, в результате неискаженными останутся бит шесть в лучшем случае, а внизу -- шум, ошибки округления.

baka-kun правильно. Полностью согласен.

неправда ваша, этот плагин биты не теряет

Указанный plug-in RawPhoto для GIMP даёт вам диалог с картинкой и ~7 рычажками, которые можно подергать, пока картинка находится в 16bit на канал (это происходит между диалогом открытия файла и работой с ним в GIMP), после этого нажимаете Ок и картинка интерполируется. И вот только после этого с ней можно работать в GIMP, но нужно ли? ;-)

По крайней мере экспозицию/баланс белого подравнять можно, можно еще что то сделать, я пока не разобрался :-) У плагина, кстати, не очень хороший Auto Adjust.

Хотя сам факт, что импорт RAW таким не лучшим способом делается огорчает.

> И вот только после этого с ней можно работать в GIMP, но нужно ли? ;-)

Вот именно. А дальше ты уже ничего не вытянешь.

> По крайней мере экспозицию/баланс белого подравнять можно

А этого катастрофически мало. Пример: фотография этого лета. Ясный солнечный день, легкие кучевые облачка, на переднем плане много зелени, третий квадрант диагонально пересекает ручеек с кучей бликов.

Композиция и динамический диапазон такие, что если выводить зелень, небо превратится в сплошную однотонную плашку, облака потеряются, ручей станет набором белых пятен. Если вытягивать небо и воду, зелень уйдет в темные полутона. Был бы при съемке градиентный светофильтр, еще туда-сюда, но и композицию пришлось бы менять на полностью диагональную. В фотошопе я могу сделать нормальную маску, вытянуть небо и зелень как _мне_ надо. На любом этапе имея достаточный запас.

Поэтому не надо спорить, _негоден_ GIMP для полноценной работы с фото.

> А этого катастрофически мало. Пример: фотография этого лета. Ясный солнечный день, легкие кучевые облачка, на переднем плане много зелени, третий квадрант диагонально пересекает ручеек с кучей бликов.
>Поэтому не надо спорить, _негоден_ GIMP для полноценной работы с фото.
Ну зачем так категорично? Такие _явные_ просчёты (?) экспозиции корректируются либо при конвертации из raw, либо делаются 2 изображения, скажем, с разницей 2Ev, а потом с помощью масок cовмещается как угодно. Ошибки передискретизации, конечно, есть, но кто сказал, что они _непременно_ накапливаются? Это сказал какой-то дядя и все повторяют? Конечно, если первой операцией будет шарпинг, то получите, конечно, чудеса, так это и на 16 битах так.

И ещё вопрос: сколько цветов отображает ваш монитор? Сколько из них вы можете различить? Ведь если вы не можете различить цвета 1:1:1 и 2:2:2 (и как следствие, проведёте неправильную коррекцию), ваш динамический диапазон уменьшается вдвое, вне зависимости от глубины цвета и т.п.! А это уже похлеще, чем _возможное_ накопление ошибки в младшем бите. И очень хотелось бы узнать, РЕАЛЬНЫЙ (т.е. чтоб шума не было) динамический диапазон матриц. Мне, вот, интересны, конечно, цифры с http://www.dpreview.com/news/0011/00111608dynamicrange.asp, но недавно я читал статью на астронете, так там у охлаждаемых матриц был заявлен диапазон около 50dB, что меньше, чем многие значения в приведённой таблице. А астронету я верю больше, извините. А если вы ещё не можете различить на своём мониторе 1:1:1 и 2:2:2 (это весьма возможно, но не буду категоричен), то в 8 бит влезут абсолютно все и с запасом.

А теперь хотелось бы послушать ещё парочку категоричных заявлений. Очень хотелось бы посмотреть на местных экспертов, которые с хотя бы 70-процентной вероятностью правильно определить: вот эта фотография сделана в супер-пупер-фотошопе (я не наезжаю, просто для контраста), а это в недо-гимпе. А я лично почти уверен, что не сможете! И на печати не сможете, если на экране не различите. Вот так-то.

Я не против 16 бит на канал как таковых, но по-моему, вы слегка приувеличиваете их ценность.

> Ну зачем так категорично?

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

> Такие _явные_ просчёты (?) экспозиции корректируются либо при конвертации из raw

Так было задумано -- очень красивые облака и ручей, но и вместо зелени не хотелось получать темную кучу, и так на ней сэкономил. Если бы это была пленка, пришлось бы компоновать по диагонали, использовать светофильтр с подходящим клином от прозрачного до нейтрального серого, долго и упорно искать точку... потом пропустить свет и возвращаться на следующий день. ;)

> либо делаются 2 изображения

Угу. Сначала из raw делаем нормальные светлые полутона, сохраняем 8-бит, затем делаем нормальные темные, сохраняем. Потом сводим в два слоя, и начинаем создавать три маски, а только это нам даст от двух до шести произведений на канал. Не считая последующих эффектов и финального восстановления гаммы. В фотошопе мне достаточно одной маски, и нет необходимости постоянно повторять два первых самых трудоемких этапа, если надо что-то подправить. И вся математика в 16 бит.

> Ошибки передискретизации, конечно, есть, но кто сказал, что они _непременно_ накапливаются? Это сказал какой-то дядя и все повторяют? Конечно, если первой операцией будет шарпинг, то получите, конечно, чудеса, так это и на 16 битах так.

Ну, были такие дядьки: Котельников и Шеннон. Они очень много про это говорили в свое время. А первой операцией, с вероятностью 99.(9)%, будет гаммакоррекция. Мультипликативная операция.

Накопление ошибки можешь проверить сам: взять произвольное 8 бит значение, умножить, скажем, на 1.3, округлить до 8-бит, затем разделить на 1.7, округлить, разделить на 1.3, округлить, умножить на 1.7, округлить, повторить операцию десяток раз. Потом дополнить свое первоначальное число снизу нулями до 16 бит (умножить на 256) и повторить опыт. Результат доложить. Потом доказать, что в 8-бит работать не хуже, поскольку ошибки не накапливаются.

> Ведь если вы не можете различить цвета 1:1:1 и 2:2:2

В том-то и дело, что могу. И мониторы у меня все откалиброваны.

> И очень хотелось бы узнать, РЕАЛЬНЫЙ (т.е. чтоб шума не было) динамический диапазон матриц... недавно я читал статью на астронете...

Сам не измерял, врать не буду. Некоторые источники указывают цифры в 60db и выше, 1 бит -- примерно 6db. Астронет -- это очень хорошо, но там не уточняли, для какой длины волны они считали диапазон?

Но дело даже не в этом. После первой же операции нам потребуется бОльшая разрядность, чем была на входе. Все, этого достаточно. Да и опыт с накоплением ошибки, думаю, уже убедил.

> Я не против 16 бит на канал как таковых, но по-моему, вы слегка приувеличиваете их ценность.

Боюсь показаться грубым, но LOL. :-)

Вот тебе программка для проверки, самому ведь лениво будет ;)

====
#define CONST XXXX /* define value here */

int a = CONST;
int b = CONST << 8;
char s1[32], s2[32];

i2b (char *s, int c, int i) {
    s[i] = 0;
    while (i) {
        s[--i] = '0' + (c & 1);
        c >>= 1;
    }
}

main () {
    int i;

    for (i = 0; i < 10; i++) {
        a *= 1.3; a /= 1.7; a /= 1.3; a *= 1.7;
        b *= 1.3; b /= 1.7; b /= 1.3; b *= 1.7;
        i2b(s1, a, 8);
        i2b(s2, b, 16);
        printf("%x(%s) %x(%s)\n", a, s1, b, s2);
    }
}
====

Гамма-коррекция должна производиться на переводе из raw, если уж на то пошло (я не знаю, позволяет ли тот плагин делать это, но проверю, когда доберусь домой).

Совмещение изображений приходится делать чаще, чем многие думают. Зачем другие дядьки тогда придумали брекетинг на всех профессиональных камерах, которые, несомненно, обладают RAW? Почему намного лучшее качество достигается при сливании 2-х кадров (даже JPEG), а не из одного raw (это не относитя к камерам, которые делают экспокомпенсацию путём сдвига данных с матрицы в ту или иную сторону)?! Другое дело, не всякий кадр позволит его фотографировать дважды.

Я повтрорю: хоть 120 бит давайте наружу, если это будет 7-8 бит _от силы_ + шум, это ничего не даст. Ну не добавляет это информации.

С некоторыми ;) теоремами Шеннона знаком. Про астронет уточню.

Ещё раз повторю: я не говорю, что 16 бит на канал - это плохо или _абсолютно_никому_не_нужно_. Это замечательно! Но в подавляющем большинстве случаев это не нужно (будет - скажу разработчикам спасибо). Гораздо большее влияние на восприятие оказывает правильная тональность, контраст, резкость (или наоборот, размытость).

По поводу программы. Так-то это так (подозреваю, значения будут всё время отклоняться в одну сторону), НО! во-первых, если переставить каждый второй раз или по рандому операции умножения и деления, то эффект будет намного меньше; во-вторых, много ли операций вроде умножения значения пиксела на 1.7(!) вы производите за сеанс редактирования? Ещё допущу, что на этапе правки curves (Г.К.), но об этом смотрите выше.

В крайнем случае, сделайте supersampling - увеличьте изображение раза в 2 по горизонтали и вертикали - последней операцией назад вернёте.

*** Всё сказанное выше являеся моим личным мнением и не претендует на объективность. Я не очень давно, скорее даже недавно, пересел с Photoshop'а на The Gimp и ничуть об этом не жалею. Более того, никакой заметной разницы в качестве финальных изображений я не вижу, что бы там рассчёты не говорили. :)))

Bottom-line:
============
Берётесь определить на глаз, где обработано 8 бит, а где 16? ;)

Засим остаюсь.
Приятно, когда с тобой спорят аргументированно.
С уважениеи,
fAX.

> я не знаю, позволяет ли тот плагин делать это
позволяет :)

> Гамма-коррекция должна производиться на переводе из raw, если уж на то пошло

Понимаешь, некоторые вещи (почти все) лучше делать на линейной картинке, а некоторые при целевой гамме (обычно 2.2). Вот и приходится несколько раз крутить.

> Другое дело, не всякий кадр позволит его фотографировать дважды.

Именно. В первую очередь именно те, на которые человек всегда готов смотреть. Заешь "люди бесконечно могут смотреть на воду, огонь..."? ;)

> хоть 120 бит давайте наружу, если это будет 7-8 бит _от силы_ + шум, это ничего не даст. Ну не добавляет это информации.

А я повторю: задача не _добавить_ информацию, а _не_потерять_ существующую. Представляешь, что происходит при рулении гаммы в 8-бит? Это ведь степенная функция, и считаться будет как 255*(255/x)^gamma. Уже оценил потери на краях диапазона? То-то.

> во-вторых, много ли операций вроде умножения значения пиксела на 1.7(!) вы производите за сеанс редактирования?

Бывает, я провожу возведение в степень 2.2 или 1/2.2. Согласись, это много _хуже_ умножения на 1.7? Да и 1.7 -- вполне реально, просто поднять контраст.

> В крайнем случае, сделайте supersampling ... - последней операцией назад вернёте.

Тогда уж перед даунсемплингом произвести еще и дизеринг в младшем бите.

> я не говорю, что 16 бит на канал - это плохо ... Но в подавляющем большинстве случаев это не нужно

Гхм. Тогда давай проведем аналогию со звуком. Нафиг писать 24х96, если у микрофона дай бог 80 db, а человек выше 18-20 не слышит? Нафиг обрабатывать все в 24, 32 или fp, если выход пойдет в mp3, а в лучшем случае в 16x44.1? О каком накоплении ошибок идет речь, если в младших 3-4 битах -- шум?

Я думаю, люди, работающие со звуком, будут очень рады, когда ты скажешь: "я не говорю, что 24 бита (32, 64/80 float-point) на канал - это плохо или _абсолютно_никому_не_нужно_. Это замечательно! Но в _подавляющем_ _большинстве_ случаев это не нужно. Гораздо большее влияние на восприятие оказывает правильная распальцовка, бескислородная медь, лампы, винил и торсионные поля".

PS. Сейчас перечитал, грубовато получается. Специфика флеймов. ;)

С уважением,

>Я думаю, люди, работающие со звуком, будут очень рады, когда ты скажешь: "я не говорю, что 24 бита (32, 64/80 float-point) на канал - это плохо или _абсолютно_никому_не_нужно_. Это замечательно! Но в _подавляющем_ _большинстве_ случаев это не нужно.

Люди-то, может, и не обрадуются, только так оно и есть.

>Гораздо большее влияние на восприятие оказывает правильная распальцовка, бескислородная медь, лампы, винил и торсионные поля

количество бит на цвет (>24) или на звук (>19) - на 99% та самая правильная распальцовка для лошков. На любом сканере сейчас есть 48 бит на цвет. Ты этому страшно рад?

ГИМП

Есть еще 1 плагин для импорта RAW в ГИМП: http://ufraw.sourceforge.net/

Его changelog говорит о его возможностях :)

23/01/2005 - UFRaw-0.3 released, based on DCRaw v6.23.

* Added basic color management support using Little CMS. * Created a standalone version with a GUI interface and batch processing support. Images can be saved in the PPM, TIFF and JPEG formats. * Settings are saved between sessions in a configuration file. * Added white balance temperature presets (direct sunlight, cloudy, shade, flash, etc.). * Serveral possible live histograms. * Initial (a bit slow) support for thumbnails in the Gimp open file dialog. * Many smaller changes.

28/10/2004 - UFRaw-0.2 released, based on DCRaw v6.10.

* Added support for Nikon Tone Curves. * This version can be used on the smaller 1024x768 screens. * I'm finally satisfied with the Saturation control. * Many small changes.

> Гхм. Тогда давай проведем аналогию со звуком. Нафиг писать 24х96, если у микрофона дай бог 80 db, а человек выше 18-20 не слышит?

Вообще-то эти 96khz и те 18-20, которые воспроизводятся - вещи разные. Их нельзя сравнивать.

Лёш, за достаточность 19-битного кодирования звука тебя порвут как Тузик грелку :)

Я предупреждал, что людЯм не понравится.

Только объективно это мало что меняет. ацп и цапы с реально бОльшим, чем 19 разрядов качеством - фантастика. Хороший ацп будет в младшие биты писать белый шум, а плохой - модулированный.

А то, что грамотная распальцовка влияет на качество - медицинский факт. :)

> Люди-то, может, и не обрадуются, только так оно и есть.

Ты не в теме. Речь идет о количестве бит на этапе _обработки_. На входе 8 на канал для цвета, пусть 16 для звука, на выходе то же самое. А вот на протяжении всех преобразований _необходимо_ иметь полутора-двухкратный запас. И чем больше, тем лучше.

Любой нормальный аудио-софт внутри работает в 32 бита или в fp.

> Вообще-то эти 96khz и те 18-20, которые воспроизводятся - вещи разные. Их нельзя сравнивать.

Я что, зря там Котельникова поминал? ;)

> Только объективно это мало что меняет. ацп и цапы с реально бОльшим, чем 19 разрядов качеством - фантастика.

Равно как и оптические сенсоры. И что? Знаешь что с тобой сделают за цифромой микшер или процессор с 16-бит на канал внутренним представлением звука?

Повышение разрядности на этапе обработки - маскировка хреновых алгоритмов, не имеющих понятия о дискретной математике. Дешевая китайская маскировка.

Заметь, ты не знаешь, что там внутри в фотошопе. Ты просто _веришь_ в счастливую цифру 16 бит на канал. Был бы гимп закрытым, на нем было бы налеплен тот же стикер - 16 бит на канал...

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

Да нет. Я сам знаю, что в своей профессиональной области невозможно так вот добровольно признать _практически_ бесполезным говном любой мало-мальский бантик. Но от этого объективная картина не меняется. 99% народа снимает мыльницами, печатает на струйные принтеры, слушает плейры и смотрит VHS или пиратские тряпки на двд. И это не мешает этим 99% закатывать глазки на качественный hi8 (говно, это же хуже бетакама или даже... dv), cd (44 кгц- да вы с ума сошли!!!), или на тот же гимп.

ГИМП

А мы тут дискуссиями балуемся :)

Да, нет у ГИМПа 16и бит или float на канал. Это плохо? Да, плохо. Это смертельно - нет, не смертельно :). Если не делать повышение яркости недоэкспонированного изображения или его частей, то постеризации не будет. А ошибки округления не настолько и заметны, тем более, что по сравнению с float максимально возможная ошибка - 0.5 дискреты на операцию. Причем случайным образом - последовательные операции могут и скомпенсировать ошибки друг друга :).

Можно до судорог :) спорить, но можно и проверить. Владельцы фотошопа CS, ауу. Возьмите одну фотографию (jpg) и сделайте над ней последовательные операции. А потом точно те же в ГИМПе. И давайте сравним результат.

> Да, нет у ГИМПа 16и бит или float на канал. Это плохо?

http://www.normankoren.com/makingfineprints.html#Why48

http://www.creativepro.com/story/feature/7627.html

http://www.inkjetart.com/2450/48bit/

> Заметь, ты не знаешь, что там внутри в фотошопе. Ты просто _веришь_ в счастливую цифру 16 бит на канал. Был бы гимп закрытым, на нем было бы налеплен тот же стикер - 16 бит на канал...

Ну в этом, кстати, очень убедиться легко. Исходников для этого не нужно.

Другое дело, что и в фотошопе есть некоторые косяки в реализации алгоритмов. Скажем тот же Levels гораздо более грубый, чем в ImageMagick.

В файле лежат 16 бит?

Симметричные эффекты дают один результат?

Это все побочные эффекты, которых можно достичь разными способами.

первый раз за несколько лет я вижу спокойное обсуждение графического софта на лоре с нормальными аргументами и без флейма. Irsi, где ты??? тут скучно )))

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

> В файле лежат 16 бит?

Да, исходник 16 bit. Простые операции, вроде Levels или преобразований цветовых пространств и гаммы делаются в ImageMagick. Но если хочется, скажем, наложить градиент или какую-нибудь хитрую маску - Gimp уже не подходит.

ГИМП

Предлагаю для беспристрастной оценки все-таки наложить эту маску :) в ГИМПе и Фотошлепе. просто для того, чтобы мы все могли оценить, какова на самом деле разница.

> Повышение разрядности на этапе обработки - маскировка хреновых алгоритмов, не имеющих понятия о дискретной математике. Дешевая китайская маскировка.

Как все запущено... Могу только порекомендовать повторить курс цифровой обработки сигналов. ;)

> Заметь, ты не знаешь, что там внутри в фотошопе. Ты просто _веришь_ в счастливую цифру 16 бит на канал.

Это _очень_ легко проверяется. Банально крутишь Level и смотришь на дыры в гистограмме.

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

"Нормальную математику", ну-ну. Два простых примера из жизни любого, кто работает с фото:

1. На входе линейная картинка 8 бит на канал, нам необходимо поправить гамму для 2.2 - 2.5 (для веба рисуем, например, значит будут на мониторе смотреть), а потом применить еще несколько эффектов (градиентики, масочки, фигню всякую). Так вот, после гаммакоррекции нам _уже_ надо 10-12 бит, чтобы только _не_потерять_ существующее. На выходе, конечно, придется урезать, но зато все промежуточные этапы вносят минимум искажений.

2. На входе 8 бит, с гаммой 2.5, надо почистить, пошарпить, скадрировать и т.п., и отправить на печать. Значит на выходе нам надо гамму 1, естественно. Лучший вариант -- сначала откатить гамму, а все шарпы/блюры/деспеклы/HSV крутить уже на линейной картинке. Если внутри делать все тоже в 8 бит, дай бог 5-6 останется.

И заметь, здесь пока ничего прошумы -- сплошь об ошибках округления.

Вот тут всё спорят про то насколько это плохо что в гимпе нету 16 бит... А ведь уже давно есть форк гимпа cinepaint (бывший filmGIMP) в котором до 32 бит на канал... Кто-нибудь его серьёзно использовал? Как впечатления?

В обработке цифровых сигналов я разбираюсь примерно так, как ирси в картографии, то есть очень хорошо. :)

Крутить уровни можно и в 24 битах. И потом свести их к тем же 8 на канал. Как уже говорилось, плагины в гимпе могут работать в какой угодно модели и с какой угодно разрядностью.

Нормалная математика, это малошумящие фильтры раз, недеструктивное редактирование два, переменная разрядность - три и нормальное удаление нелинейных искажений - четыре.

Попытка подменить эти факторы единственной циферкой "16 на канал" является не более чем маркетинговой уловкой. Китайским плейером...

> Как уже говорилось, плагины в гимпе могут работать в какой угодно модели и с какой угодно разрядностью.

Абсолютно верно.

И ещё. По поводу заявлений насчёт "16 бит в Фотошопе уже Х версий/лет": до версии 8 aka CS 16 бит были несколько, хмм, убогими. Очень хотелось бы посмотреть, как делается градиентный фильтр на 16-битное изображение, если ФШ (<= 7) в 16-битном режиме не даст градиент нарисовать ;).

А mainstream до сих пор 7-й фотошоп, а может даже и 6-й. Поправьте, если я не прав.

И ещё (это из ссылок maxcom'а): http://www.creativepro.com/story/feature/16097.html

> А ведь уже давно есть форк гимпа cinepaint (бывший filmGIMP) в котором до 32 бит на канал... Кто-нибудь его серьёзно использовал? Как впечатления?

О впечатлениях надо спрашивать кино-студии. ;) Хотя они используют свои внутренние сборки, а не то, что лежит на sf.net.

Я последний раз смотрел на 0.18-1, мрачно все -- падает на ровном месте. Жду Glasgow, он будет на FLTK вместо gtk1.

> Крутить уровни можно и в 24 битах. И потом свести их к тем же 8 на канал. Как уже говорилось, плагины в гимпе могут работать в какой угодно модели и с какой угодно разрядностью.

Могут. _Внутри_ себя. а между плагинами только 8бит RGB. А как уже говорилось, после гаммакоррекции 7-8 бит превращаются в 10-12.

> Нормалная математика, это малошумящие фильтры раз, недеструктивное редактирование два, переменная разрядность - три и нормальное удаление нелинейных искажений - четыре.

То есть ты, как теоретик, предлагаешь формат с переменной точностью? Может еще и нелинейные с разными весами битов? Замечательно, я соглашусь, что для представления одной точки может быть достаточно 4 бит, а соседней -- 14, и что редко когда может понадобиться больше 16. Теперь передай это пожелание практикам-программистам, и получи заранее известный ответ: быстрее, проще и эффективней выбрать одну максимальную разрядность, кратную байту и имеющую нативную поддержку в железе.

> Попытка подменить эти факторы единственной циферкой "16 на канал" является не более чем маркетинговой уловкой.

Утверждение было бы истиной, если бы эти "16 бит" ничего не давали. Вот 8Mpix про матрице 1/2.7 -- это маркетинговая уловка. А raw и больше 8 бит на этапе обработки -- необходимость.

Если говорить о том, какой бы графический редактор хотелось бы.

Сейчас все работает как: каждый этап/операция/фильтр получает на вход данные, меняет их по определенному закону и отдает дальше. В идеале каждый этап должен давать на выход _уравнение_, а уже на самом конце цепочки (визуализация/вывод в файл) -- решение/оптимизация системы уравнений с учетом побочных эффектов и однократное применение к первоначальным входным данным.

> до версии 8 aka CS 16 бит были несколько, хмм, убогими.

Да, приходилось искать обходные пути, с некоторыми ты ознакомился: "И ещё (это из ссылок maxcom'а)". Но в GIMP даже этого нет.

> А mainstream до сих пор 7-й фотошоп, а может даже и 6-й. Поправьте, если я не прав.

Все знакомые, работающие с Фото, сразу перешли на CS. В России, думаю, даже у прыщавых пионеров поголовно стоит именно CS, по вполне понятным причинам.