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

Question

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

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

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

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

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

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

Ключевым вопросом здесь является дискуссия, которую я вел: являются ли 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 из-за субдискретизации;каждый второй пиксель выбрасывается во время процесса кодирования, и эти блоки DCT 8x8 изначально имели размер 16x16 и будут декодироваться обратно в 16x16.Это не будет проблемой при настройках самого высокого качества.

Answer 3

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

Answer 4

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

Answer 5

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