RGB и Grayscale в TIFF: измеренный тест 36 файлов без потерь

Для несжатого массива RGB 8 бит нужны три байта на пиксель, а для Grayscale 8 бит — один. Но сжатые файлы не обязаны отличаться ровно втрое. Мы сохранили 36 TIFF из контролируемых изображений и измерили реальные байты. Для шума 1024×1024 сжатый серый TIFF занял 1 049 274 байта, RGB — 2 785 748. Для рисунка с полосами отношение оказалось другим.

Это собственный тест кодирования на синтетических пикселях, проведённый 14 октября 2026 года. Он отличается от геометрической матрицы размера скана: здесь программа действительно создала, сохранила и повторно открыла каждый файл. Аппараты, фотографии и OCR не тестировались. Для расчёта своего архива пригодится калькулятор объёма, но коэффициент сжатия следует взять из собственной пробы.

Какие изображения использованы в эксперименте? #

Созданы три типа одноканальных 8-битных рисунков. «Полосы» — белый фон с чёрными и серыми прямоугольными линиями. «Градиент» — одинаковый во всех строках плавный переход от чёрного к белому. «Шум» — псевдослучайные значения от 0 до 255 с явно заданным начальным состоянием генератора.

Каждый рисунок создан в размерах 256×256, 512×512 и 1024×1024 пикселя. От исходного серого массива получена RGB-версия с тремя одинаковыми каналами: R = G = B. Поэтому обе версии показывают тот же серый рисунок, а исходная цветовая информация не удаляется — её не было.

Каждая версия сохранена дважды: как несжатый TIFF и TIFF с tiff_adobe_deflate. Произведение 3 рисунка × 3 размера × 2 режима × 2 варианта кодирования даёт 36 файлов. Метаданные фотографий, встроенные превью и цветовые профили не добавлялись. Этот ограниченный набор позволяет отделить структуру пикселей от сложностей настоящего архива.

Что именно было измерено и проверено? #

Размер файла получен из фактически сохранённых байтов, а не из формулы ширины и высоты. Затем каждый файл открыт заново. Проверены размеры, режим L/RGB и полное равенство декодированного массива исходному. Все 36 проверок дали совпадение.

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

Среда — Python и Pillow 12.2.0. Версия Pillow записана в каждой строке CSV. Кодек и его служебная упаковка могут меняться при другой сборке библиотеки. Для точного побайтного сравнения размера следует воспроизвести ту же среду; смысл теста остаётся проверяемым через собственное повторное сохранение и декодирование.

Какие размеры получились для 1024×1024? #

Без сжатия число пикселей одинаково, поэтому размеры не зависят от рисунка. Серый TIFF занимает 1 048 698 байт, RGB — 3 145 868. Разница с сырым массивом — служебные байты контейнера. При DEFLATE структура изображения меняет результат:

Для шумового серого рисунка DEFLATE оказался немного больше несжатого TIFF. Это не ошибка: упаковка не обязана сокращать любую последовательность байтов. Добавленные служебные данные при плохо сжимаемом содержимом способны увеличить результат.

Почему одинаковая геометрия даёт разное сжатие? #

У полос много повторяющихся участков. Градиент повторяет одну строку, но содержит последовательность разных значений внутри неё. Шум специально создаёт структуру с малым числом устойчивых повторов. Один и тот же кодек обрабатывает эти последовательности с разной эффективностью.

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

В настоящем скане присутствуют бумажная текстура, шум сенсора, зерно, мелкие буквы и цветовые различия. Они могут менять результат в обе стороны. Наши образцы не представляют статистическую выборку семейных фотографий или офисных документов. Мы не называем их результаты «средним размером TIFF».

Можно ли перенести вывод на PDF и JPEG? #

Нельзя автоматически. PDF — контейнер, в котором изображения могут использовать разные кодеки; дополнительно присутствуют страницы, текстовый слой, шрифты и метаданные. JPEG применяет другой механизм и часто связан с потерями. TIFF тоже может содержать разные способы сжатия; расширение файла само по себе не определяет обработку пикселей.

Если цель — уменьшить документ для отправки, сначала выясните, что именно создаёт объём. Перекодирование уже сжатого изображения в другой контейнер не гарантирует уменьшения. Для PDF порядок выбора показан в руководстве по уменьшению размера и инструкции сканирования в PDF.

Не сравнивайте размеры файлов с разными пикселями и называйте разницу свойством кодека. Если один вариант одновременно уменьшил dpi, перевёл цвет в серый и изменил формат, результат объединяет три изменения. Честный локальный тест меняет один параметр за раз либо явно перечисляет все различия.

Когда серый режим подходит для документа? #

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

Сначала сохраните цветную мастер-копию, затем создайте серую производную и сравните читаемость значимых областей. Режим Grayscale не равен однобитному чёрно-белому: первый сохраняет полутона, второй оставляет только два состояния. Значение битности объясняется в словаре, а оценка разных режимов хранения — в матрице объёма.

Для архивного проекта экономия места не должна быть единственным критерием. Результат, который потерял важные различия, может оказаться непригодным даже при очень маленьком размере. В тесте такие потери намеренно исключены за счёт серых исходных рисунков; реальные оригиналы требуют отдельной проверки.

Как повторить эксперимент на своих файлах? #

Сделайте копии нескольких характерных изображений и сохраните неизменный размер в пикселях. Сравните режимы и кодеки, записав версии программы и точные параметры. После сохранения откройте файл и проверьте не только объём, но и нужные признаки. Для кодирования без потерь можно дополнительно сравнить декодированные пиксели.

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

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

Где находятся данные и код? #

CSV с 36 наблюдениями публикует рисунок, размеры, каналы, битность, кодек, сырые и файловые байты, результат проверки, хеш исходных пикселей и версию Pillow. Исходный код повторно создаёт рисунки, файлы в памяти и проверки; псевдослучайный шум имеет фиксированное начальное состояние.

Вывод эксперимента ограничен, но полезен: трёхкратная разница числа каналов не задаёт постоянный коэффициент размера сжатого файла. Для собственного архива проверяйте структуру реальных образцов и сохраняйте результаты вместе с параметрами, вместо использования универсального обещания экономии.