Как стать автором
Обновить

Комментарии 11

для простого теста, что файл догрузился, проверял если не путаю пару байт в конце
Я так и проверяю сейчас — первые и последние байты, но этого мало. Ряд изображений содержат маркеры, но битые по сути.

Например, файл загружался в несколько потоков кусками. Какой-то кусок не приехал и вместо него может быть блок нулей. Или может не быть.
Так нет там никакого контроля целостности. Поэтому любая смотрелка загрузит файл, но покажет мусор.
Делал очень давно, взял за основу rdjpgcom.c из какой то libjpeg, там разбор заголовка и пробег по маркерам без декодирования. Но это скорее типа для своего «jpeginfo»
Спасибо. Поковыряюсь в этом направлении.

Пара уточняющих вопросов.


Пусть у нас такие данные:
10 11 12 13 10 9
С помощью дельта-кодирования их можно представить так:
10 1 2 3 0 -1

Не должно ли быть 10 1 1 1 -3 -1? Насколько я понимаю, в дельта-кодировании нужно считать дельту от предыдущего элемента, а не от первого.


Кодирование Хаффмана…
Всё это хорошо, но что если нам нужно ещё сильнее сэкономить пространство? Например, так:
a: 0
b: 1
c: 00
d: 01
e: 10

Не будет ли коллизий с такой таблицей? Например, 100 можно прочитать как baa, можно как bc, можно как ea

Коллизии будут, это не префиксный код, это просто взятый для примера код с переменной длинной слова. Пример префиксного кода приведён в статье далее.

Кстати, может это и общеизвестно, но маркеры в jpg позволяют "спрятать" файл…
copy /b "photo.jpg" + "data.zip" "out.jpg"


Файл out.jpg практически всеми программами воспринимается как "картинка" исходного photo.jpg.
Но, при этом, если его переименовать в "out.zip", то большинство архиваторов будут работать с ним как с архивом.


Немного не по теме статьи. Просто вспомнилось

Большинство архиваторов и так будут работать, на расширение они не смотрят.
Спасибо! Очень познавательно. Буду изучить детали.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий