Я занимаюсь программированием, которое включает кодирование данных изображения с использованием WIC. Я использовал данные RGB, но WIC всегда рассматривает их как BGR. У меня есть связанный вопрос по переполнению стека, касающийся стороны программирования. Однако я хочу исключить, что проблема может быть связана с WIC или форматом файла JPEG.
Это нормальное поведение для JPEG или как WIC обрабатывает данные изображения?
Это основная переписка моего ответа, основанная на дополнительной информации, предоставленной ФП в комментариях, связанной ветке о SO и его собственном ответе.
Поддерживает ли формат файла JPEG данные RGB?
RGB имеет два значения.
Это цветовое пространство, где цвета определяются с точки зрения основных цветов красного, зеленого. и синий. Стандарт JPEG основан на цветовом пространстве RGB в качестве отправной точки. Он конвертируется в YCbCr для сжатия. Довольно подробное описание процесса кодирования и сжатия приведено в этой статье Википедии.
RGB означает порядок интерпретации сохраненных цветовых данных. Ответ Боба объясняет, почему его также можно интерпретировать в порядке BGR. Именно это и привело к путанице, которая привела к этому вопросу. На самом деле это относится не к стандарту JPEG, а к тому, как WIC обрабатывает данные.
Спецификация файла формата изображения включает в себя определение цветовой последовательности. Это не ситуация в этом случае. WIC создает JPEG из необработанных данных изображения. Согласно найденной вами ссылке, WIC поддерживает как RGB, так и порядок BGR для входных данных, хотя в качестве входных данных для своего родного кодека JPEG используется только BGR. Таким образом, проблема заключается в взаимодействии с WIC и предоставлении ему того, что он ожидает увидеть.
Несмотря на то, что фактическим форматом данных, считываемым WIC, можно управлять, обратите внимание, что формат независимого от устройства растрового изображения , обычно используемый для несжатых данных изображения (и содержащийся также в большинстве файлов BMP), сохраняет каждый пиксель в форматах 24BPP и 32BPP как один 24-разрядный или 32-битное слово с прямым порядком байтов .
Это изображение описывает little-endian довольно хорошо:
Изображение является общественным достоянием, по RS Шоу и получены из Викисклада
Как вы можете видеть, младший байт идет первым, а самый старший - последним. Значение 32BPP ARGB будет храниться в памяти и на диске как отдельные 8-битные байты B, G, R, A. То же самое относится и к значению 24BPP RGB, которое хранится в памяти как B, G, R.
Это, вероятно, объясняет, почему формат по умолчанию, используемый WIC, выглядит как "BGR" - потому что это представление по умолчанию в памяти, и преобразование в RGB с прямым порядком байтов будет дополнительной работой, которая не выполняется без явного запроса.
Между прочим, люди обычно читают числа как big-endian; в обратном порядке. Байт-байтовое представление того же слова 24BPP/32BPP читается как RGB или ARGB, ближе к тому, что вы, похоже, ожидаете.
Этот форум говорит,
Это покрыто MSDN. Кодер JPEG кодирует три формата:
- GUID_WICPixelFormat8bppGray
- GUID_WICPixelFormat24bppBGR
- GUID_WICPixelFormat32bppCMYK
Если ваши исходные данные имеют другой формат, вам нужно использовать IWICFormatConverter как часть вашей цепочки.
