Разве все цифровые изображения в конечном итоге не являются значениями пикселей в диапазоне от 0 до 255?

У меня есть несколько невероятно простых (глупых?) Вопросов об изображениях; в частности, форматы изображения и значения пикселей.

Прости, я не фотограф. Я просто тот, кто работает с изображениями, и для меня они просто строки и столбцы чисел.

Мои вопросы:

Если по сути, фотографии представляют собой всего 3 канала значений пикселей [0, 255] X RBG, то как может быть какая-либо разница между любыми двумя форматами изображений? Я имею в виду, что делает RAW отличным от TIFF - не ограничены ли они значениями от 0 до 255? Число - это число - не должен ли быть возможен только один заданный формат? Или не должны ли два изображения одинаковой высоты и ширины иметь одинаковый размер файла?

Кроме того, с цифровой точки зрения, что отличает 16-битные изображения от 32-битных? Опять же, изображение - это просто массив с целочисленными значениями от 0 до 255.

Продолжая с этой точки зрения, что изображение в файловой системе компьютера представляет собой просто 3-канальный массив целых чисел в диапазоне от 0 до 255, какой смысл сжимать изображение в формат с потерями, такой как, например, JPG? Скажем, алгоритм сжатия изменяет некоторые значения пикселей с 254 до 255 или как угодно. Так? Как это обеспечивает экономию размера файла или влияет на качество изображения?

Я знаю, что существует множество разных способов хранения данных изображений. Но я не спрашиваю ни о чем, кроме основного 3-канального изображения RBC. Все, что я знаю, это то, что, если кто-то вручит мне один из них, у меня теперь есть массив чисел. У меня нет причин знать, почему один массив чисел может отличаться от другого массива чисел от 0 до 255. Надеюсь, это имеет смысл. Этот вопрос не ограничивается форматом RAW! Скорее, речь идет о любом массиве значений пикселей

Извините, но ваша основная предпосылка неверна: изображение может быть закодировано как массив пикселей RBG с 8 битами на значение, но есть много других способов:

• один канал с одним битом / каналом (чистый черный и белый),
• один канал с x бит / канал (в градациях серого, x обычно составляет 8 или 16, что дает значения 256 или 65536)
• различные форматы на основе палитры (cf.GIF)
• полноцветное с (по крайней мере, теоретически) количеством каналов с любой требуемой битовой глубиной.

И это для изображения, хранящегося в оперативной памяти компьютера во время редактирования / просмотра. Я игнорирую различные существующие форматы изображений RAW (здесь и в оставшейся части этого поста).

Для фотографии наиболее распространены 3 канала с 8, 16 или 32 битами / канал (обычно целочисленные, но по крайней мере некоторые программы работают внутри с 32-битными числами с плавающей запятой). Часто есть 4-й канал (альфа), особенно когда программа позволяет использовать слои. И где-то размеры массива изображения должны быть сохранены.

Существуют различные причины для этих разных форматов. Что касается формата в памяти, то важным фактором были размер данных и скорость (намного быстрее манипулировать одним 8-битным каналом, чем 4 32-битными каналами). Это менее важно в наше время, но мы получили полное управление цветом с различными цветовыми пространствами. Некоторым из них (например, prophoto RGB) требуется не менее 16 бит / канал, чтобы различия между соседними цветами были достаточно малыми, чтобы избежать видимых полос. По мере усложнения процедур есть преимущества использования 32-битных чисел с плавающей запятой (когда цвета кодируются значениями от 0,0 до 1,0, а обработка допускает промежуточные значения вне этого диапазона).

Если вы хотите сохранить изображение в файл и загрузить его в те же данные в памяти, вам нужно использовать как минимум столько же битов на канал, сколько в формате im-memory, и вы должны хранить информацию о размеры изображения, битовая глубина и цветовое пространство.

Пользователи этих изображений также любят хранить некоторую дополнительную информацию об изображении (подпись, заголовок, кто взял изображение и т. Д.). Опять разные способы хранения этой информации.

Тогда есть различные способы сжатия данных изображения для хранения файлов. Одним из более простых является RLE (Run Length Encoding), где вы сохраняете счетчик и значение пикселя всякий раз, когда сталкиваетесь с повторяющимся значением пикселя. Другие, такие как jpeg, намного сложнее, но также дают гораздо большее сжатие. Например, jpeg использует косинусное преобразование и отбрасывает (менее видимую) высокочастотную информацию, обеспечивая высокие коэффициенты сжатия за счет потери информации (это еще не все, но это слишком долго).

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

Затем происходит постоянное развитие, например, методов сжатия без потерь, с которыми существующие форматы не всегда могут справиться.

Таким образом, мы получаем различные форматы файлов, с различными компромиссами между точностью сохраненной информации, занимаемым дисковым пространством и скоростью чтения, записи и передачи (сравните размер несжатого TIFF и JPG приличного качества) ,

Если вы обрабатываете изображение в памяти, оно будет в форме одного или нескольких массивов. На этом этапе оригинальный формат файла больше не должен играть никакой роли . Я предполагаю, что вы обрабатываете свои данные с 8 бит / канал.

Но вам нужно знать, есть ли у вас обработанное изображение или необработанное изображение, поскольку между ними есть два важных различия:

• необработанные изображения обычно имеют 1 цвет на пиксель , а пиксели обычно располагаются в массиве Байера с 2 зелеными, 1 красным и 1 синим пикселем на квадрат из 4 пикселей. Значения пропорциональны интенсивности сцены (кроме очень низких и очень высоких значений).
• обработанные изображения могут быть упорядочены в виде двумерного массива записей, содержащего 3 числовых значения, или в виде цветовых плоскостей (3 двумерных массива, по одному для каждого из R, G, B). Кроме того, значения обычно не пропорциональны интенсивности сцены . Хуже того, точное соотношение между значениями пикселей и интенсивностями сцены зависит от обработки изображения. И баланс между цветами был настроен так, чтобы соответствовать реакции человеческого глаза (баланс белого, красный и синий усилены относительно зеленого).

Таким образом, если вы получаете необработанное изображение с 3 значениями цвета на пиксель, то это необработанное изображение уже подверглось некоторой обработке (по крайней мере, либо демозакуация , либо простое объединение 4 необработанных пикселей в 1 пиксель изображения). Будет ли это приемлемым, будет зависеть от вашего приложения.

Если в основе, фотографии только 3 канала пиксельных значений [0, 255] X RBG,

Но фотографии - это не «всего 3 канала значений пикселей», даже «по сути». Компьютерные экраны обычно состоят из массива пикселей RGB, поэтому, если вы хотите отобразить изображение на экране компьютера, вы должны в какой-то момент отобразить любые имеющиеся у вас данные изображения в массив пикселей RGB, но эти данные являются только конкретный рендеринг данных изображения. Данные на изображении могут вообще не состоять из потока значений пикселей. Чтобы получить значения пикселей из изображения, вы должны знать, как форматируются данные.

тогда как может быть какая-то разница между любыми двумя форматами изображений? Я имею в виду, что делает RAW отличным от TIFF - не ограничены ли они значениями от 0 до 255?

Это два хороших примера, потому что ни один из этих форматов не обязательно содержит прямоугольный массив значений RGB.

RAW вообще не является единственным форматом - это своего рода универсальное имя для файлов, которые содержат данные, записанные непосредственно с датчика изображения. Таким образом, файл RAW может содержать последовательность значений, которые представляют напряжения, считанные с различных сайтов датчиков. Эти сайты похожи на пиксели изображения, но они не являются пикселями RGB. Чтобы получить пиксели RGB из файла RAW, вы должны интерпретировать эти данные в контексте информации о датчике, настройках камеры на данный момент и т. Д. Другими словами, вы можете открыть файл RAW в шестнадцатеричном редакторе. и смотрите все, что хотите, но вы не найдете ни одного значения RGB.

TIFF обозначает теговый формат файла изображения , и это очень интересный формат, поскольку он может содержать множество различных представлений изображения. Один файл TIFF может содержать «одно и то же» изображение нескольких размеров, например эскиз, изображение с разрешением экрана и изображение с разрешением печати, а также может иметь цветную и полутоновую версии. Знаете ли вы, что факсимильные аппараты обычно отправляют свои данные в виде файлов TIFF? Чтобы получить пиксели RGB из файла TIFF, вам необходимо понимать не только формат TIFF, но и формат конкретного представления изображения в этом файле.

Число - это число - не должен ли быть возможен только один заданный формат?

Нет. Существует множество различных форматов изображений, потому что каждый из них обслуживает разные потребности. Сжатие JPEG с потерями отлично подходит для получения очень маленьких файлов изображений, но не подходит для изображений, которые придется редактировать несколько раз. В некоторых форматах используется чересстрочная развертка , что позволяет очень быстро считывать изображение в нескольких разных разрешениях. И так далее ... каждый формат предлагает свое сочетание преимуществ и компромиссов.

Или не должны ли два изображения одинаковой высоты и ширины иметь одинаковый размер файла?

Нет, это было бы ужасно. Если бы размер каждого файла изображения должен был быть по существу width * height * 3(при условии 24-битного цвета), то вы бы потратили много места для хранения. Большинство фотографий содержат много избыточности, то есть областей, где один и тот же цвет повторяется много раз. Чтобы сэкономить место для хранения, часто имеет смысл устранить эту избыточную информацию. Например, один из способов сделать это - кодирование длин серийили RLE. Например, если у вас есть область из 4195 последовательных пикселей, которые все белые, гораздо эффективнее кодировать это как «следующие 4195 пикселей - это все {255, 255, 255}» вместо простого хранения такого количества белых пикселей в файл. RLE фактически используется в некоторых форматах изображений, но многие форматы имеют гораздо более сложные схемы, которые экономят намного больше места, и это означает, что вы можете хранить гораздо больше изображений на жестком диске или карте памяти. Это также значительно ускоряет отправку изображения кому-либо еще.

Продолжая с этой точки зрения, что изображение в файловой системе компьютера представляет собой просто 3-канальный массив целых чисел в диапазоне от 0 до 255, какой смысл сжимать изображение в формат с потерями, такой как, например, JPG?

Дело в том, что это делает файл намного меньше. Сжатие JPEG часто уменьшает размер файла в 10 и более раз. Это означает, что вы можете разместить больше изображений на определенном устройстве хранения, вы можете копировать их быстрее, вы можете открывать их быстрее и вы можете загружать и загружать их быстрее. Хранение одного и того же изображения (или почти такого же) в гораздо меньшем пространстве использует ресурсы более эффективно и, следовательно, снижает стоимость. Подумайте об этом в широком масштабе: вполне вероятно, что очень большой процент информации, доступной в Интернете, состоит из изображений и фильмов, и без сжатия нам потребуется больше или больше центров обработки данных и потреблять гораздо больше энергии.

Скажем, алгоритм сжатия изменяет некоторые значения пикселей с 254 до 255 или как угодно. Так? Как это обеспечивает экономию размера файла или влияет на качество изображения?

Рассмотрим мой пример RLE выше. Допустим, у вас есть фотография с большой глухой стеной, поэтому большие области фотографии имеют один и тот же цвет, за исключением того, что на снимках присутствуют немного более темные пиксели, едва заметные на изображении. Эти пиксели снижают эффективность сжатия. Вместо того, чтобы просто сказать: «все следующие 500 000 пикселей - это все {243, 251, 227}», вы должны запустить кодирование длины намного большего количества меньших фрагментов, потому что время от времени вы сталкиваетесь с одним из этих немного разных пикселей. Если вы позволите алгоритму сжатия вносить небольшие изменения, возможно, изменяя только один пиксель не более чем на 1% или 2%, то вы можете получить гораздо более высокий коэффициент сжатия без заметного изменения изображения. Это компромисс: вы отказ от небольшого количества информации в исходном изображении в обмен на значительное уменьшение размера файла. Место, где вы хотите нарисовать эту линию, может измениться, поэтому форматы с потерями, такие как JPEG, позволяют пользователю выбирать, какой уровень сжатия он / она хочет.

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

Кодеки предназначены для:

• Быть без потерь против потерь
• Быстрое кодирование против уменьшения размера файла
• Асимметричное и симметричное кодирование / декодирование
• Быть совместимым с программным обеспечением
• Быть воспринимаемым практически без потерь в разных уровнях сжатия / ситуациях
• Есть функции, которые не предлагают другие кодеки, в том числе:
  • быть без роялти
  • поддержка слоев
  • поддержка альфа-канала (например, RGBA) / прозрачность
  • предложить быстрый просмотр в Интернете
  • поддержка высокой (er) битовой глубины
  • поддержка нескольких цветовых пространств (RGB / CMYK)
  • поддержка метаданных / управление версиями / ...

Некоторые из этих вещей являются взаимоисключающими. И из-за этого у нас осталось множество кодеков.

Несколько примеров

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

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

Затем JPEG 2000 пришел на смену JPEG: он основан на вейвлет-преобразовании, поэтому, хотя он предлагает примерно то же качество, что и JPEG, в настройках более высокого качества, он предлагает намного лучшее качество в настройках более низкого качества (блоки немного размыты ). Кроме того, JPEG 2000 предлагает интересующие области (высокое качество в одной области изображения, более низкое качество в другом месте) и поддержку 16 бит. (Кроме того, некоторые другие вещи.) К сожалению (?), Потому что это дороже вычислений, чем JPEG и из-за некоторых проблем с лицензированием, JPEG 2000 не так широко поддерживается, как JPEG.

PNG - это еще один широко известный формат - он без потерь и поддерживает альфа-каналы, но не предлагает поддержку цветовых пространств, не относящихся к RGB (например, CMYK). Таким образом, это формат «только онлайн».

Затем существуют форматы VFX, такие как OpenEXR . Все они вращаются вокруг качества и скорости: OpenEXR без потерь, поддерживает до 64 бит и быстро кодирует / декодирует. Он в основном используется в индустрии VFX в качестве промежуточного формата.

TIFF - еще один формат без потерь, который очень популярен среди фотографов. Для сжатия он не предлагает / ZIP / RLE / LZW / JPEG. Поддерживает до 32 бит. С возможностью выбора сжатия он довольно адаптивный, но из-за своей потери он больше в автономном формате.

HEIF - один из последних кодеков изображений. Он использует то же сжатие, что и HEVC / h.265, и поэтому, как ожидается, даст лучший коэффициент сжатия, чем JPEG. Тем не менее, поскольку он является довольно новым и потому что на него распространяются патенты, он не так широко поддерживается, как любой из вышеперечисленных.

Изображения RAW ^{См. Также} не настоящие изображения, на самом деле: они являются скорее контейнером для необработанных (отсюда и название) данных считывания с датчика. Только с программным обеспечением, которое знает, как интерпретировать данные, возможно получить изображение. Вот почему RAW-конвертеры, такие как Lightroom / Capture One / DarkTable / ..., нуждаются в обновлениях для поддержки новых камер, которые используют уже указанные контейнеры, такие как * .CR2 для Canon. Это также причина, почему 14-битный RAW предлагает больше возможностей редактирования, чем 32-битный TIFF, который вы экспортировали из того же RAW.

Intermisision: без потерь против потерь

Я до сих пор не уверен, что вы на самом деле спрашиваете, поэтому я подумал, что не мешало бы добавить небольшое объяснение о потерях против потерь.

Сжатие без потерь работает путем кодирования длин серий (RLE) / кодирования Хаффмана / ... для сжатия данных. Сами данные не изменяются, но сохраняются в меньшем пакете. Например, возьмем RLE: скажем, у нас есть битовый поток R-канала (от пикселя 0,0к пикселю 0,11) 255,255,255,255,255,215,215,235,100,000,000,000- RLE закодировал бы это как 52552215123511003000- это намного меньше, и так как мы знаем, что он сохраняется в группах из 4 цифр и что первая цифра - это счетчик, а последние три цифры - это значение, затем мы можем восстановить его полностью 255,255,255,255,255,215,215,235,100,000,000,000.

С другой стороны, сжатие с потерями пытается сжать даже больше, чем без потерь. Чтобы сделать это, кодеки с потерями обычно пытаются удалить вещи, которые наше восприятие не получает. Возьмем, к примеру, YUV( YCbCr, на самом деле) модель JPEG (и почти все видео кодеков) использует: Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Человек не может определить разницу между 4:2:0(каждый пиксель имеет значение яркости, но цвета сохраняются в блоках 2x2 поочередно) и 4:4:4(каждый пиксель имеет яркость и оба цветовых канала) кодированного изображения. Это связано с физиологией нашего глаза : мы не можем видеть различия в цвете, а также мы видим различия в яркости.

Это работает хорошо в большинстве случаев, но сравните его с файлом MP3: почти никто не может различить разницу между 192 кбит / с и 320 кбит / с, но ниже 64 кбит / с, и все становится ужасно быстро. Кроме того, перекодирование будет дополнительно снижать качество, так как могут появиться нежелательные артефакты (например, в JPEG небольшие блоки из кодировок высокого качества будут рассматриваться как детали изображения в последующих кодировках).

Нижняя линия

Если вам не нужны форматы изображений или их функции, то все будет в порядке. При достаточно высоких настройках качества возможно и ожидается, что вы даже не увидите разницу между ними.

Однако, если вам нужна какая-то конкретная функция, возможно, (и почти наверняка) будет кодек, на который это распространяется.

Если в основе, фотографии - только 3 канала значений пикселей [0, 255] X RBG

Это серьезно нарушенное предположение, и остальная часть вашего вопроса просто не отвечает, не отрываясь от него.

Я имею в виду, что делает RAW отличным от TIFF - не ограничены ли они значениями от 0 до 255?

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

Изображение «Camera Raw» хранит необработанные данные, когда они выходят из датчика. Большинство современных датчиков камер имеют АЦП с более чем 8 битами, но они также собирают данные об интенсивности только для одного цветового компонента в каждом месте. Объектив может искажать геометрию, значения интенсивности от АЦП могут не очень хорошо отражать восприятие интенсивности людьми, цветовые компоненты могут не соответствовать точно тем, которые используются вашим монитором и так далее.

Сложный процесс отображения, включающий интерполяцию, необходим для того, чтобы превратить необработанные данные датчика в RGB-изображение хорошего качества, и нет единственно правильного способа сделать это. Кроме того, из-за необходимости интерполировать цветовые компоненты изображение RGB может оказаться больше, чем необработанные данные.

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

Tiff - это сложный формат файлов, в котором можно хранить изображения в различных форматах с различными метаданными. Однако на практике он обычно используется для хранения несжатых или сжатых без потерь изображений RGB или CMYK.

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

Кроме того, с цифровой точки зрения, что отличает 16-битные изображения от 32-битных?

К сожалению, «n бит» может означать две разные вещи. Это может означать, что все цветовые компоненты сведены в битовое число (например, 5 бит для красного, 5 бит для синего и 6 бит для зеленого для 16 бит или 8 бит красного, 8 бит зеленого, 8 бит синего и 8 бит альфа для 32 бит) или at может означать, что у каждого компонента цвета есть n битов информации в каждом местоположении пикселя.

Продолжая с этой точки зрения, что изображение в файловой системе компьютера представляет собой просто 3-канальный массив целых чисел от 0 до 255

Опять же, эта точка зрения просто неверна.

Файл представляет собой последовательность байтов, но эти байты почти никогда не являются «просто 3-канальным массивом целых чисел от 0 до 255»

Вы можете сохранить изображение, как это. Некоторые инструменты даже поддерживают чтение и запись таких файлов, но проблема в том, что вам нужно знать о файле, прежде чем вы сможете его прочитать. Предположим, у вас был такой файл размером 3000 байт, у вас есть 1000 24-битных пикселей RGB? 3000 8 битных оттенков серого? 3000 8 битных пикселей с поддона? В каком порядке находятся цветовые компоненты? какая форма изображения? цветовые компоненты в порядке RGB или BGR? Если вы не знаете ответы на эти вопросы, вы не можете осмысленно прочитать такой файл.

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

Какой смысл сжимать изображение в формат с потерями, например, JPG? Скажем, алгоритм сжатия изменяет некоторые значения пикселей с 254 до 255 или как угодно. Так? Как это обеспечивает экономию размера файла или влияет на качество изображения?

Алгоритмы сжатия не просто «изменяют значения», они кодируют информацию совершенно другим способом, например, JPEG можно грубо описать как

• Конвертировать данные из RGB в YUV
• (опционально) уменьшить разрешение каналов цветности в 2 раза в одном или обоих измерениях
• Разделите данные для каждого канала на блоки 8x8.
• Преобразовать блоки в частотную область, используя дискретное косинусное преобразование
• Количественная оценка результатов, сохранение низкочастотной информации при одновременном снижении точности высокочастотной информации.
• Кодировать полученные числа как последовательность байтов, используя схему кодирования переменной длины (кодирование Хаффмана или арифметическое кодирование)
• Сохраните эти байты в файле вместе с соответствующими заголовками.

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

• Преобразуйте данные в один из поддерживаемых форматов (например, биты для красного, зеленого и синего в этом порядке)
• Для каждой строки изображения, выполняющей процессы «фильтрации», есть несколько вариантов фильтрации (включая фильтрацию вообще), но общая цель состоит в том, чтобы взять информацию, относящуюся к изображению, которую пиксель может быть похож на своих соседей, и закодировать это так, что "сдувать" может иметь дело с.
• Сжатие отфильтрованных данных с использованием алгоритма сжатия общего назначения "deflate".
• Сохраните эти байты в файле вместе с соответствующими заголовками.

Есть несколько причин, почему это предположение неверно, и все они сводятся к одному:

Какой масштаб вы на самом деле используете?

И это может быть разбито немного дальше:

Что такое 255?

«Цвет» не является свойством физической вселенной. Это ощущение, которое возникает в уме. И это включает в себя такие вещи, как «синий», «зеленый» и «красный». Шкала от 0, означающая «вообще нет синего» до 255, означающая «все синее!» на самом деле не может быть 255, представляющих платонический идеал синего цвета , потому что ... в реальном мире нет такой совершенной вещи. Итак, это значит:

• самая голубая вещь, которую вы можете сделать на устройстве перед вами?
• насколько близко к идеальному сочетанию чистый синий с точки зрения системы человеческого зрения, даже если большинство экранов и комбинаций принтер / чернила / бумага не могут это представить?
• довольно хороший синий, который может быть разумно представлен на самых разных устройствах?
• синий, который находится вне диапазона человеческого зрения, но который позволяет вашему RGB-тройному покрытию охватывать большинство цветов, которые находятся в диапазоне?

Звук надуманный? Нет! Это на самом деле реальные примеры. Проверьте эти представления каждого выбора. Изогнутая область представляет собой 2D-срез цветового пространства человеческого зрения, и треугольник показывает область, которая может быть представлена ​​с определенным выбором красного, зеленого или синего цветов.

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

Теперь вот пространство Adobe RGB. Обратите внимание, насколько это больше, чем то, что может показать мой экран!

Итак, вот sRGB - стандарт defacto и пространство по умолчанию, обычно предполагаемое, когда ничего не указано. Это должно быть "достаточно хорошо" в большинстве ситуаций.

И, наконец, ProPhoto RGB, в котором в качестве основных цветов используются воображаемые цвета , чтобы сделать треугольник достаточно большим, чтобы соответствовать почти всему человеческому зрению.

Теперь добавьте цвет самого света и хроматическую адаптацию - способность системы человеческого зрения приспособить восприятие к окружающей среде. На самом деле, это не просто способность: это происходит независимо от того, хотите вы этого или нет . Означает ли «чистый синий», что эта штука выглядит такой же голубой, какой она может быть при свете ламп накаливания? Какой должна быть ценность, если мы вместо этого фотографируем на солнце?

Таким образом, «255» может означать много разных вещей.

Что такое 0?

Это довольно просто - каким черным нужно 0, чтобы быть? Это черный черный? Если это так, но все фактические оттенки в вашей сцене намного менее экстремальны , действительно ли вы хотите «потратить» кучу потенциальных значений для динамического диапазона, которого нет в вашей сцене - и который, как цвет, может Вы даже не представлены каким-либо устройством или принтером, к которому у вас есть доступ?

Какая у тебя кривая?

Итак, когда у вас есть конечные точки, как вы переходите от одного к другому? Человеческое восприятие яркости определенно нелинейно . В вашей шкале 0-255, должно ли 100 быть в два раза ярче, чем 50, или это должен быть какой-то больший фактор? Должна ли разница в восприятии, скажем, между 3 и 4 быть такой же, как между 203 и 204?

Если вы решите использовать систему хранения журналов, следует ли оптимизировать эту кривую для соответствия человеческому зрению, или для оптимизации данных, или для чего-то еще?

Есть много возможностей для разных нужд.

На сжатие

Ты спрашиваешь.

Скажем, алгоритм сжатия изменяет некоторые значения пикселей с 254 до 255 или как угодно. Так? Как это обеспечивает экономию размера файла или влияет на качество изображения?

Современные алгоритмы сжатия более сложны, чем это, но это хороший пример. Я собираюсь использовать шестнадцатеричное FFдля представления 255 и FEдля представления 254, и представьте, что мы используем кодирование длин серий как форму сжатия. А для простоты, давайте предположим, что черно-белый цвет вместо цветного. При этом, если у нас есть ряд данных, который выглядит следующим образом:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

мы можем сжать это до очень простого

16×FF 

... что довольно очевидная экономия. В основном мы можем хранить 16 байтов в двух (один для подсчета, два для данных). Но скажем, у нас есть:

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

Теперь кодирование длин серий дает нам:

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

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

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

По битовой глубине

Кроме того, с цифровой точки зрения, что отличает 16-битные изображения от 32-битных? Опять же, изображение это просто массив с целочисленными значениями от 0 до 255.

Итак ..... массив целочисленных значений от 0 до 255 - это восьмибитный массив. (2⁸ = 256.) С тремя каналами это 24-битное изображение; некоторые форматы также имеют канал прозрачности («альфа») для 32 бит. Можно также использовать более высокое значение на канал, что обычно имеет в виду, когда мы говорим «16-битная глубина». Это означает, что массив идет от 0-65535 (2¹⁶ = 65536), а не 0-255. Обычно в такой схеме это в основном просто множитель, где самое высокое значение представляет одну и ту же вещь в каждой шкале, но более высокая битовая глубина дает больше возможных нюансов. (Подробнее об этом см. В этом ответе .) Существуют также некоторые специализированные форматы файлов, которые используют 64-разрядные числа с плавающей запятой (!) Вместо целых чисел для значений или другие типы данных в зависимости от варианта использования, но основная концепция та же самая ,

Нет, изображение - это не просто значения RGB в диапазоне 0-255. Даже если вы игнорируете форматы хранения, есть много способов описать цвет. Вот некоторые примеры:

• Красные, зеленые и синие компоненты (RGB)
• Голубой, пурпурный, желтый и черный компоненты (CMYK)
• Оттенок, насыщенность и яркость / значение (HSL / HSV)
• Количество света, попадающего на группу датчиков в камере
• Количество света и его направление при попадании на датчики (в световой камере )

Первые два наиболее часто используются для отображения на мониторах и для печати соответственно.

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

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

Однако форматы файлов разные. По сути, существует несколько различных способов представления одного и того же изображения, как упоминалось выше: bmp, png, jpg и т. Д. Конечно, после их декодирования две кодированные версии без потерь одного и того же изображения приведут к одинаковым матрицам.
Думайте об этом как о файле .txt, который вы сжали с помощью zip. С добавленной странностью, что кодирование без потерь вернуло бы текст, который не совпадает с оригиналом, но действительно близок, почти как тупая версия текста.

Следуя аналогии с текстом, скажем, у вас есть тот же текст, сохраненный как .txt, .docx, .pdf и т. Д. Почему не все файлы одинаковы, если содержимое одинаковое? (Хорошо, txt не имеет форматирования, но другие имеют).

Кстати, посмотрите, чем кодировка Netpbm действительно отличается от JPEG .

Насколько я могу судить, для форматов RAW и TIFF ответ (как уже говорили другие) состоит в том, что они на самом деле не всегда используют одни и те же цветовые пространства (например, файлы RAW могут использовать больше битов на пиксель, поэтому могут хранить более точную информацию о цвете) ,

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

Хорошим примером причины этого являются различия в сжатии между файлом PNG и файлом TIFF.

Файлы PNG используют один конкретный алгоритм сжатия. Это означает, что изображение не будет просто сохранено как большой список чисел для каждого пикселя. Упрощенный пример: он может хранить что-то вроде «в этом блоке пикселей 10x10 все пиксели имеют цвет XYZ». Затем вместо того, чтобы хранить эту информацию 100 раз, она сохраняет ее один раз, плюс немного информации о регионе, к которому относится эта информация.

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

Файлы PNG всегда используют один и тот же алгоритм сжатия, поэтому программное обеспечение может легко поддерживать все действительные файлы PNG. С другой стороны, некоторые изображения имеют структуру, которая не поддается алгоритму сжатия PNG, поэтому некоторые из ваших файлов PNG могут оказаться довольно большими.

Файлы TIFF, с другой стороны, поддерживают множество различных алгоритмов сжатия. Фактически, он может даже хранить разные части изображения, сжатые по-разному. И он поддерживает «расширения», так что вы можете сжимать изображения, используя собственные способы. Поэтому, возможно, верхняя половина вашего изображения будет сжата с использованием метода, аналогичного PNG, но это не очень хорошо сожмет нижнюю половину, поэтому нижняя половина будет сжата другим методом.

Таким образом, файлы TIFF более гибкие - вы можете хранить тот же массив чисел, используя меньше байтов. Но программное обеспечение, необходимое для декодирования изображения, будет более сложным и может не работать согласованно с каждым файлом TIFF, который вы к нему добавляете, например, вы можете сохранить файл TIFF в одном программном обеспечении и не сможете открыть его с помощью другого программного обеспечения, хотя оно до сих пор работает в оригинале.

Итак, вы спрашиваете

Но я не спрашиваю ни о чем, кроме основного 3-канального изображения RBC. Все, что я знаю, это то, что, если кто-то вручит мне один из них, у меня теперь есть массив чисел. У меня нет причин знать, почему один массив чисел может отличаться от другого массива чисел от 0 до 255.

Чтобы передать его вам, кто-то должен был знать, как хранится изображение и как его преобразовать в массив чисел. (Или, возможно, какое-то программное обеспечение делает этот перевод для вас без вашего ведома).

Вы можете попробовать сохранить изображение в формате PNG, а затем снова в формате TIFF или GIF и посмотреть на него в шестнадцатеричном средстве просмотра, чтобы увидеть, как каждый из них представляет один и тот же массив чисел по-разному. Или прочтите подробности о том, как файлы PNG и TIFF представлены внутри, чтобы дать вам представление о том, что необходимо встроить в программное обеспечение для различного считывания идентичных массивов чисел.

Bitmaps

Растровое изображение (BMP) - это, по сути, то, что вы описываете, массив чисел, представляющих цвета пикселей. Например, что-то вроде

1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1

Сжатие без потерь

Теперь давайте определим схему сжатия. В нашей схеме сжатия у нас будет массив пар чисел. Например

3, 1, 1, 0, 7, 1

Теперь, первое, что я хочу отметить, это то, что эта схема сжатия представляет те же пиксели, что и первый массив. Первый массив имеет три единицы, за которыми следует один 0, а затем семь единиц. И это то, что мы представляем здесь. Этот формат короче, поскольку представляет несколько пикселей с двумя числами. Растровый формат должен использовать один номер для каждого пикселя.

Очевидно, что это несколько упрощенный вид изображения (например, всего одна строка) и схема сжатия. Но, надеюсь, это позволит вам увидеть, как схема сжатия меняет формат изображения. Вот как GIF относится к BMP. GIF использует схему сжатия под названием Lempel-Ziv-Welch вместо упрощенной.

Мы описали здесь схему сжатия без потерь. Проблема со схемами сжатия без потерь состоит в том, что для некоторых входов закодированная форма может быть длиннее, чем оригинал. Например, для

1, 0, 1, 0, 1

Кодировка

1, 1, 1, 0, 1, 1, 1, 0, 1, 1

Ну, это было бесполезно. Мы сделали вклад в два раза дольше.

Еще одно сжатие без потерь

Теперь давайте рассмотрим другую схему сжатия. В этом мы представим изображение в виде наложенных кругов. Для каждого круга мы определим центр, радиус и цвет.

Нашим первым растровым изображением станет

5, 5, 1, 3, 0, 0

Это та же длина, что и у нашего первого метода сжатия.

И наш второй может быть либо

2, 2, 1, 2, 1, 0, 2, 0, 1

Это три круга с центром в среднем элементе (который в подсчете компьютеров является номером 2, так как компьютеры начинают считать в 0). Один круг имеет радиус 2 и цвет 1. Затем мы добавляем круг цвета 0 и радиуса 1. Наконец, у нас есть круг цвета 1 и радиуса 0. На этапах это будет

1, 1, 1, 1, 1
1, 0, 0, 0, 1
1, 0, 1, 0, 1

Или же

2, 2, 1, 1, 0, 0, 3, 0, 0

Это тот же начальный круг, но покрытый двумя точечными кругами. По шагам было бы

1, 1, 1, 1, 1
1, 0, 1, 1, 1
1, 0, 1, 0, 1

Оба они на одну короче первой закодированной версии, но все же длиннее оригинальной.

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

Сжатие с потерями

У нас также есть концепция схем сжатия с потерями. Эти схемы сжатия без потерь могут быть возвращены в исходный массив растровых изображений. Схемы сжатия с потерями могут быть необратимыми.

Давайте рассмотрим версию нашего круга с потерями. В этом мы будем использовать простое правило. Мы не будем хранить круги с радиусом меньше 1. Поэтому в наших последних двух кодировках вместо этого

2, 2, 1, 2, 1, 0

а также

2, 2, 1

которые преобразованы в пиксели снова

1, 0, 0, 0, 1

а также

1, 1, 1, 1, 1

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

Мы описываем изображения с более строгими правилами как более низкого качества.

Это представление изображений в виде наложенных коллекций круглых форм аналогично тому, как работает формат Joint Photographic Experts Group или JPEG . Его формы - это эллипсы, а не круги, но идея похожа. Вместо нашего упрощенного метода он использует дискретное косинусное преобразование для кодирования изображений.

В отличие от GIF, JPEG на самом деле представляет собой другой способ представления изображения. GIF все еще пикселей. Они просто хранятся по-другому. JPEG это формы. Чтобы просмотреть JPEG, мы затем конвертируем фигуры в пиксели, потому что так работают экраны. Теоретически мы могли бы разработать экран, который бы не работал таким образом. Вместо пикселей он может создавать фигуры, чтобы лучше соответствовать формату JPEG. Конечно, этот экран не сможет отображать растровые изображения. Чтобы отобразить BMP или GIF, нам нужно конвертировать в JPEG.

Если вы конвертируете стандартный GIF, скажем, 300x300 пикселей, преобразуете его в JPEG и проверяете качество вниз, базовые формы, которые он использует, должны быть видны. Многие JPEG избегают этих артефактов, начиная с изображения с гораздо более высоким разрешением.

JPEG хорошо масштабируется, потому что это фигуры, а не пиксели. Поэтому, если вы начнете с изображения 8000x8000, преобразуете его в JPEG и отобразите его как изображение 300x300, большая часть потерянных деталей в любом случае была бы потеряна. Если сначала преобразовать растровое изображение 8000x8000 в растровое изображение 300x300, а затем в JPEG, результаты часто будут иметь более низкое качество.

MPEG

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

Последовательность обычно не такая длинная, скажем, пять кадров. Но это помогает сделать поток меньше, чем он был бы.

Упрощения

Я много игнорировал. Мои изображения имеют только два цвета (1 бит), а не 256 8-битного изображения и, конечно, не 4 294 967 296 32-битного изображения. Обратите внимание, что даже для 8-битных изображений вы часто можете выбирать разные палитры для изображения. Таким образом, две 8-битные битовые карты с одинаковыми последовательностями могут представлять изображения, которые выглядят по-разному (одинаковой формы, но разных цветов)

Мои изображения одиночные, а не двухмерные. Большинство изображений будут иметь определенный размер строки, делая массивы двумерными.

Я вообще не пытался представлять фактические кодировки. Они намного сложнее, чем те, которые я использовал. Я сделал это, потому что хотел описать кодировки в этом посте. Я не уверен, что мог бы объяснить Лемпеля-Зива гораздо меньше, чем более сложное уточнение Лемпеля-Зива-Уэлча в одном ответе. И я не понимаю преобразований Фурье достаточно хорошо, чтобы объяснить их подробно.

Это очень упрощенная версия фактической обработки изображений. Тем не менее, я чувствую, что в дидактических целях это легче понять, чем более сложную реальность, но при этом затрагивать основные моменты.

Допустим, это правда, что каждый пиксель состоял всего из трех чисел (красного, зеленого и синего), каждое из которых находилось в диапазоне 0-255. Другие ответчики начали (правильно), оспаривая это предположение, но для простоты давайте просто скажем, что это правда.

Я помню (но, к сожалению, не могу найти в Интернете) карикатуру из учебника по лингвистике: два древнеегипетских резчика по камню сидят измученными у основания массивной стены, на которой они вырезали очень большое количество марширующих фигур. Один говорит другому: «Разумеется, должен быть более простой способ написать:« У фараона было 100 000 солдат? ». Помните об этой идее.

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

0 0 0    0 0 0     0 0 0   ....

Так сколько места для хранения это потребует? Каждое значение является байтом. Три байта на пиксель, 1800 пикселей на строку, так что уже 5400 байтов на строку. Таким образом, изображение размером 1800 x 1200 должно занимать в 1200 раз больше, что превышает 6 мегабайт. Итак, теперь давайте поищем в Google изображения и загрузим пару изображений размером 1800x1200 - скажем, одно .pngизображение и одно .jpgизображение. Посмотрите на размер файла: это 6 МБ? Нет, обычно это намного меньше. И это желательно, конечно, все это экономит место и сокращает время загрузки ....

Итак, что происходит? Ключевым моментом является то, что, даже если у вас есть столько чисел для хранения, есть разные способы представленияэти цифры в файле. Вот пример более эффективного представления прямо здесь, в моем ответе, два параграфа назад. Я написал слова «1800 черных пикселей». Это 17 символов, поэтому не нужно занимать больше 17 байт, но в то же время он точно описывает ту же информацию, для которой, как мы думали, нам нужно 5400 байт. И вы, безусловно, могли бы сделать лучше, чем 17 байт (и также сэкономить много усилий в реализации кодирования / декодирования), если бы вы не использовали английский язык для кодирования этой информации, а скорее более специализированный язык. Итак, теперь мы уже представили более одного формата сжатия изображений: тот, который использует английские слова, и тот, который более эффективен, чем этот. Видишь, куда это идет?

Хорошо, вы говорите, это работает, если целая куча смежных пикселей имеет один и тот же цвет. Но что если они этого не сделают? Конечно, это зависит от содержимого конкретного изображения: чем больше избыточности , тем проще сжать информацию. Избыточность означает, что части изображения могут быть предсказаны довольно хорошо, если вы уже знаете другие части. Сжатие означает только запись минимума, необходимого для восстановления информации. Не каждое возможное изображение имеет избыточность, но любое реальное изображение, которое имеет значение для человеческого глаза и мозга, несмотря на то, что оно является более сложным, чем мой чисто черный пример, все равно будет иметь тенденцию иметь довольно много избыточности. И есть много разных способов сжатия. Некоторые методы сжатия без потерьЭто означает, что информация может быть реконструирована так, чтобы она была математически идентична оригиналу, как в моем примере с черным рядом пикселей. В большинстве .pngфайлов используется метод сжатия без потерь. Некоторые методы с потерями : реконструкция не идеальна, но ошибки скрыты таким образом, что человеческий глаз и мозг их едва замечают. Большинство .jpgфайлов с потерями.

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

Несколько комментаторов выше сделали разумные предположения относительно того, где могло возникнуть ваше заблуждение. В вашем вопросе вы, кажется, думаете, что сжатие просто немного меняет значения пикселей (и, конечно, методы сжатия с потерями делают это местами, но только как нежелательный побочный эффект), не изменяя структуру информации. Когда вы открываете файл и просматриваете содержимое изображения (например, как массив чисел в Matlab или как изображение на экране в Photoshop), вы смотрите не на сжатый контент файла, а на реконструкцию, который имеет тот же макет, что и оригинал (это не будет большой реконструкцией, если он не воссоздает макет правильно). Процедура открытия файла распаковала информацию из файла в полное несжатое представление в памяти. Если вы сравните две несжатые реконструкции, то на самом деле нечего отличать два разных формата изображения, из которых они получены (за исключением ошибок восстановления, если они есть).

Да, но как вы получите эти 1 и 0 очень разные.

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

Чтобы усложнить дело, есть разные каналы. CMYK, RGB, B & W, просто назвать несколько. Мы не будем вдаваться в это. Существуют также различные этапы, такие как захват, хранение и отображение. Мы будем вдаваться в подробности, хотя пример должен продемонстрировать, что он не является точным. Если вам нужны точные примеры, вам нужно найти тонну технической документации.

Итак, в нашем примере мы будем смотреть на черно-белое изображение.

00067000
00067000
00567800
04056090
40056009

Цифры показывают, насколько сильны «черные». Вот как камера захватила изображение. Это приличная камера, поэтому она также хранит изображение.

Теперь он хранит изображение на компьютере, но занимает много места, поэтому мы собираемся сжать его. Помимо того, что мы делаем это, мы также знаем, что большинство людей не могут обнаружить разницу в 1 уровень черного, поэтому мы сгладим это.

302730
302730
204820
*04056090
1420262019

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

Теперь предположим, что мы хотим напечатать это на принтере. Принтер печатает только один уровень черного, поэтому компьютер переводит сохраненное сжатое изображение в принтер.

00011000
00011000
00111100
01011010
10011001

Это распечатывает разумно выглядящее изображение, но вы можете видеть, даже в этом примере, очень низкое качество. Но эй, это ошибка принтера.

Наконец, вы идете, чтобы напечатать изображение на хорошем принтере с 10 уровнями черного. Так же, как ваша камера. Таким образом, вы используете сохраненное и сжатое изображение.

00077000
00077000
00888800
04056090
40066009

Как видите, изображение «лучше», но немного изменено по сравнению с оригиналом.

В любой момент вы правы, что это всего лишь сила канала. И если не считать сжатое изображение, которое нужно распаковать в любом случае, оно остается верным этому.

Однако сжатый формат теряет много «информации». Важна ли эта информация? Ну, это зависит от художника и зрителей. Есть несколько компромиссов между экономией места, временем обработки, качеством конечного / сохраненного изображения и необходимостью. Я сканирую большинство своих документов одним черным цветом, потому что это все, что мне нужно. Тем не менее, мои свадебные фотографии в формате HUGE RAW, потому что я никогда не знаю, когда я захочу их перепечатать. Тем не менее, когда я передаю их (фотографии) в цифровую фоторамку, я конвертирую их в JPEG для экономии места. Разные каналы, разные фильтры и разные методы сжатия - это ряд компромиссов. Это как цифровая версия треугольника принтеров.

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

В своей основной форме изображение (ЛЮБОЕ изображение), отображаемое на определенном экране, действительно является просто идентичным массивом чисел. Все эти числа могут быть 0-255 или 0-65535 или 0-что-32-бит-это-я-забыл-гуглить-это.

НО так много способов ХРАНИТЬ и ТРАНСПОРТИРОВАТЬ эту информацию, многие из них - просто продукты технологий, утерянные в глубине веков.

Кроме того, одна деталь, которую я не видел ни у кого из упомянутых здесь педантов, заключается в том, что данные датчика изображения RAW, полученные с цифровой камеры, вполне могут быть RGrGbB по схеме Байера или что-то такое, что нужно обработать хотя бы немного, чтобы любой смысл для человеческого глаза Mk.1. Скорее всего, вы никогда не получите это даже в формате RAW, сохраненном вашей DSLR, потому что это бесполезно, пока вы не преобразуете его в красивую сетку пикселей RGB или YUV, будь то глубина 8, 16, 32 или одиннадцать миллиардов.

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

Некоторое легкое чтение перед сном см. В разделе «формат изображения кадра»: http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf.

В любом случае ... вернемся к исходному вопросу о разнице между несжатыми файлами изображений, такими как TIFF / RAW / IFF / PNG.

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

Таким образом, RAW, как обсуждали другие в этой теме, является общим термином для нескольких разных вещей, сохраняемых различными цифровыми камерами, используя любую загрузку данных, которые, по мнению производителя камеры, были важны, основываясь на функциях, которые их камера имеет или может иметь в будущем. Таким образом, хотя бит данных основного изображения может быть очень похожим, «упаковка» вокруг него, которая описывает изображение и все настройки камеры и т. Д., Поэтому один файл не будет понят другим производителем.

Традиционно это делается для того, чтобы вы (или, что более вероятно, профессиональные фотографы) могли использовать свое проприетарное (а иногда и дорогое) программное обеспечение для обработки этих изображений более высокого качества, иначе вы можете начать использовать дорогое программное обеспечение других людей. Кроме того, возможно, Adobe Photoshop хочет поддержать их формат, поэтому, возможно, они могут взимать с Adobe $$$ за эту информацию, чтобы более профессиональные фотографы покупали PS и, возможно, покупали эту марку камеры, потому что PS поддерживает ее сейчас. Уютная!

RAW также хранит информацию о том, как превратить этот конкретный пакет данных обратно в изображение, видимое человеком, просто добавив все необходимые настройки, чтобы изображение выглядело «правильно».

TIFF был ранним форматом изображений, который, помимо прочего, использовался для отправки графических данных на принтеры (когда принтеры с поддержкой графики стали доступны по цене). Это было довольно просто, так легко обрабатывать на маленьком дешевом микропроцессоре внутри принтера.

IFF (да, это так) был похожим форматом, используемым на компьютерах Amiga, я полагаю, он был изобретен ими или одним из популярных пакетов краски. Но я использую его здесь в качестве примера, потому что, хотя он хранит данные изображения битовой карты, как и другие, он поддерживает несжатые данные или данные RLE, переменную глубину цвета от 1-битного моно до 8-битного 256-цветного (но с 3x8-битная палитра RGB на выбор для каждого из цветов), а также специальные режимы, называемые полутоновыми и удерживающими-и-модифицированными, позволяющие получать намного больше цветов, чем другие машины той эпохи. Да, и он также поддерживал анимацию (например, GIF), поэтому файл IFF может хранить любое количество кадров с переменными задержками между кадрами, и каждый кадр может иметь свою собственную палитру. Таким образом, IFF будет включать дополнительные данные для обработки всего этого по сравнению, скажем, с файлом TIFF.

PNG - это другой формат изображений без потерь, в котором снова хранятся растровые данные, но поддерживаются некоторые прикольные функции, такие как 8-битный альфа-канал для переменной прозрачности изображения (полезно на веб-страницах), поэтому снова «полезная нагрузка» данных изображения может выглядеть очень похожей но оболочка вокруг него другая, и полезная нагрузка может содержать RGBA, а не просто данные RGB на пиксель.

Итак, это 4 различных формата файлов изображений, описанных - вы можете сохранить образец полноцветного HD-изображения кошки в любом из 4-х, и он будет выглядеть одинаково, каждый пиксель на вашем экране будет иметь значение ТОЧНО ЖЕ, и НЕТ разница в качестве между 4 ... но эти 4 файла, вероятно, будут различаться по размеру, разметке и будут проще или сложнее для загрузки и обработки программного обеспечения.

Надеюсь, это поможет!

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

Пиксели в изображении не сохраняются в байтах - если только изображение не является монохромным, то есть только черно-белым.

Если у вас есть изображение истинного цвета, то каждый пиксель представлен 16 битами или 2 байтами - как одно значение. Если у вас есть 32-битное изображение, то для каждого пикселя требуется 32 бита или 4 байта, опять же как одно значение.

Интересно, что графические и звуковые файлы и все другие типы данных в компьютере сводятся к битам 1 и 0. Только интерпретируя их в кусках правильного размера, значение извлекается из них.

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

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

Вот почему у нас есть 16-битные и 32-битные изображения, а также 16-битные и 24-битные аудиофайлы. Чем больше бит вы используете для пикселя или звукового образца, тем более выразительным вы можете быть - 16 бит могут определять только 64 000 уникальных цветов, а 32 бит могут определять более 4 миллионов уникальных цветов. Монохромное изображение использует 1 бит на пиксель - оно либо включено, либо выключено.

С аудиофайлами, чем больше битов вы используете на семпл, тем более детальной и детальной может быть запись.

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

Даже без упоминания цветовых доменов, сжатия, размеров битов и формата канала, существует набор форматов файлов, которые совершенно не похожи на пиксельные карты. И все же векторные форматы также намного «лучше» отображают определенные типы изображений, которые обычно создаются компьютером, а не камерой.

На этот вопрос был дан довольно подробный ответ. Однако, несмотря на то, что в ответах представлено много теории, я чувствую, что есть некоторые базовые предметы, обычно связанные с компьютерным программированием, которые требуют большего разъяснения. Я должен заявить, что я инженер-программист. После того, как я прочитал вопрос, я понял, что есть совершенно неправильное понимание основных типов данных программирования, которые породили этот вопрос.

Первый вопрос здесь:

Кроме того, с цифровой точки зрения, что отличает 16-битные изображения от 32-битных? Опять же, изображение - это просто массив с целочисленными значениями от 0 до 255.

Как представлено ранее: нет, это не так. Изображение - это не просто массив целочисленных значений от 0 до 255. На самом деле это может быть одиночный или многомерный массив значений от 0 до 65535, массив от 0 до 4294967295 или даже массив битов (бит может содержать значения 0 или 1, вот и все), который преобразуется программным обеспечением, способным читать файлы изображений в целые числа в соответствии с различными правилами кодирования.

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

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

• БИТ - удерживая 0 или 1
• UINT8 - 8-битное целое число без знака - они могут содержать значения в интервале от [0 до 255].
• INT8 - 8-битное целое число со знаком - они могут содержать значения в интервале от [-126 до 127].
• UINT16 - 16-битное целое число без знака - они могут содержать значения в интервале от [0 до 65535].
• INT16 - 16-битное целое число без знака - они могут содержать значения в интервале от [−32768 до 32767].
• UINT32 - 32-разрядное целое число без знака - они могут содержать значения в интервале от [0 до 4294967295].
• INT32 - 32-разрядное целое число без знака - они могут содержать значения в интервале [от –2147483648 до 2147483647].
• ИЛИ сочетание всех этих типов данных в более сложном формате. Например, UINT16 (16 бит), содержащий 3 разных значения, первый 4 бит, содержащий значения от 0 до 127, следующий бит, 0 или 1, и так далее.

Более того, программистам приходится иметь дело с чтением или записью целочисленного типа данных из файлов. ПорядокПорядковый номер относится к последовательному порядку, в котором байты (UINT8 из нашей таблицы) располагаются в большие числовые значения при хранении в памяти или файлах. Порядковый номер представляет интерес в информатике, потому что два конфликтующих и несовместимых формата широко используются: значения могут быть представлены в формате с прямым порядком байтов или с прямым порядком байтов, в зависимости от того, упорядочены ли биты, байты или другие компоненты с большого конца (наиболее значимый) немного) или маленький конец (наименее значимый бит). Проще говоря, вы можете сохранить значение, например, 0000000011011111 или ... как 1101111100000000, в зависимости от выбранного порядка байтов. И вы можете выбрать любой заказ, который соответствует вашим целям. Нет других правил, которые вы устанавливаете при разработке формата файла изображения.

Обратите внимание, что в компьютерном программировании целые числа используют больше или меньше места, в зависимости от значения. Как будто вам нужно больше бумаги, чтобы написать 255255255, вам нужно больше битов, чтобы написать большее значение. Затем, когда вы захотите прочитать значение, вы должны точно знать правила, которые вы создали, когда писали его. В противном случае вы не сможете понять, как читать только массив с целочисленными значениями от 0 до 255, потому что вы просто не знаете, где хранятся эти числа и как хранятся эти числа, учитывая, что у вас есть такой выбор (BIT, UINT8 , UINT16, UINT32 или комбинация всех этих типов данных компьютера). И не забывай, Endianness. Если вы не знаете, что данные были записаны с использованием порядка с прямым или прямым порядком байтов, вы не сможете прочитать правильное значение.

Из-за этого изображения НИКОГДА не являются просто массивом с целочисленными значениями от 0 до 255. Некоторые из них являются массивами UINT16 (16-битные изображения), другие являются массивами UINT32 (32-битные изображения) или другие являются массивами UINT8 (8-битные изображения). Некоторые очень креативные программисты могут даже использовать подписанные типы, которые используют вас для массивов INT8, что означает массив значений от -126 до 127.

На самом деле, когда вы читаете файл изображения, одним из первых данных, с которыми вы сталкиваетесь, обычно являются биты, представляющие ширину и высоту изображения. И это не просто 0-255 значений. Это также некоторые типы данных, выбранные программистом. Некоторые программисты подумают, что 16 битов достаточно для сохранения максимальной ширины изображения 65535 пикселей, потому что они разрабатывают формат изображения, используемый в игре, чтобы сохранить изображения маленьких кнопок. Некоторые другие программисты могут использовать здесь 32-битное значение, позволяющее хранить изображения вплоть до ширины и высоты 4294967295. Некоторые сумасшедшие программисты NASA могут даже использовать 64-битные для хранения огромных фотографий галактики размером до 18446744073709551615 пикселей.Если вы не знаете правил, вы не можете прочитать эти «значения», как вы их называете. Потому что вы не знаете, где они начинаются в файле изображения и где они заканчиваются. Таким образом, вы получаете кучу битов, о которых ничего не понимаете.

Вот почему вселенная полна так много разных форматов изображений. Потому что не существует стандартного решения для записи некоторых целочисленных значений в файл. Это выбор программиста, полностью основанный на многих факторах, таких как Endianess машины, на которой вы работаете, язык программирования, который вы используете для разработки оригинальной реализации формата файла, и многие другие вещи, такие как назначение формата изображения (как четко было сказано ранее другие ответы).

Практичный простой формат файла черно-белого изображения, который содержит только одно значение 166 для представления изображения 4x2 пикселей:

Изображение (1 - черный пиксель, 0 - белый пиксель):

1010 
0110

Этот формат файла использует 1 БИТ на ПИКСЕЛ, сохраненный как ЕДИНОЕ 8-битное целое значение 166 (10100110). Вот и все. Никакой массив значений 0-255 не используется, но 8 различных значений 0 или 1 сохраняются в качестве значения 166.

Если вы использовали массив значений 0-255 для каждого пикселя * 3 раза для RGB, вы получите изображение в 24 раза больше. Этот формат файла просто сэкономил в 24 раза больше дискового пространства, необходимое для сохранения изображения, подобного этому, или в 24 раза меньше памяти компьютера, необходимой для чтения и сохранения этого изображения в оперативной памяти компьютера, когда вы используете это изображение, например, в своем высокопроизводительном движке 3D-игр для нарисовать на экране что-нибудь (текстурирование тысяч летящих частиц пыли может быть хорошим кандидатом :)).