В чем причина ограничения на размер изображения 65536 на 65536 px в формате JPEG(JFIF)?

Question

[kras_ai]

Столкнулся с необходимостью технического обоснования выше указанного ограничения.
Ознакомившись с спецификацией JFIF ответ на вопрос найти не смог.
Прошу помочь советом, ну или ответом :)
Спасибо.

Answer 1

[pi314]

Wikipedia:

65536 is a power of two: 2^{16} (2 to the 16th power)

Все элементарно: в седой древности, когда разрабатывался формат, 16 бит было "нормальной" разрядностью и казалось более чем достаточно на веки вечные. Ну, а потом, когда в мире наплодилось имплементаций, было уже поздно что-то менять :) Ну, и если честно: 64к пикселей, это весьма немало и этого стало реально нехватать сравнительно недавно.

UP:
JFIF, как формат, вообще, затачивался под медленные каналы связи (на те времена диал-ап 300 Baud было верхом совершенства) с последовательной передачей. Этим определена структура разметки (попрыгушечки по блокам через оффсеты) и структура файла: ключевая информация (например, IPTC) как можно ближе к началу, данные - в хвосте. Предполагалось, что принимающая система может в зависимости от уже принятых метаданных "на лету" перенаправить дальнейший поток данных, куда нужно. По тем временам это было весьма резонное соображение, т.к. ресурсы (в первую очередь, доступная память) были крайне ограничены.

UP2:

Вы считаете, что дело в размерности полей "X density" и "Y density"?

Нет! Мы считаем, что дело в структуре маркера SOF0 (0xC0) (Start Of Frame), за которым следуют:
- 8 бит - бит-на-пиксель,
- 16 бит - ширина,
- 16 бит - высота и
- 8 бит - кол-во компонент.

Вот эти самые 2 по 16 бит и ограничивают макс. размеры изображения.

Density - это совсем из другой оперы. Как следует из названия, это таки реально разрешение по осям Х и У, задаваемое в единицах, которые закодированы в пред. байте.

Comments

[kras_ai]

Спасибо за дополнительные разъяснения. Про «ошибочные раскопки» согласен, собственно это же и пытался объяснить в рассуждениях. Еще раз спасибо. Удачи!

[StrangeAttractor]

"ключевая информация (например, IPTC) как можно ближе к началу, данные - в хвосте ... По тем временам это было весьма резонное соображение..." - оно по любым временам резонное, мне кажется.

[pi314]

@StrangeAttractor Ну, теоретически, конечно - да. Но в случае с JPEG это давно стало практически не актуально, т.к. файл обрабатывается целиком, т.е. когда все данные "уже есть" (как правило, на носителе с произвольным доступом). Для примера, в том же MP3 метаданные вполне себе стандартно могут находиться в хвосте и никого это особенно не смущает. Такой подход принципиально важен только для стрима или для носителя с последовательным доступом, типа магнитной ленты. При поблочном чтении или в памяти (где прыжок на любое смещение практически ничего не стоит) никакого принципиального преимущества, кроме морального удовлетворения, он не дает :)

[StrangeAttractor]

Ну, @pi314, я непосредственно думаю о быстроте и удобстве определения типа файла (правильное - именно по сигнатуре, а не по части имени файла) и считывания метаданных, например, файловым менеджером (кстати ненавижу файлы thumbs.db и тому подобный сифилис - всегда отключаю их генерацию). Я, например, активн пользуюсь реалтзованными через плагин колонками отображения высоты и ширины тех же JPEG-ов в Total Commander. Понятно, что можно потерпеть несколько лишних секунд, но лучше же не терпеть если можно это заложить на этапе дизайна. Плюс слабые каналы никуда не исчезают: спутниковые телефоны в труднодоступных местах, огомные площади "регионов" (у меня на даче (в очень обжитом районе всего в нескольких десятках километров от Питера) даже 3G не ловит, в лучшем случае с трудом GPRS), часы пик в больших городах, когда все сидят в машинах в пробках и по полчаса не могут страницу открыть, кафе, торговые центры и тому подобное с практически поголовно жутко говёным (а в некоторых местах при этом ещё и платным) WiFi, и т.д. Плюс в той же Европе, например (где я обитаю уже немало лет), дела с доступностью высоких скоростей в общем гораздо хуже, чем в Москве или в Украине.

[StrangeAttractor]

В то же время помещать метаданные в конец файла - тоже вполне логично: в результате чётко выделяется неизменяемая (immutable) часть файла, которая, в системе отсчёта от начала данного файла, не меняется как бы пользователь ни развлекался с остальным, в аналогичном случае если метаданные в начале - то смещение данных меняется если только блок метаданных не имеет строго регламентированный размер (что не желательно с точки зрения задела на возможности прозрачной эволюции формата).

Answer 2

[Dmitry]

Размер X и Y 2 байта, больше чем 65536 в 2 байта не записать.
en.wikipedia.org/wiki/JPEG_File_Interchange_Format...

Comments

[kras_ai]

Если вы про поля "X density" и "Y density" то они обычно равны 1 (соответственно при "Density units=0"). Не уверен что дело только в ограничении размерности данных полей.
.....+ проверял в HEX редакторе файлики JPEG

[Dmitry]

Чему они равны это одно, а сколько под них места выделено это другое, спецификация формата выделает под эти данные по 2 байта, соответственно писать туда можно хоть 0, хоть 65536. Псевдокод будет выглядеть так :
int x = read(buf, 2);

[kras_ai]

Про размерность согласен. Но является ли это ограничением, влияющим на возможность хранить изображение разрешения более рассматриваемого?
Заголовок нескольких файлов JPG(JFIF) я проанализировал с помощью HEX редактора, везде данные поля равны 1. (соответственно при unit=0). При остальных значениях "unit", данные поля хранят разрешение.

[pi314]

@kras_ai @CTAKAH4uK Вы не там роете! Если лень внимательно прочесть и понять спецификацию формата, читайте апдейт моего ответа. Там - точный ответ на вопрос.

Answer 3

[Юрий Лобанов]

Здравый смысл?

Answer 4

[kras_ai]

Вы считаете, что дело в размерности полей "X density" и "Y density"?