Comments 32
В этом способе есть один жирный минус — изображение будет очень плохо сжиматься. Фактически его размер будет примерно равен размеру bmp изображения.
Скорее всего будет выгоднее хранить 2 или даже 3 копии изображения в формате типа png вместо закодированной несжимаемой шумной сетки.
Я думаю, просто размер этих самых рандомных блоков сделать в 16х16 (для JPEG), и будет, хоть и не такой крутое восстановление, но, тем не менее, всё равно будет.
Провел эксперимент на приведенных изображениях:
png:
оригинал — сжатие 0,5
кодированное — сжатие 0,85
jpg:
оригинал сжатие — сжатие 0,3
кодированное — сжатие 0,51
Не так уж все и плохо.
png:
оригинал — сжатие 0,5
кодированное — сжатие 0,85
jpg:
оригинал сжатие — сжатие 0,3
кодированное — сжатие 0,51
Не так уж все и плохо.
Существуют и рабочие методы:
cgm.computergraphics.ru/issues/issue17/poissonimaging
cgm.computergraphics.ru/issues/issue17/poissonimaging
Сделайте хайрезы по клику, пожалуйста. Хочется разглядеть.
Круто, только вот битмапы никто в чистом виде не хранит. Сжимают.
А для сжатых данных алгоритм в чистом виде не применим. А в не совсем чистом виде он очень давно уже есть в Progressive JPEG, в котором можно «потерять» часть конца файла, и всё равно распаковать картинку меньшего качества.
А для сжатых данных алгоритм в чистом виде не применим. А в не совсем чистом виде он очень давно уже есть в Progressive JPEG, в котором можно «потерять» часть конца файла, и всё равно распаковать картинку меньшего качества.
Практика ремонта JPEG-ов в течение нескольких лет показывает, что при сбое Progressive JPEG восстановлению подлежит только изображение очень низкого разрешения — первый скан, а все дальнейшие сканы восстановлению не подлежат совсем.
С другой стороны, в случае sequental, даже заметный сбой в начале/средине может быть нивелирован — «выкусыванием» сбойного фрагмента с восстановлением всего изображения после сбоя.
С другой стороны, в случае sequental, даже заметный сбой в начале/средине может быть нивелирован — «выкусыванием» сбойного фрагмента с восстановлением всего изображения после сбоя.
Помимо уже указанной невозможности сжать изображение после такого кодирования, есть и другие побочные эффекты.
1) Если окончание изображения не было «оторвано» или залито чёрным, а заменено фрагментом другого изображения, вы получите смесь из двух изображений. При примерно одинаковой яркости вы можете уже не подобрать фильтр, который подавит одно изображение и выделит другое.
Пример: восстановление удалённых файлов обычно приводит к такой каше из файлов.
2) Если средина файла была утрачена, а всё что после сдвинуто к началу, причём вы не знаете на сколько байт — сдвинутые данные распакуются на неправильные места и вы вместо *всего* изображения снова получите «помехи».
Пример: при перегреве флешек данные из них копируются с потерей синхронизации — с выпадениями и сдвигами.
3) Самое уязвимое место файла — заголовок. Для адаптивного JPEG-а повреждение таблиц Хаффмана (100-200 байт в заголовке) означает полную потерю изображения.
В целом вам нужно оценить устойчивость вашего кодирования к:
1) Замене данных на произвольные — белый шум, часть другого изображения вашего же формата, константы, BMP-образные данные и т.п.
2) Вставке чужих данных со сдвигом
3) Потере со сдвигом фрагмента файла вашего формата
4) Повреждению заголовка, в котором записана информация о типе кодирования, размере файла, типе и параметрах кодирования.
1) Если окончание изображения не было «оторвано» или залито чёрным, а заменено фрагментом другого изображения, вы получите смесь из двух изображений. При примерно одинаковой яркости вы можете уже не подобрать фильтр, который подавит одно изображение и выделит другое.
Пример: восстановление удалённых файлов обычно приводит к такой каше из файлов.
2) Если средина файла была утрачена, а всё что после сдвинуто к началу, причём вы не знаете на сколько байт — сдвинутые данные распакуются на неправильные места и вы вместо *всего* изображения снова получите «помехи».
Пример: при перегреве флешек данные из них копируются с потерей синхронизации — с выпадениями и сдвигами.
3) Самое уязвимое место файла — заголовок. Для адаптивного JPEG-а повреждение таблиц Хаффмана (100-200 байт в заголовке) означает полную потерю изображения.
В целом вам нужно оценить устойчивость вашего кодирования к:
1) Замене данных на произвольные — белый шум, часть другого изображения вашего же формата, константы, BMP-образные данные и т.п.
2) Вставке чужих данных со сдвигом
3) Потере со сдвигом фрагмента файла вашего формата
4) Повреждению заголовка, в котором записана информация о типе кодирования, размере файла, типе и параметрах кодирования.
Так всё и есть. Но, как я понимаю, автор не пытался соорудить защиту от какого-то повреждения файлов, встречающегося в реальной жизни. Ну, то есть, эта вот заливка части изображения чёрным — чисто умозрительная опасность. И пост (как, опять же, я понял) — это просто ответ на голографическое кодирование недавнее. В духе «гологаммы интересно, но ровно та же задача решается лучше вот так».
Выше написано много комментариев с рассуждениями о том, что так будут страдать алгоритмы сжатия. Но почему никто не спросил, при каких условиях вообще будут возникать дефекты такого рода? (большие связные дефектные области)
Если дефекты будут возникать на бинарном уровне, то тогда проще придумать формат изображения с избыточной информацией, и восстанавливать с помощью например тех же кодов Рида-Соломона
Если дефекты будут возникать на бинарном уровне, то тогда проще придумать формат изображения с избыточной информацией, и восстанавливать с помощью например тех же кодов Рида-Соломона
> при каких условиях вообще будут возникать дефекты такого рода? (большие связные дефектные области)
Условия не такие уж и редкие. Повреждение фотоснимка на флешке довольно часто убивает существенный фрагмент файла — в средине или до конца. Недокопировался, недозаписался, записался криво, удалён и восстановлен после записи на флешку.
> восстанавливать с помощью например тех же кодов Рида-Соломона
Рид-Соломон добавляет возможность восстановления ~X% объёма исходного файла за счёт добавления ~2X% к хранимому объёму. Засада в том, что если повредится больше X% объёма файла, то Рид-Соломон не сработает вообще.
Условия не такие уж и редкие. Повреждение фотоснимка на флешке довольно часто убивает существенный фрагмент файла — в средине или до конца. Недокопировался, недозаписался, записался криво, удалён и восстановлен после записи на флешку.
> восстанавливать с помощью например тех же кодов Рида-Соломона
Рид-Соломон добавляет возможность восстановления ~X% объёма исходного файла за счёт добавления ~2X% к хранимому объёму. Засада в том, что если повредится больше X% объёма файла, то Рид-Соломон не сработает вообще.
Еще проще не использовать такой канал, на котором могут возникать такие дефекты. Избыточность и помехоустойчивость лучше применять уровнем ниже, ко всему каналу или протоколу сразу. Чтобы не придумывать отдельный алгоритм для каждого типа передаваемых файлов или данных. Уж очень сложно делать по новому алгоритму для всех возможных типов данных )
Условия простые — снимок распечатан, половина оторвана, и снова отсканирован :)
Извините, но в приведенном примере задействано исходное изображение.
Да, вы пишите, что в теории можно картинку для начала размазать и применить метод. Но на практике это не показано. А ведь чудес не бывает, потерянную инфу легко не вернешь.
Советую почитать по теме: cgm.computergraphics.ru/issues/issue17/poissonimaging
Да, вы пишите, что в теории можно картинку для начала размазать и применить метод. Но на практике это не показано. А ведь чудес не бывает, потерянную инфу легко не вернешь.
Советую почитать по теме: cgm.computergraphics.ru/issues/issue17/poissonimaging
ВО! Нашёл! habrahabr.ru/blogs/image_processing/120473/ Вам явно сюда!
Метод методом, но объясните мне пожалуйста, КАК, откуда программа знает что было на испорченном куске?
Что именно кресла-лежалки в таком порядке, что именно их было столько, и что там не было, допустим, человека?
Система понятна, но непонятно, откуда она знает, что там должно быть?
Что именно кресла-лежалки в таком порядке, что именно их было столько, и что там не было, допустим, человека?
Система понятна, но непонятно, откуда она знает, что там должно быть?
Вам система непонятна. Перечитайте статью.
Если перевести картинку в частотную область, то потеря достаточно большой части коэффициентов не сильно скажется на изображении. Грубо говоря критичны будут несколько первых, что в НЧ. Те что в ВЧ вызовут потерю резкости.
А вообще, давно уже придумали помехоустойчивые коды, того же Рида-Соломона, кодируйте свои важные данные и будет вас ЩАСТЬЕ)
А вообще, давно уже придумали помехоустойчивые коды, того же Рида-Соломона, кодируйте свои важные данные и будет вас ЩАСТЬЕ)
Рид с Соломоном рулят, но они о другом типе помех. Пример автора, конечно, надуманный и практической ценности в нём мало (в том виде, как он описан), но результат достаточно любопытен и имеет смысл для дальнейшего анализа.
Ну как вариант, на вскидку, можно наиболее значимые коэффициенты ДКП защитить избыточной информацией (тем же соломоном), а оставшиеся бросить как есть. Таким образом потеря низкочастотных коэффициентов скомпенсируется избыточностью помехозащищенного кода, а потеря высокочастотных не так страшна и приведет к некоторому размытию картинки.
От описанного типа дефектов это не спасёт. Вот если совместить перемешивание с вашим вариантом, тогда да, конечно. Получится ещё лучше. Ценность исследования в том, что даже такой примитивный метод (без расчехления теории чисел, полей, колец и циклических кодов, не говоря о разложениях в ряды) даёт потрясающе приемлимый результат. Осталось малое — придумать куда эту байду прикрутить. :) Как-то сходу не могу найти места, где такие дефекты могут сгенерироваться :).
One pixel camera dsp.rice.edu/cscamera
Немного не по теме, но по сути об одном. В топике про восстановление по части, а тут в некотором роде сжатие за счёт рандомизации.
Немного не по теме, но по сути об одном. В топике про восстановление по части, а тут в некотором роде сжатие за счёт рандомизации.
О прогрессивном сжатии автор не слышал?
Sign up to leave a comment.
Размышления о восстановлении испорченного изображения