X-log

raw vs jpg — что, как и почему

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

сразу хочу предупредить, что заумной теории тут не будет — я все свои знания получаю исключительно из опыта. поэтому я не буду сложно рассказывать о технической стороне, потому что мало что в этом понимаю, а буду рассказывать просто и доступно о том, что нужно крутить. в результате, правда, всё равно окажется, что надо крутить мозг.
да, raw я буду называть равом, а jpg — жпегом, потому что мне очень нравится переключаться между раскладками в середине текста, но я себя решил не баловать. имейте в виду.
ну, поехали.

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

поздравляю, мы открыли для себя два куска, которые непосредственно участвуют в формировании изображения. к обьективу рав прямого отношения не имеет, поэтому поговорим о матрице, а обьектив выкинем в окно.
на вид матрица — прямоугольник из чёрного стекла, размером (на моём фотоаппарате, грубо) 2×1,5 см. как, я надеюсь, все присутствующие понимают, матрица это светочувствительная конструкция, непосредственно формирующая изображение, получаемое через обьектив. о том, как конкретно эта штука работает, я мало что знаю, но кое-что рассказать могу, как запомнил и сам вычислил, ковыряясь в камере ложкой. на каждый пиксель, заявленный в аннотации к камере, имеется 3 светочувствительных элемента, закрытых разными светофильтрами — красный, синий, зелёный. хотя я бы честно говоря на трезвую голову не взялся из 3х маленьких круглых пикселей составлять один большой квадратный.

в результате мы имеем на выходе с моей камеры 8×3=24 миллионов фактически чёрно-белых недопикселей, из которых и получается в последствии 8-мегапиксельная цветная картинка. (напомню, я говорю сейчас про свою камеру, но принципиально разницы никакой нет и на любой другой.) вот этот самый сырой результат с матрицы и есть рав!

упд меня просветили по поводу технической строны вопроса. мегапикселей всё равно получается 8, из них 4 на зелёный, 2 на красный и 2 на синий, а потом из них высчитывается 8. до этого я бы мог кстати легко догадаться сам, если бы просто пересчитал все красные или синие пиксели на каком-нибудь кадре. каюсь, не озаботился.

уф. это было сложно, но мы прорвались.

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

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

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

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

плюсы сьёмки в raw
говорят, плюс у рава только один — невероятная гибкость в обработке изображения при конвертации в жпег или тифф. почему так?
а вот почему. жпег у нас формат 8-битный, т.е. на каждый пиксель в каждом цветовом канале приходится 8 бит информации. каналов в жпеге у нас обычно 3, потому что работаем обычно в цветовой модели RGB, соответственно на каждый цветной пиксель у нас приходится слияние 255 оттенков красного, 255 оттенков зелёного и 255 оттенков синего. а в раве у нас всё по другому. у нас рав 12-битный, а не 8-битный. вот и плюс — рав содержит значительно большее количество информации, чем жпег, именно за счёт этих дополнительных бит. а почему у нас в раве 12 бит? потому что с матрицы выходит по 12 бит на канал, и с этим ничего не поделаешь. этой части я уделил довольно мало места, при том что это, наверное, основное преимущество рава. именно за счёт повышенного динамического диапазона мы имеем такие могучие возможности по экспокоррекции уже после сьёмки.

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

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

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

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

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

ну что, 2 преимущества мы уже нарыли. осталось ещё одно очевидное преимущество — работа с шумами.
я уже говорил, что рав содержит все шумы в полном обьёме и сам по себе никак их не снижает. процесс шумоподавления происходит при конвертации из рава в жпег, сразу в камере или потом, на компе. когда бес пересчитывает рав в жпег непосредственно в камере, он пользуется своими собственными алгоритмами шумоподавления. у такой схемы есть 2 недостатка — отсутствие возможности настройки и требования к мощности процессора камеры. с настройками всё понятно — отрегулировать уровень подавления шума мы не можем, по этому с радостным блеянием теряем детали изображения, сожранные шумодавом. шумодав облизывается, мы довльны, как Наполеон, которому ещё не доложили о потерях.
со скоростью работы не всё так просто и понятно, и тут я не могу утверждать наверняка. но попробуем представить, какая нужна вычислительная мощность, чтобы обсчитать и подавить шумы на 3х 8-мегапиксельных кадрах за одну секунду (скорость серийной сьёмки моей камеры — 3 в секунду). мой домашний ноут такой мощностью не обладает, а он размером с том БЭС. ну только потоньше раза в два. что тогда говорить о маленькой камере? с другой стороны, там стоит специальный процессор, рассчитаный именно на эту задачу и ни на какую другую, в него зашиты умные алгоритмы подавления шумов именно этой камеры. поэтому вопрос, насколько на самом деле эффектвно камера гасит шумы, я решил экспериментально. кот в качестве модели, исо 1600, raw+jpg, низкая освещённость.
после этого рав прогнал через captureOne pro. вердикт однозначный — алгоритм шумоподавления в камере — купированый. фотографии я выложу позже, сейчас, увы, возможности нет — кот, работавший моделью, взбеленился и отгрыз мне от сетевого шнура сегмент, отвечающий за выкладку файлов через ftp.

общие выводы по шумам — рав лучше тем, что при конвертации использует гораздо более мощные и гибкие в настройке алгоритмы шумоподавления. имеется в виду, конечно, что программное обеспечение, осущствляющее конвертацию, подавляет шумы. а это означает, что мы можем управлять степнью «смазывания» картинки,добиваясь нужного баланса между шумностью и детализацией. конечно, можно возразить, что и на жпег можно применить standalone софт для подавления шумов, типа NeatImage. но я на это возражу, что шумодав, использующий в качестве источника данных упитанный и румяный рав, всегда будет работать лучше шумодава, опирающегося на данные из обглоданного жпега. это так же очевидно, как то, что бульон из упитанного баварца, любителя пива и колбасок, получится вкуснее и наваристее, чем из тощего монаха монастыря Шао-Линь. монах ещё и расплескает всё, пока вариться будет...

общие выводы по преимуществам рава относительно жпега:
1. на порядок большая гибкость в коррекции контраста и экспозиции за счёт более широкого динамического диапазона
2. на 2 порядка большая гибкость в коррекции цвета
3. более гибкие и мощные инструменты подавления цветового шума

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

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

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

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

summary
обобщаю:
снимайте в рав, если:
1. вы фотохудожник, который никуда не торопится
2. вы коммерческий фотограф, снимающий в студии предметку или моделей на пленере
3. вам требуется получить максимально возможное качество фотографий
4. вы находитесь в сложных условиях сьёмки и заранее не знаете, какой будет свет и будет ли он вообще
5. вы перфекционист и хотите иметь возможность покрутить цвета и экспозицию сами
6. вы — это я

снимайте в жпег, если:
1. вы репортажник, работающий на ежедневное/еженедельное издание
2. у вас внезапно образовалась срочная сьёмка, фотографии должны быть сданы через полчаса
3. вы стали свидетелем события, которое необходимо запечатлеть, а камера настроена на сьёмку в студии — ставьте на автомат и стреляйте, она снимет в жпег
4. вы снимаете с внешней вспышкой и не собираетесь причёсывать кадры после сьёмки
5. вы вообще пофигист и не собираетесь причёсывать кадры никогда

имейте в виду, что всё вышенаписанное — исключительно моё мнение, почти исключительно основанное на моём опыте и аналитической работе. в технических деталях я не уверен, но в принципах вроде не ошибся.
вот. если что не так — поправляйте.

Комментарии (4)

Комментарии (4)

  1. | Fotostation декабря 10, 2008 2:51

    [...] на тему (см сабж). без картинок, иба хз чо там рисовать. raw vs jpg Тэги: [...]

  2. snowdosker декабря 11, 2008 1:34

    Красиво написал -) И многим на пользу )

    А вот с шумодавами пока беда... С1 не пользую, а во всех остальных конвертерах шумодавы мне не нравятся :- (

  3. Angry XlinkaS декабря 11, 2008 13:28

    встроенные шумодавы везде — бяка... рекомендую NeatImage — при умелом использовании решает разнообразные проблемы.

  4. Pavel декабря 15, 2008 12:29

    Не совсем так. С 8ми мегапиксельной камеры мы имеем ровно 8 миллионов недопикселей из которых по 2 милона красных и синих и 4 миллиона зеленых. Потом путем байеровской трансформации мы получаем на каждый из 8ми миллионов пикселей все 3 канала цвета. ru.wikipedia.org/wiki/%D0...0%B5%D1%80%D0%B0

Оставить комментарий