Коррекция sRGB для текстур в OpenGL на iOS

Я столкнулся с проблемой, описанной в этой статье, где вторая цветовая рампа эффективно гамма-коррекция дважды, что приводит к избыточным и размытым цветам. Это отчасти связано с тем, что я использовал фреймбуфер sRGB, но это не является реальной причиной проблемы.

Я тестирую текстуры в своем тестовом приложении на iOS8, и, в частности, я в настоящее время использую файл изображения PNG и используя GLKTextureLoader для загрузки его в виде куба.

По умолчанию текстуры обрабатываются НЕ как находящиеся в пространстве sRGB (которые они неизменно сохраняются с помощью программного обеспечения для редактирования изображений, используемого для построения текстуры).

Следствием этого является то, что Apple сделала GLKTextureLoader glTexImage2D вызова glTexImage2D для вас, и они неизменно называют его с настройкой GL_RGB8, тогда как для реальной корректности будущих операций с цветом мы должны исправить гамма, чтобы получить значения линейной яркости в наши текстуры для наших шейдеров.

Теперь я могу увидеть аргумент, что большинство мобильных приложений не требуется педантично о цветовых операциях и цветовой правильности применительно к продвинутым 3D-технологиям, включающим смешивание цветов. Часть проблемы заключается в том, что нереалистично использовать драгоценное ОЗУ для общего устройства для хранения текстур на любой битовой глубине более 8 бит на канал, и если мы будем читать наши JPG/PNG/TGA/TIFF и гамма-исправлять его 8 бит sRGB в 8 бит линейных, мы будем ухудшать качество.

Таким образом, процесс для большинства приложений просто счастливо подбрасывает линейную цветокорреляцию из окна, и в любом случае просто игнорирует гамма-коррекцию и делает смешение в пространстве SRGB. Это очень подходит для Angry Birds, так как это игра, в которой нет затенения или смешивания, поэтому совершенно разумно выполнять все операции в цветовом пространстве с коррекцией гамма-излучения.

Таким образом, это подводит меня к проблеме, которая у меня есть сейчас. Мне нужно использовать EXT_sRGB а GLKit упрощает настройку фреймбуффа sRGB, и это отлично работает на EXT_sRGB третьего поколения или с таким же поколением, на которых работает iOS 7 или новее. При этом я обращаю внимание на темный и неестественный вид тени нескорректированного трубопровода рендеринга. Это позволяет мне хорошо выглядеть ламбертским и blinn-phong. Это позволяет мне хранить sRGB в буферах рендеринга, чтобы я мог выполнять постобработки, используя улучшенное перцептивное цветовое разрешение, обеспечиваемое сохранением буферов в этом цветовом пространстве.

Но проблема теперь, когда я начинаю работать с текстурами, состоит в том, что кажется, что я даже не могу использовать GLKTextureLoader, как и предполагалось, поскольку я просто получаю загадочную ошибку (код 18), когда устанавливаю флаг опций для SRGB (GLKTextureLoaderSRGB). И это невозможно отлаживать, поскольку нет исходного кода для этого.

Поэтому я думал, что смогу построить свой конвейер для загрузки текстур с помощью glTexImage2D и использовать GL_SRGB8 чтобы указать, что я хочу гамма-исправлять свои текстуры, прежде чем я их GL_SRGB8 в шейдере. Однако быстрый взгляд на документы GL ES 2.0 показывает, что GL ES 2.0 даже не поддерживает sRGB.

Наконец, я нахожу спецификацию EXT_sRGB, в которой говорится:

Add Section 3.7.14, sRGB Texture Color Conversion

If the currently bound texture internal format is one of SRGB_EXT or 
SRGB_ALPHA_EXT the red, green, and blue components are converted from an
sRGB color space to a  linear color space as part of filtering described in
sections 3.7.7 and 3.7.8. Any alpha component is left unchanged.  Ideally,
implementations should perform this color conversion on each sample prior
to filtering but implementations are allowed to perform this conversion
after filtering (though this post-filtering approach is inferior to 
converting from sRGB prior to filtering).

The conversion from an sRGB encoded component, cs, to a linear component,
cl, is as follows.

        {  cs / 12.92,                 cs <= 0.04045
   cl = {
        {  ((cs + 0.055)/1.055)^2.4,   cs >  0.04045

Assume cs is the sRGB component in the range [0,1]."

Поскольку я никогда не выкапывал эту глубину при внедрении игрового движка для настольного оборудования (что я бы ожидал, что соображения о цветовом разрешении будут существенно спорными при использовании буферов визуализации с глубиной 16 бит на канал или выше), мое понимание того, как это работает, неясно, но этот параграф делает какой-то способ успокоить меня тем, что я могу получить свой торт и съесть его тоже в отношении сохранения всех 8 бит информации о цвете, если я загружаю текстуры, используя SRGB_EXT хранения изображений SRGB_EXT.

Здесь, в OpenGL ES 2.0 с этим расширением, я могу использовать SRGB_EXT или SRGB_ALPHA_EXT а не аналогичную SRGB или SRGB8_ALPHA из ванильного GL.

Приношу свои извинения за то, что вы не представили простой ответный вопрос. Пусть это будет одно: Я лаяю неправильное дерево здесь или мои предположения более или менее правильные? Похоже, я слишком долго смотрел на эти спецификации. Другой способ ответить на мой вопрос: если вы можете пролить свет на ошибку 18 GLKTextureLoader, которую я получаю, когда пытаюсь установить параметр sRGB.

Похоже, мне еще предстоит сделать больше чтения, поскольку я должен решить, нужно ли начинать разворачивать мой код, чтобы получить один код, который использует GL ES 2.0 с EXT_sRGB, а другой - с помощью GL ES 3.0, который, безусловно, выглядит очень перспективным сравнивая документацию для glTexImage2D с другими версиями GL и ближе к OpenGL 4, чем другие, поэтому мне очень нравится, что ES 3 будет приближать мобильные устройства к API, используемым на рабочем столе.