Есть ли качество, размер файла или другие преимущества для форматов JPEG, кратных 8 или 16 пикселей?

Question

Процесс кодирования сжатия JPEG разделяет данное изображение на блоки размером 8x8 пикселей, работая с этими блоками в будущих сжатиях с потерями и без потерь. [источник]

Также упоминается, что если изображение представляет собой несколько блоков 1MCU (определяемых как минимальная кодированная единица, «обычно 16 пикселей в обоих направлениях»), то могут быть выполнены изменения JPEG без потерь. [источник]

Я работаю с изображениями продуктов и хотел бы знать, как и сколько преимуществ можно получить, используя кратные 16 в моем конечном размере изображения (скажем, используя изображение размером 480 на 360 пикселей) по сравнению с не - кратно 16 (например, 484x362). В этом примере меня не интересуют дальнейшие изменения, редактирование или повторное сжатие конечного изображения.

Чтобы попытаться приблизиться к конкретному ответу, где, как я знаю, должны быть в основном общие черты: учитывая изображение размером 480x360, которое составляет 64 КБ и сохранено с максимальным качеством в Photoshop [пример] :

• Можно ли ожидать потери качества изображения 484x362
• Какое количество добавлений к размеру файла я могу ожидать (для этого примера дополнительное пространство будет белыми пикселями)
• Есть ли какие-либо иные недостатки, связанные с увеличением размера по сравнению с сеткой 8 пикселей?

Я знаю, что использовать этот конкретный пример произвольно, но было бы полезно (для меня и, возможно, для любых других людей обдумать размер изображения), чтобы понять, с каким уровнем компромисса я буду иметь дело при нарушении сетки не-8px .

Ключевой вопрос здесь - это спор о том, являются ли 8-пиксельные делимые изображения более высокого качества, чем изображения, которые не делятся на 8-пиксельные.

Answer 1

8 пикселей - отсечка. Причина в том, что изображения JPEG - это просто массив блоков DCT 8x8; если разрешение изображения не mod8 в обоих направлениях, кодировщик должен заполнить стороны до следующего разрешения mod8. На практике это не очень дорого; что гораздо хуже, это случаи, когда изображение имеет четкие черные линии (например, изображение в виде почтового ящика), которые не лежат на границах блоков. Это особенно проблематично при кодировании видео. Причина этого в том, что частотное преобразование резкой линии является гауссовым распределением коэффициентов, что приводит к огромному количеству битов для кодирования.

Для любопытных наиболее распространенным методом заполнения краев при внутреннем сжатии (например, изображениях JPEG) является зеркальное отображение линий пикселей перед краем. Например, если вам нужно заполнить три линии, а линия X - это край, линия X + 1 равна строке X, строка X + 2 - строке X-1, а строка X + 3 - строке X-. 2. Это довольно эффективно минимизирует стоимость в коэффициентах преобразования дополнительных строк.

Однако во взаимном кодировании алгоритмы заполнения, как правило, просто дублируют последнюю строку, потому что метод зеркалирования не работает хорошо для взаимного сжатия, такого как сжатие видео.

Answer 2

Иногда вам нужно использовать границы 16 пикселей, а не 8 из-за подвыборки; каждый 2-й пиксель отбрасывается во время процесса кодирования, и эти блоки DCT 8x8 начинаются как 16x16 и декодируются обратно в 16x16. Это не будет проблемой при настройках наивысшего качества.

Answer 3

JPG с размерами, кратными 8, также можно вращать / переворачивать без потери качества. Например, gthumb может сделать это в Linux.

Answer 4

Размеры изображения, кратные 8 или 16, не сильно повлияют на размер диска, но вы можете существенно сэкономить, если выровняете визуальное содержимое с сеткой 8x8 пикселей, например, если есть повторяющийся узор или текстуру на изображении.

Answer 5

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