Какой самый большой размер JPEG 640x480?

Я создаю устройство хранения данных, которое делает несколько снимков ночного неба за пару часов, и они будут загружены сразу после того, как все они сделаны. Карта памяти должна быть способна хранить все снимки одновременно.

Размер файла JPEG, который будет получен, составляет 640x480 пикселей, и очень важно, чтобы на карте памяти было достаточно места для всех 100 из них. Так какой же самый большой размер JPEG 640x480?

Я сделал несколько тестовых фотографий, чтобы понять это:

• Размер файла изображения «stackoverflow» составляет 73 774 байта.
• Размер файла белого изображения составляет всего 36 607 байт.
• Но размер файла для клетчатой ​​фотографии составляет 149,339 байт.

Я предполагаю, что размер файла увеличивается со сложностью.

Как можно разместить на карте памяти достаточно места, чтобы вместить 100 файлов JPEG 640x480, не зная, насколько они сложны и какого размера они будут? Я не хочу тратить лишнее пространство, так как, возможно, я делаю многие из этих устройств захвата.

Здесь я предлагаю верхнюю границу для размеров файлов JPEG. См . Ответ Ильмари Каронен для обсуждения более типичных размеров JPEG.

Пиксельное пространство для 32-битного растрового изображения 640X480 можно рассчитать следующим образом (основываясь на этом ответе, но исправив его на основе комментария Игнасио Васкеса-Абрамса и этого ответа):

Предполагая, что к файлу не применено сжатие, имеется 307 200 пикселей, что составляет 0,3 МП. Удобный столик

Если каждый пиксель содержит 32 бита информации, то

1. 307 200 * 32 = 9 830 400 бит информации
2. Разделите на 8 бит, чтобы стать байтовым значением
3. 9 830 400/8 = 1228800 байт (или 1,17 Мб)

Это размер несжатого растрового изображения, и поэтому он должен быть верхним пределом для размера файла JPEG (на самом деле, поскольку формат JPEG использует сжатие , ваши изображения должны быть намного меньше, особенно учитывая, что вы делаете ночные снимки). небо, которое я представляю, содержит много черного. Обратите внимание, что самый большой пример изображения в вашем вопросе составляет всего 0,14 МБ).

Что касается вашей конкретной проблемы, тем не менее, даже с использованием этой верхней границы, 100 изображений - это всего 117 МБ, и прошло много времени с тех пор, как я видел карту памяти размером до 128 МБ. Я подозреваю, что у любой доступной в настоящее время карты памяти будет достаточно емкости, чтобы удовлетворить ваши потребности.

По-видимому, вопрос максимального размера файла JPEG является предметом некоторых дискуссий. В этом ответе о переполнении стека предлагается теоретический максимальный размер в 20,25 байта на пиксель или 5,9 МБ в вашем случае, но для создания изображения такого размера требуется преднамеренное неправильное использование схемы сжатия в формате JPEG, поэтому крайне маловероятно, что вы когда-либо увидите такое вещь, созданная камерой.

Просто чтобы проверить, позвольте мне проверить анализ ForeverWintr экспериментально.

Наихудшим видом входного изображения для сжатия JPEG (или любого другого сжатия на самом деле) является равномерно случайный шум RGB, который теоретически несжимаем. Итак, позвольте мне сгенерировать некоторые из них с помощью инструментов netpbm :

$ rawtoppm < /dev/urandom 640 480 > rnd.ppm
$ pnmtopng < rnd.ppm > rnd.png
$ du -b rnd.*
923772  rnd.png
921615  rnd.ppm

^{(Равномерно случайный шум RGB, формат PNG без потерь, 903 кбайт)}

^{Примечание (март 2017 года): Я вполне уверен, что изображение выше было в формате PNG, когда я впервые написал этот ответ и загрузил его еще в 2013 году. (Ниже даже есть комментарий об управлении цветом, который сильно подразумевает это.) К сожалению, это будет кажется, что в какой-то момент он был тихо преобразован в JPEG, что делает визуальное сравнение здесь бесполезным.}

^{Я попытался повторно загрузить новое тестовое изображение PNG, но, по-видимому, оно достигает какого-то произвольного предела размера файла PNG в imgur и автоматически преобразуется в JPEG. Я не уверен, есть ли способ обойти эту проблему, но, по крайней мере, если у вас есть доступ к Linux, вы всегда можете повторно запустить данные команды, чтобы сгенерировать свои собственные тестовые образы. В любом случае, кроме предотвращения прямого визуального сравнения качества сжатия, это никоим образом не делает недействительным анализ, приведенный ниже.}

Итак, несжатый файл PPM имеет длину 640 × 480 × 3 = 921 600 байт, плюс 15 байт для минимального заголовка PPM, как и ожидалось. Попытка сжать его без потерь с использованием формата PNG в конечном итоге приводит к увеличению размера на 2157 байт, что, вероятно, связано с заголовками и метаданными PNG и, возможно, с некоторой неэффективностью алгоритма сжатия, пытающегося сжимать несжимаемые данные.

(Да, это 3 байта на пиксель, а не 4, и даже формат PPM, что примерно так же просто , как графический формат может получить, не глуп достаточно , чтобы хранить бесполезный четвертый байт на пиксель на диске Там. Может быть какой - то Преимущество делать это в памяти по причинам выравнивания, особенно если вам также необходимо сохранить альфа-канал, но эти причины не применимы при записи изображения в файл.)

ОК, а как насчет JPEG? Попробуем сначала минимизировать потери на сжатие (качество = 100, отсутствие подвыборки цветности, DCT с плавающей точкой). К сожалению, в pnmtojpegруководстве не дается четкого объяснения того, как установить все соответствующие параметры (в частности, этот -sampleпараметр указан в разделе «Параметры для мастеров», который просто ссылается на файл в документации по libjpeg), поэтому я преобразую его в ГИМП вместо. Полученный файл выглядит так:

897249  rnd.jpg

^{(JPEG сжатый RGB-шум, качество = 100, без подвыборки цветности, 876 кб)}

Что, как это может быть меньше? Разве я не сказал, что чистый шум несжимаем? Дело в том, что даже при максимальном качестве обычное сжатие JPEG не совсем без потерь. Повторно открывая изображение в GIMP и сравнивая его с оригиналом, можно увидеть, что значения цвета некоторых пикселей смещены на один или два шага (из 256). Это те пиксели, где алгоритм сжатия JPEG «обманул» и выбросил немного здесь, другой - туда, где он оценил, что изменение не будет заметно. Действительно, для невооруженного человеческого глаза результат весьма неотличим от оригинала, но эти отброшенные биты в целом приводят к заметному уменьшению размера файла, даже после учета заголовка и накладных расходов кодирования.

Так что это было максимальное качество; а как насчет более типичных настроек, таких как pnmtojpegнастройки по умолчанию (качество = 75, субсэмплинг включен)? Давай попробуем:

$ pnmtojpeg < rnd.ppm > rnd2.jpg
$ du -b rnd2.jpg
185128  rnd2.jpg

^{(JPEG сжатый RGB-шум, качество = 75, выборка цветности, 184 кб)}

Вау, с 901 до 184 кб! Это довольно агрессивное сжатие, и вы можете точно определить разницу, сравнивая изображения. В основном это связано с подвыборкой цветности, которая в основном просто отбрасывает 75% данных о цвете (оттенок / насыщенность). Попытка его в GIMP с отключенной подвыборкой дает файл размером 350 618 байт, который все еще выглядит (по крайней мере, для человеческого глаза) довольно близко к оригиналу даже при увеличении.

В любом случае, смысл всего этого в том, чтобы продемонстрировать, что независимо от того, насколько шумными будут ваши фотографии в ночном небе, и независимо от того, какое высокое качество вы можете выбрать, просто невозможно, чтобы файл JPEG 640 × 480 мог быть значительно больше 900 кб. (Что ж, если ваша камера не подключила к нему мульти-мегабайтный цветовой профиль Exif или что-то такое же глупое, то есть.) И если вы используете более типичные настройки сжатия JPEG, максимальный вероятный размер файла снижается примерно до 200 КБ или около того. ,