jourmager
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Некоторые аспекты хранения изображений в pdf-файлах в контексте обсуждения программы WinSoftMagic Advanced PDF Compressor 2012
1) Изображения DeviceRGB с методом сжатия Run Length, ZIP или No Compression
1а) В PDF-XChange Editor свойства таких изображений (например): BPC: 1, Color Space: DeviceRGB, Compression: Run Length, ZIP
Т.е. один бит на компонент (канал), цветовое пространство RGB (три канала-компонента), сжатие методом Run Length, ZIP.
В самом pdf-файле будет строка: /BitsPerComponent 1/ColorSpace/DeviceRGB
Это означает, что в pdf-файле между соответствующими метками stream и endstream будет последовательность бит, которая кодирует цвет в формате RGB последовательно для всех пикселей.
При этом на кодирование одного цвета отводится 1 бит, а всего бит 3 (для 3 цветовых компонентов), соответственно всего цветов может быть 8 (2 в третьей степени).
Т.е. (например) для чисто красного цвета это будет последовательность 100100100100100100100100100100 или 92 49 24 9 в HEX-формате.
Надо учитывать, что если применяется сжатие (Run Length, ZIP), то данную последовательность бит в явном виде можно будет увидеть только после декомпрессии.
1б) если свойства такие: BPC: 2, Color Space: DeviceRGB, Compression: Run Length, ZIP и строка вида
/BitsPerComponent 2/ColorSpace/DeviceRGB
то это значит, что цвет кодируется двумя битами и соответствующая последовательность бит для (например) чистого красного цвета в несжатом потоке будет иметь вид
110000110000110000110000110000110000110000110000110000 или C3 0C 30 C3 0C 30 C3 в HEX-формате.
При этом на кодирование одного цвета отводится 2 бита, а всего бит 6 (для 3 цветовых компонентов), соответственно всего цветов может быть 64 (2 в шестой степени).
1в) если свойства такие: BPC: 4, Color Space: DeviceRGB, Compression: Run Length, ZIP и строка вида
/BitsPerComponent 4/ColorSpace/DeviceRGB
то это значит, что цвет кодируется четырьмя битами и соответствующая последовательность бит для (например) чистого красного цвета в несжатом потоке будет иметь вид
11110000 11110000 11110000 11110000 11110000 или F0 0F 00 F0 0F 00 F0 0F в HEX-формате.
При этом на кодирование одного цвета отводится четыре бита, а всего бит 12 (для 3 цветовых компонентов), соответственно всего цветов может быть 4096 (2 в двенадцатой степени).
2) Изображения Indexed с методом сжатия Run Length, ZIP или No Compression
В PDF-XChange Editor свойства таких изображений (например): BPC: 8, Color Space: Indexed (DeviceRGB), Compression: Run Length, ZIP
Т.е. восемь бит на компонент (канал), цветовое пространство RGB (три канала-компонента), сжатие методом Run Length, ZIP.
В самом pdf-файле будет примерно такая строка: /BitsPerComponent 8/ColorSpace[/Indexed/DeviceRGB 10 0 R]
Это означает, что в pdf-файле между соответствующими метками stream и endstream будет последовательность бит, которая кодирует цвет по номерам из "таблицы цветов" или "цветовой палитры" последовательно для всех пикселей.
При этом на кодирование номера цвета отводится 8 (восемь) бит, а всего цветов может быть до 255 включительно.
Тут важно не путать 8 бит для номера цвета и 8 бит для кодирования цвета в канале-компоненте.
Ограничение по количеству цветов в таблице цветов значением 255 заложено в стандарте PDF в разделе Indexed Color Spaces.
Итак, (например) для четырёх цветов это будет последовательность что-то вроде 00 00 00 00 00 00 01 01 01 01 01 02 02 02 02 03 03 03.
Где числа 00, 01, 02, 03 соответствуют порядковому номеру определенного цвета в таблице цветов.
Сама таблица цветов находится в объекте, следующим сразу после объекта, содержащего битовую последовательность цветов пикселей.
При этом между метками stream и endstream будет последовательность бит, кодирующая цвет в формате RGB.
Например, если цветов всего 4, и это, по порядку номеров (от 00 до 03), чистый красный (FF 00 00) , чистый зеленый (00 FF 00), чистый синий (00 00 FF), чистый белый (FF FF FF), то (несжатая) последовательность будет иметь вид
FF 00 00 00 FF 00 00 00 FF FF FF FF в HEX-формате. |
Всего записей: 832 | Зарегистр. 04-11-2019 | Отправлено: 11:13 02-05-2023 | Исправлено: jourmager, 12:25 02-05-2023 |
|
Помнится, даже hex-редактором залазил аж на гибкий диск, высчитывал место конкретного пикселя в секторе, правил биты и потом на экране разглядывал, что действительно пиксель цвет поменял как рассчитано. Других средств редактуры не знал. И там точно цвета были не восьмибитные 
