zed писал(а):[
- в JPG пишется первая строка ПОЛНОСТЬЮ, без пропусков;
- формируется следующая строка n*256 и так 256 раз (вполне возможно, что обработчику JPG передаётся не одна строка, а 8 или сразу все 256, из-за особенностей JPG-компрессии, но суть дела это ни сколько не меняет)
Вдогонку и на погоны -
конкретный пример на пальцах в аттаче:
1. Берем картинку 1.bmp (в данном случае 500х380 пикс)
2. Пишем ее в ЖПЕГ средствами фотошопа (baseline, 50% сжатия). Получаем картинку 1.jpg 500х380 с валидной жпег-структурой.
3. Опять берем картинку 1.bmp (500х380 пикс)
4. Клеим в нее ЛЮБУЮ произвольную область от другой картинки, не перекрывающую ВСЕГО изображения 1.bmp (в данном случае область 500х48 поверх исходных 500х380)
5. Сохраняем получившееся изображение в 2.bmp
6. Также пишем его же в ЖПЕГ средствами фотошопа (baseline, 50% сжатия). Получаем картинку 2.jpg 500х380 с валидной жпег-структурой.
Исходные данные готовы. Начинаем "анализ":
1. Смотрим на размеры файлов 1.bmp и 2.bmp. Размер файлов ИДЕНТИЧЕН - 570.056 байт, несмотря на разный контент.
2. Смотрим на размеры файлов 1.jpg и 2.jpg. Размеры файлов НЕ совпадают, в полном соответствии с логикой работы контентнозависимого сжатия, примененного в ЖПЕГе.
3. Берем любой инструмент сравнения бинарных файлов.
4. Смотрим на различия файлов 1.bmp и 2.bmp на уровне байт: прекрасно видим, что разница в файлах строго линейна, с определенными границами и имеет место быть ТОЛЬКО на том участке, где мы вклеивали новый контент (и не далее, вплоть до полностью одинаковых заголовков у обоих файлов). См. скриншот "1.bmp-2.bmp.diff_report.gif", различающиеся байты выделены в программе красным цветом, слева в виде узкой колонки - общий расклад обоих файлов по всей их длине.
5. Смотрим на различия файлов 1.jpg и 2.jpg на уровне байт: прекрасно видим, что разница в файлах ГЛОБАЛЬНА, имеет место быть по всему телу файлов плюс заголовок, а небольшие вкрапления одинаковых байт попадаются ТОЛЬКО в заголовке (на ту часть заголовка попадают данные о thumbnail исключая участок "разницы", данные о размере изображения, встраиваемом цветовом профайле, подписи кодера-упаковщика жпег и прочие одинаковые для обоих файлов метаданные). Явственно видно, что ТЕЛА файлов абсолютно различны и даже не совпадают по размеру, несмотря на локальное и небольшое изменение контента не превышающее общих размеров исходного изображения. См. скриншот "1.jpg-2.jpg.diff_report.gif", различающиеся байты выделены в программе красным цветом, слева в виде узкой колонки - общий расклад обоих файлов по всей их длине.
Резюме: локальное изменение контента файла формата БМП
не приводит ко глобальному изменению тела файла, и изменения легко предсказуемы и линейны. Локальное же изменение контента файла формата ЖПЕГ
приводит ко
глобальному изменению тела файла и\или общего размера
всего контейнера, предсказать изменения заранее не является возможным до момента окончания упаковки ВСЕГО контента в жпег и получения валидного окончательного жпег-файла.
Что и требовалось доказать. Что я и имел ввиду в своих постах на протяжении последней недели.
PS: все желающие могут поэкспериментировать с ТИФФом без сжатия. Картина будет абсолютно той же - и это я тоже утверждал ранее. Последующие перверсии от ораторов по типу "а в ЖПЕГ таки можно клеить частями рандомно и\или последовательно, в обход и\или без применения жпег-кодера - и при этом успешно получать валидную жпег-структуру..."
без приложения конкретных и проверяемых примеров мною лично будут клеймиться как "ФМЗ" (фимоз головного мозга™).
Вот теперь по жпегу, надеюсь, сказал действительно и окончательно
всё. 
, я набросал утилитку, которая склеивает тайлы по заданной области. Сохраняет файл в формате BMP.
TilesMerge.part2.rar
