Чи обертання програми "Windows Photo Viewer" без втрат?

Чи можна обертати збиті стислі фотографії, які я переглядаю в програмі перегляду фотографій Windows, не переживаючи про втрату ще більшої інформації при стисненні?

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

— horatio

@horatio, кратні 90 градусів є особливим випадком стиснення JPG, де технічно можливо обертати зображення без циклу стиснення, "просто" переставляючи стислі дані. Це передбачає видалення та нанесення шару стиснення без втрат, тому розмір файлу може змінюватися, але операції з втратою не потрібні.

— RBerteig

Я думаю, що я вас розумію, але моя думка полягає в тому, що jpeg - це формат зберігання диска і не має ніякого відношення до якості самих перетворень. Тобто, хоча часто йдеться про роботу з jpegs тощо, хоча файл відображається на екрані та маніпулює ним, це не jpeg.

— horatio

Чоловік, Я ВЖЕ завжди хотів дізнатися відповідь на це питання. ІМО вони повинні бути Але, швидше за все, через стандарт JPEG ... Я не думаю, що технічно неможливо зробити цю операцію без втрат.

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

Переглядач зображень Google Picasa НЕ втрачається. але це обманює. він не обертає зображення. він просто відмічається у метаданих "відобразити це зображення повернутим".

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

Якщо розміри зображення кратні 8 (або 16, якщо використовується підсистема кольоровості), то обертання без втрат. В іншому випадку неможливо повернути зображення без перерахування блоків, тобто повторного стиснення зображення, що є втратою.

Причиною цього є те, що зображення jpeg розбиваються на серії 8x8 або 16x16 блоків, які стискаються окремо. Неповні блоки дозволені лише з правого краю та нижнього краю. Таким чином, ваше зображення не є точним кратним 8/16, воно буде містити неповні блоки, які після обертання опиняться на неправильному краї.

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

256х256

253x253

Потім я здійснив чотири обертання проти годинникової стрілки, закриваючи переглядач фотографій після кожного обертання, щоб переконатися, що зображення зберігається в його поверненому стані.

256х256

253x253

Немає необхідності виконувати віднімання, щоб побачити різницю із зображенням 253 пікселів, воно помітно темніше та брудніше!

Відмінність від іншого зображення виглядає так:

тобто зображення однакові, обертання були без втрат.

— Метт Грум
джерело

Я знаю, що в минулому, коли я робив обертання, він попереджав мене про те, що обертання буде втраченим, що означає, що у випадках, коли попередження не відображалося, трансформація була без втрат, але я не перевіряв. Я також не пам'ятаю, яку версію WPV я використовував, не виключаючи можливості, що MS змінила базу коду, так що ні, я не можу бути впевнений.

— Метт Грум

@Tim зображення чистого шуму - це за визначенням найгірший випадок для jpeg (або будь-якого алгоритму стиснення), саме тому я вибрав його! Результати на реальних зображеннях виглядали б краще.

— Метт Грум

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

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

@MattGrum Раніше я працював у команді WPV. AFAIK, (і я впевнений, що ваша відповідь правильна. Також +1 за дуже ретельний метод доведення вашої гіпотези

— :)

@TrevorBoydSmith кожна камера, яку я бачив, має розміри зображень, кратні 8 або 16. Обертання не обов'язково є причиною, це може просто дати змогу оптимізувати конвеєр JPEG.

— Марк Рансом