Jpeg, вычисляющий макс. размер

Окончательный размер в байтах зависит от используемых настроек качества кодирования и количества пикселей. В вашем случае все изображения должны быть одинакового размера, поскольку вы выполняете кодировку, и ваш пользователь, кажется, вынужден рисовать в области 200x200.

Однако, согласно Википедии, максимум составляет примерно 9 бит на пиксель.

Итак, 200 * 200 * 9 = 360000 бит = 45 КБ

http://en.wikipedia.org/wiki/JPEG#Effects_of_JPEG_compression

Максимально возможный размер JPEG должен составлять примерно ширина * высота * 12 бит .

JPEG преобразует изображения в другое цветовое пространство (YCbCr), в котором используется меньшее количество бит (точнее, 12) для представления одного цвета. Однако на самом деле изображение будет намного меньше, чем предполагает приведенная выше формула.

Если мы будем использовать только сжатие без потерь, размер файла будет немного меньше. Даже в этом случае никто этого не делает, поэтому ваше изображение должно быть намного ниже предела, установленного этой формулой.

Вкратце: максимум 60 кб, но, скорее всего, намного меньше.

Я не уверен, что это было бы так полезно, но я считаю, что абсолютный максимум, который может быть, будет следующим:

ширина * высота * 4 (размер int) Вам, вероятно, также следует добавить, может быть, килобайт для метаданных ... но я сомневаюсь, что изображение КОГДА-ЛИБО достигнет этого (поскольку в этом весь смысл сжатия JPEG)

Есть много способов сделать "патологический" файл JPEG / JFIF необычно большого размера.

В крайнем конце спектра нет ограничений на размер, поскольку стандарт не ограничивает некоторые типы маркеров, появляющиеся более одного раза - например, файл JFIF, полный многих ГБ маркеров DRI (определение интервала перезапуска), а затем микроконтроллер 8x8 пикселей в конце технически допустим.

Если мы ограничимся «нормальным» использованием маркеров, то найдем верхний предел следующим образом:

Некоторый фон -

1. JPEG кодирует пиксели как MCU (группа) блоков 8x8 пикселей (блоки DCT), один Блок DCT для каждого компонента (Y, Cb, Cr).

2. Чтобы получить наилучшее сжатие (и наименьший размер), используется схема субдискретизации цветности 4: 2: 0, в которой опущено 75% информации цветности. Чтобы получить наилучшее качество (и наибольший размер), файл имеет 2/3 цветности, 1/3 информации о яркости.

3. Символы битового потока Хаффмана используются для кодирования компонентов DCT, из которых до 65 на блок DCT (64 AC + 1 DC).

4. Символы Хаффмана могут иметь диапазон от 1 до 16 бит и выбираются кодером как можно меньшего размера; Однако можно указать выбор длины символа.

5. Окончательное кодирование потока битов Хаффмана должно быть выполнено так, чтобы маркеры могли быть однозначно идентифицированы. То есть, любое появление байта 0xff в выводе должно быть заменено двумя байтами - 0xff, 0x00.

Используя всю эту информацию, мы можем создать патологический, но действительный файл JPEG, который libjpeg (наиболее распространенная реализация декодера JPEG) с радостью декодирует.

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

Итак, мы определяем таблицу Хаффмана, которая устанавливает последние два символа следующим образом:

11111111_1111110  -> (0,0) (EOB - end of block value)
11111111_11111110 -> (0,15)

Такая таблица Хаффмана могла бы появиться в файле JPEG как:

0xFF, 0xC4 ; DHT - define huffman table
0x00, 35 ; length
0x00 ; DC 0
1,1,1,1,1,1,1,1,1,1, 1, 1, 1, 1, 1, 1 ; histogram
1,2,3,4,5,6,7,8,9,10,11,12,13,14,0,15 ; symbols

Теперь, чтобы закодировать блок DCT максимальной длины:

1 x DC of 31 bits  ( 11111111 11111110 11111111 1111111 )
64 x AC of 31 bits ( 11111111 11111110 11111111 1111111 )
= 2015 bits

Так как MCU будет состоять из 3 блоков DCT (по одному для каждого компонента), размер MCU будет 6045 бит.

Большинство этих байтов будут иметь размер 0xff, которые в соответствии со стандартом заменяются на 0xff, 0x00 в выходном потоке, чтобы отличить поток битов от действительных маркеров.

Выполните это сопоставление, и полный DCT будет представлен 8 повторениями следующего байтового шаблона:

0xff,0x00,0xfe,0xff,0x00,0xff,0x00
0xff,0x00,0xfd,0xff,0x00,0xff,0x00
0xff,0x00,0xfb,0xff,0x00,0xff,0x00
0xff,0x00,0xf7,0xff,0x00,0xff,0x00
0xff,0x00,0xef,0xff,0x00,0xff,0x00
0xff,0x00,0xdf,0xff,0x00,0xff,0x00
0xff,0x00,0xbf,0xff,0x00,0xff,0x00
0xff,0x00,0x7f,0xff,0x00

, что в сумме составляет 8 * 54 = 432 байта

Сложив все это, мы имеем: 3 компонента * (432 байта на компонент) = 1296 байтов на 8x8 пикселей

заголовок размером 339 байтов требуется для сегментов SOI / DHT / DQT / SOS для настройки свойств изображения и таблиц Хаффмана, 2 байта Маркер EOI необходим для завершения изображения.

Так как изображение 200x200 будет размером 25x25 микроконтроллеров, у нас есть окончательный размер:

339 + (25 * 25 * 1296) + 2 = 810341 байт

, что работает чуть более 20,25 байта на пиксель, что более чем в 6 раз больше, чем в несжатом BMP / TGA.