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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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