GIMP и проблема 8-битного цвета
В компьютерном мире есть одна несправедливость, которая не даёт мне покоя. Часто и много говорится о «разрядности» приложений, однако, не о той, которая имеет значение для простого пользователя. Та же, которая имеет значение, вспоминается редко и туманно, потому что мало у кого хватает терпения зарыться так глубоко в технические вопросы. В меру сил и способностей сегодня я попытаюсь это сделать.
Что обычно мы понимаем под «разрядностью»? Да конечно количество бит, которым оперирует центральный процессор! Почти двадцать лет миром правили 32-битные ЦПУ, способные обрабатывать за раз, одной командой, числа размером в 4 байта, то есть те самые 32 бита. Переход к 64 разрядам начался примерно десять лет назад — и хоть до сих пор не завершён, не так уж страшен. Честно говоря, рядовой пользователь на обычных задачах скорее всего даже не отличит программу, скомпилированную в 32-битных инструкциях от неё же, но уже для 64-битного процессоры. Скорость будет примерно та же, памяти она съест примерно столько же.
Но есть ещё разрядность графических файлов — и вот о ней знает куда меньше пользователей. Чтобы лучше понять, о чём идёт речь, запустите прямо сейчас GIMP и загрузите в него любое изображение в формате JPG. Теперь увеличьте, пока не станут видны отдельные пиксели. Каждая точка здесь — результат сложения трёх цветов: красного, зелёного и синего. Их ещё называют цветовыми каналами. И на каждый канал в стандарте JPG отдаётся ровно 8 бит. То есть каждая точка может иметь 256 (2 в степени 8) оттенков красного, 256 зелёного и 256 синего. Этого хватает, чтобы изобразить 16 миллионов оттенков. Огромное количество! Столько покажет не каждый дисплей, и уж человеческий глаз, конечно, не отличит один миллион две тысячи первый оттенок от один миллион две тысячи второго.
Так что ничего удивительного, что и программы, обрабатывающие графику, тоже традиционно строились с поддержкой только 8 бит на канал. GIMP, который мы только что запустили, как раз из их числа: он умеет работать только с изображениями, где каждый цвет изображается 8 битами. Ещё этот параметр называют «цветовым разрешением» или «точностью цвета» (color precision). В данном случае оно 8-битное и, как мы только что убедились, этого вроде бы более чем достаточно.
Однако давайте попробуем «поиграть» с цветами на нашем изображении: скажем, рисовать цветной кистью в режиме «перекрытие» (overlay) и т.п. Как графический редактор делает это? С помощью простой математики. Когда вы проводите кистью по экрану, GIMP вычисляет новые значения цвета для каждого пикселя. Пусть, к примеру, у исходного пикселя был чистый красный цвет: красная компонента была равна 255, зелёная и синяя нулевыми. И пусть мы провели по нему кистью с чуть менее ярким красным (скажем, с параметром 254). GIMP складывает значения каналов и вычисляет среднее. В нашем случае это будет 254,5.
Но вот какая засада: если мы работаем с 8-битной точностью цвета, то цвет может принимать только 256 целых значений. То есть 0, 1, 2, …, 255. Восемью битами невозможно записать дробное число 254,5! А это значит, что GIMP будет вынужден округлить результат до ближайшего целого — до 255 или 254. И чем больше операций вы совершите, чем сложней они будут, тем чаще графическому редактору придётся округлять значения цветов. В конце концов это приведёт вот к какому результату (см. фото ниже). Видите границы между оттенками? Они получились потому, что GIMP был вынужден многократно округлять до ближайшего целого.
Давайте осмыслим результат. Несмотря на то, что 8-битной точности цвета (8 бит на каждый цветовой канал) хватает для отображения фотографий с качеством, превосходящим возможности человеческого глаза, той же самой точности для обработки фотографий уже не хватает. Если бы, вычисляя цвета, GIMP пользовался 16 битами (т.е. 65536 значений вместо 256), а лучше больше (24 бит или 32), градиентных полос на картинке выше не получилось бы. Ошибки округления перестали бы накапливаться.
Большая цветовая точность совершенно необходима для качественной обработки фотографий с цифровых фотокамер. Современные фотоаппараты позволяют сохранять снимки в формате RAW, где на каждый цветовой канал отдаётся больше 8 бит. И если вы профессионал или даже если просто желаете не терять качества при обработке снимка, вы не можете позволить огрублять эту информацию до 8 бит!
Что ж, тот же Adobe Photoshop, например, умеет обрабатывать изображения с цветовым разрешением более 8 бит. Но вот для Линукса аналогичной программы долгое время не существовало. Да, у нас много свободного софта, который умеет работать более чем с 8-битной точностью цвета: Krita (см. также «Искусство на рельсах open source»), CinePaint, VIPS/Nip2, ImageMagick и другие. Однако у всех у них своя специализация: одни предназначены только для преобразования изображений, другие «заточены» под рисование кистью, третьи ещё что-нибудь. И только GIMP был и остаётся достаточно мощным и универсальным, чтобы составить конкуренцию Photoshop. Но GIMP, увы, не умел обрабатывать картинки с больше чем 8-битной точностью цвета! Чем, кстати, пользовались противники open source: мол, а покажите-ка мне свободное приложение для качественной обработки снимков!..
В 2012-м году эту недоработку, наконец, исправили. GIMP научили работать с большим числом бит на цветовой канал. Но, к сожалению, научили лишь его тестовую версию, 2.9, которая со временем должна была превратиться в стабильную версию 2.10. Новость была встречена восторженно, однако с тех пор минуло уже четыре года, а 2.10 так и не выпущена. Почему? Дело в том, что GIMP переживает большую внутреннюю перестройку: фактически, его чуть ли не переписывают «с нуля», адаптируя под современный графический интерфейс и новые устройства. А разработчиков не хватает (его по-прежнему делают энтузиасты). Поэтому придётся ещё подождать.
Впрочем, если большая цветовая точность необходима, можно попробовать скомпилировать 2.9 из исходников. Стабильной работы не ждите (всё-таки это тестовая версия), но возможность качественно обрабатывать фотографии с помощью исключительно свободного софта у вас появится.
--------------------------------------------
Этот текст всегда доступен по адресу linux.su/280516.shtml