Являются ли «Windows Photo Viewer» вращения без потерь?

Могу ли я вращать сжатые с потерями фотографии, которые я просматриваю в Windows Photo Viewer, не беспокоясь о потере еще большей информации для сжатия?

Обратите внимание, что, насколько мне известно, поворот на 90 градусов (и 180, 270) без потерь сам по себе, потому что это обмен координатами x и y (другие углы требуют интерполяции). Таким образом, любые потери, связанные с преобразованием, происходят из повторного сжатия. Вы можете избежать этого пересчета, сохранив преобразованное изображение в формате без потерь, но это явно не является частью вашего вопроса, поэтому я не буду его предлагать

— Горацио

@horatio, кратные 90 градусов являются особым случаем для сжатия JPG, где технически возможно вращать изображение без цикла сжатия, просто «переупорядочивая» сжатые данные. Это включает удаление и применение слоя сжатия без потерь, поэтому размер файла может измениться, но никаких операций с потерями не требуется.

— RBerteig

Я думаю, что понимаю вас, но я хочу сказать, что jpeg - это формат дискового хранилища, который не влияет на качество самих преобразований. То есть, хотя часто говорят о работе с JPEG и т. Д., В то время как файл отображается на экране и управляется, это не JPEG.

— Горацио

Человек у меня ВСЕГДА хотел знать ответ на этот вопрос. ИМО они ДОЛЖНЫ быть. Но, скорее всего, из-за стандарта JPEG ... Я не думаю, что технически возможно сделать эту операцию без потерь.

— Тревор Бойд Смит

Google Picasa просмотра изображений без потерь. но это обманывает. это не поворачивает изображение. это просто отмечает в метаданных "показать это изображение повернуто".

— Тревор Бойд Смит

Если размеры изображения кратны 8 (или 16, если используется подвыбор цветности), то повороты без потерь. В противном случае невозможно повернуть изображение без повторного вычисления блоков, т.е. повторного сжатия изображения, что приводит к потерям.

Причиной этого является то, что изображения в формате JPEG разбиты на серии блоков 8x8 или 16x16, которые сжимаются по отдельности. Неполные блоки допускаются только по правому и нижнему краю. Таким образом, если ваше изображение не является точным кратным 8/16, оно будет содержать неполные блоки, которые после поворота окажутся на неправильном краю.

Я подтвердил приведенное выше утверждение, используя версию Windows Photo Viewer, поставляемую с Windows 7. Я использовал два изображения цветового шума. Одно изображение было 256x256, то есть оба размера, кратные 8. Другое изображение было тем же, но обрезано до 253x253, то есть ни один размер не был кратен 8. Вот изображения:

256x256

253x253

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

256x256

253x253

Нет необходимости выполнять вычитание, чтобы увидеть разницу с 253-пиксельным изображением, оно заметно темнее и мутнее!

Разница на другом изображении выглядит так:

то есть изображения идентичны, вращения были без потерь.

— Мэтт Грум
источник

Я знаю, что в прошлом, когда я делал ротации, он предупреждал меня, что ротация будет с потерями, что означает, что в случаях, когда предупреждение не отображалось, трансформация была без потерь, но я не проверял. Также я не помню, какую версию WPV я использовал, не исключая возможности того, что MS изменила кодовую базу, так что нет, я не могу быть уверен.

— Мэтт Грум

@ Изображение с чистым шумом по определению является худшим случаем для JPEG (или любого алгоритма сжатия), поэтому я выбрал его! Результаты на реальных изображениях будут выглядеть лучше.

— Мэтт Грум

@MattGrum, очень классная демонстрация. Я надеюсь, что все производители цифровых камер имеют свои размеры изображения в целых кратных 8!

— Тревор Бойд Смит

@MattGrum Я работал в команде WPV. AFAIK, (и я почти уверен), ваш ответ правильный. Кроме того, +1 за очень тщательный метод доказательства вашей гипотезы

— :)

@TrevorBoydSmith каждая камера, которую я видел, имеет размеры изображения, кратные 8 или 16. Поворот не обязательно является причиной, он может просто позволить некоторую оптимизацию конвейера JPEG.

— Марк Рэнсом