Свежие комментарии

Title	Comment
1) Причем тут sRGB?	1) Причем тут sRGB? 2) Тему про CMF в этом блоге много раз обсуждали. Спектры чувствительности пикселов не делают линейными комбинациями cone fundamentals не потому что не могут, а потому что не хотят. А не хотят - из довольно очевидных соображений.
http://en.wikipedia.org/wiki	http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg http://en.wikipedia.org/wiki/File:CIE1931_RGBCMF.svg http://en.wikipedia.org/wiki/CIE_1931_color_space
Меня ввело в ступор сочетание	Меня ввело в ступор сочетание "sRGB" и "спектров" в одной фразе. Разве sRGB каким-либо образом специфицирует спектры?
Для видео такую задачу давно	Для видео такую задачу давно поставили и чего-то даже добились.
Если спектры на всех этапах	Если спектры на всех этапах являются линейными комбинациями sRGB, это позволяет снять картину и напечатать её неотличимо от оригинала. Тогда какие-то коэффициенты будут, но нет причин обзывать их ББ. Они все изображения, просто разные способы сжатия с потерями. Например, JPEG можно считать набором пикселов с прозрачностью в форме наложеных синусоид :-)
спасибо!	спасибо!
предлагаю просто в EULA	предлагаю просто в EULA (продуктов) включить пункт raw это image...
один булка	1. Цветовое пространство Любой изображение всегда Мне пожалуйста один кофе и один булка :-). Опечатка там.
Если YCrCb или RGB — видимо,	Если YCrCb или RGB — видимо, да. А там же ещё CMYK может быть, YCrCbK. Хм... а JPEG вообще как-то больше с макроблоками вяжется, там же пикселов как таковых вообще нет. То есть RAW даже изображенистей, чем JPEG.
Для истории. Обсуждение	Для истории. Обсуждение случилось тут: http://forum.onliner.by/viewtopic.php?t=4945205&start=13740
А JPEG - тоже три?	А JPEG - тоже три?
С ИК-телескопов показывают	С ИК-телескопов (и камер) показывают потом в искусственных цветах, которые к исходным "цветам" отношения не имеют (ибо исходного цвета и нет, "цвет - это ощущение"). То есть преобразование "сигнал - глаз" не определено в силу очевидных причин.
Есть одно обстоятельство:	Есть одно обстоятельство: приведенный алгоритм берет и работает. И для NEX-ов, и для A7/A7r/A7x, и для RX1 и для Axx. А тот в котором "разбираться лень" - он для старых камер (переход состоялся в A900, где были оба формата, в более новых камерах - вот только обсуждаемый) exiv2.org - это не официальный сайт exif-а, а официальный сайт библиотеки exiv2, но это уже мелочи.
"RAW изображение существует в	"RAW изображение существует в "цветовом пространстве" сенсора" - Хм. Может, соответствует? И то не совсем однозначно. Пример - ИК-телескопы.
У меня на цитату сверху	У меня на цитату сверху просится только такой ответ: «Да, RAW — это не изображениЕ. Это изображениЯ, чаще всего три монохромных». А вообще, конечно, лень и глупость уже настолько утвердились в головах современных фотографов и тем более «фотографов», что с ними об этом разговаривать зачастую просто бесполезно.
Конец красивой сказке	Итак, по пунктам. 1. Код, приведенный в статье - некая поделка для линукса под названием RawStudio. Работает сие вообще или нет - не известно, но будем придерживаться мысли что работает 2. Полный код класса, из которого выдернут кусок для статьи лежит здесь - https://github.com/wjakob/hdrmerge/blob/master/rawspeed/RawSpeed/ArwDeco... 3. Теперь неспециалисту придется просто мне верить, остальные смотрят в код, на строку 147. 4. Далее специалисты сами найдут откуда взялось значение переменной "bpp", а остальные верят мне на слово - значение может быть 8 или 12 и означает кол-во бит на пиксель, читается из метадаты этого самого рава. Кстати для А7 там будет 14 и работать не будет вообще ничего. 6. Алгоритм, обосранный в первоначальной статье применяется только для случая bpp = 8 и автор опуса не мог этого не знать (хотя кто его знает). У каких сониевских камер 8-битный рав - я не знаю, и в чем смысл паковать 8 бит в 7 - тоже. В комментариях есть некое упоминание о какой-то Sony E-550. 5. Если bpp = 12 (т.е. как во всех бзк кроме А7/А7р) - используется совершенно другой алгоритм и разбираться в нем мне лень. Пока - достаточно факта что автор статьи сознательно все это умолчал, справедливо рассчитывая что недалекие юзеры побегут друг другу пересылать линки на статью с криками "все пропало", что собсвенно и произошло. Дополнение, чисто для задротов: чтобы не было сомнений, что bpp будет равно 12. Это читается тэг из экзифа Exif.Image.BitsPerSample, его id = 0x0102. В большинстве программ-вьюверов экзифа сей тег не показывается вообще, только тэг Exif.Image.CompressedBitsPerPixel (id=0x9102), который кстати = 8. Тэг BitsPerSample можно разглядеть только программой с официального сайта экзифа - http://www.exiv2.org/download.html, запустив ее с параметрами "exiv2.exe -p v pr имя_файла". И даже для старого некс 5н там значение 12.
Какие-то (отличные от	Какие-то (отличные от одинаковых/единичных) коэффициенты ББ вы в любом случае будете вынуждены применить. Ну не в любом, хорошо, я знаю три исключения, когда ББ наложен уже при съемке. UPD: да, и три исключения с демозаикой. Становятся ли от этого sRAW изображениями, тогда как обычные CR2 ими не были?
1) Для JPEG такую задачу	1) Для JPEG такую задачу (улучшить распаковку) просто (массово) не ставят. Но там тоже есть место подвигу. Квадраты спрятать, можно много чего придумать. 2)То, что изображение нуждается в "интерпретации" - это для всех изображений так. Маргулис вон сколько книжек исписал именно об интрепретации и улучшении (без всяких RAW, готовых TIFF/JPEG). Вот классический "полуцифровой" процесс: - есть изображение (слайд), ну не цифровое. - отсканировали, получили TIFF (изображение ж!) - этот TIFF нуждается в интерпретации. По банальной причине - диапазон яркостей слайда раз в 10 шире чем у бумаги (на которой будем печатать).
Довольно хитрый переход.	Довольно хитрый переход. То, что это изображение - не спорю. И на плёнке тоже есть (скрытое) изображение, которое надо еще проявить. Однако сравнение с JPEG довольно скользское: у JPEG, насколько я знаю, однозначная интерпретация правильной раскодировки (т.е. "улучшить" JPEG более продвинутым методом распаковки нельзя), а для RAW постоянно появляются новые более продвинутые методы дебайеризации и "угадывания" деталей. То же самое и с цветовыми пространствами. Обычно у изображения гамма и цветовое пространство строго задано (хотя с современной мешаниной в форматах там может быть прописано это как угодно). Т.е. всё по стандартам конвертируется и подаётся. Для камеры же тут не всё так однозначно - фотограф может снимать с другим ББ, в надежде сконвертировать "в посте", либо может снимать под пуш/пулл, в надежде вытянуть тени. Т.е. как и с пленкой и сканированием - тут требуется интерпретация, а для "обычного" финального изображения - только конвертация да презентация на финальном носителе. Как-то так.
Баланс белого - это имитация	Баланс белого - это имитация "стандартного" освещения. Такой задачи может не быть.
>> Вот пусть 10 человек	>> Вот пусть 10 человек попросит. Прошу ;)
На маке gfxCardStatus мне	На маке gfxCardStatus мне показывает именно это. Можно еще включить debug log и посмотреть что там (после рестарта программы) в первых строчках вывода (в OpenGL версии)
а как навскидку видно что FRV	а как навскидку видно что FRV например использует dGPU, a не iGPU ?
Вот пусть 10 человек попросит	Вот пусть 10 человек попросит. Пока Files Sort order - extension даст 99% нужного
> Работа с "версиями файла с	> Работа с "версиями файла с разным процессингом" - это отдельная большая история. это несомненно - но imho логично таки в fast __raw__ viewer'е иметь опцию смотреть только __raw__ (ну или если уже есть опция для "additional raw extensions", то и опцию для исключения - например... можно непарный к raw JPG и исключить)... $0.02, нет даже $0.01
Работа с "версиями файла с	Работа с "версиями файла с разным процессингом" - это отдельная большая история. Для обсуждаемой задачи: включите сортировку по расширениям и все JPG отсортируются в отдельную кучку.
> Типичная ситуация типичного	> Типичная ситуация типичного юзера - RAW или RAW+JPG во входном потоке. да, но не менее типично сохранение готового JPG в итоге в тот же самый каталог (я например вписываю в название готового JPG каким конвертером raw был доставлен в фотошоп... RPP или C1 или ACR... плюс иногда более одного варианта обработки -> разные имена)
Типичная ситуация типичного	Типичная ситуация типичного юзера - RAW или RAW+JPG во входном потоке. Во втором случае их можно поклеить (по одинаковым именам). То есть опцию - можно, но пусть человек 10 попросят.
> JPG с другими именами - не	> JPG с другими именами - не игнорируются. может опцию - просматривать только raw ?
Есть проблема, которая	Есть проблема, которая называется "старые видеочипы" (типа Intel 845G). На них даже есть DX9, но они ограничены 64-мя инструкциями на шейдер и к этому ограничению уже очень близко. Соответственно, прозрачность можно было сделать дешево (2 шейдерных операции), все остальное будет дороже и я не рискнул (проблема усугубляется тем, что у меня на руках такого компьютера нету, приходится знакомых просить потестировать). Ну и субъективно - мне вот понравилось что получилось и я поставил себе прозрачность 0.4.

Свежие комментарии

Pages