Отличия движков Exposure и Brightness в конверторе фотошопа

Цитата:

от: VoVan
Это то я знаю, только не знаю почему этого допустили программеры. Неужели дураки? или был смысл?

не программеры дураки. а их просто ДОСТАЛИ ВОТ ТАКИЕ ВОТ ЮЗЕРЫ КАК В ЭТОЙ ТЕМЕ.
которым вобще не поймёш какого хрена надо. "правильную конвертацию" 99% такого населения не поймёт. им поедрённее да поцветастее.
и по 2 движка которые нихрена не делают на каждый квадратный сантиметр екрана

Цитата:

от: Krainov

P.S. Там в личке письмо...

Письмо к сожалению так и не получил - не знаю из-за чего, но тем не менее мне было-бы интересно Ваше мнение.

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

Идём дальше Вы не пробовали сделать такой тест: взять рав фаил с широким ДД, и сконвертироват его в тифф на гране засветки, а потом сконвертировать его в тифф на гране вылета в чёрное - а потом покрутить тифф и сравнить?

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

уффффффффф....

вопщем я гулять пошол ) -- напоследок хочу вот что сказать- что бы исключить взаимное непонимание: понятие динамический диапазон включает в себя границы диапазона и количество градаций

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

вроде все ок?

если придерживаться того что я сказал выше - то получится что камера которая воспроизводит два разных цвета одинаково - имеет меньший дд -- камера которая не передает детали в тенях или светах имеет меньший дд -- и соответственно меньшая разрядность итогового файла - содержит меньше информации - и можно сказать что дд тоже меньше -- NB! меньше в данном случае не значит уже /*если вообще можно применять понятие дд - к фалам*/

вы почему то упирались в понятие *границы дд* - это как раз относится к примеру о небе и деталях в нем -- основная непонятка была в том что меньше не обязательно уже %)) -- разрядность таки имеет значение

2 вован - лучше оставь иванова в покое )))))) -- если конечно по срачу не соскучился ))))

Цитата:

от:L4m3r
не программеры дураки. а их просто ДОСТАЛИ ВОТ ТАКИЕ ВОТ ЮЗЕРЫ КАК В ЭТОЙ ТЕМЕ.
которым вобще не поймёш какого хрена надо. "правильную конвертацию" 99% такого населения не поймёт. им поедрённее да поцветастее.
и по 2 движка которые нихрена не делают на каждый квадратный сантиметр екрана

Подробнее

Ура - афторитет пришёл=)))

Т.е....

Вобщем ответ на последний мой вопрос:

Идём дальше Вы не пробовали сделать такой тест: взять рав фаил с широким ДД, и сконвертироват его в тифф на гране засветки, а потом сконвертировать его в тифф на гране вылета в чёрное - а потом покрутить тифф и сравнить? это наверно и будет финиш этой темы, т.к. это будет ответ - влезает ли ДД рава в ДД тиффа...

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


Ламер - ещё один вопрос - пользуясь конвертерами "для лохов" я не могу проследить численную цепочку.
Ведь в одной теме я читал, что в РАВ(упс... или где?) количество градаций падает с затемнением... что-то вроде такой таблички было:

2048
1024
512и т.д. Или это не в раве, а... где? Наверно на стадии считывания с матрицы, да?

Цитата:

от:vconst

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

вроде все ок?

Подробнее

Я плакалъ.

Я же уже сказал определение ДД... Зачем меня дальше то пытать?
В этом и вся непонятка - Ваши определения неверны=(

количество информации это не ДД, а Мб - мегабайт... или стр(страниц)*шрифт, или мин -минут, или зн - знаков, или Мп - мегапикселей... а ДД это другое=( это д и а п а з о н...
прочитайте слово - оно русское=) и Вы всё поймёте=)

Если не верите мне - вот например... http://hghltd.yandex.com/yandbtm?url=http%3A//www.kv.by/index2003194702.htm&text=%C4%E8%ED%E0%EC%E8%F7%E5%F1%EA%E8%E9+%C4%E8%E0%EF%E0%E7%EE%ED&reqtext=%28%C4%E8%ED%E0%EC%E8%F7%E5%F1%EA%E8%E9%3A%3A76367+%26+%C4%E8%E0%EF%E0%E7%EE%ED%3A%3A144500%29//6&dsn=438&d=2493370&sh=2&sg=10#YANDEX_0

Динамическим диапазоном кадра будет разность между максимальным и минимальным значением плотности для этого кадра. Для отпечатков динамический диапазон имеет величину порядка 2 (на отражение), для негативной пленки - порядка 2.8, для слайдов - около 3.2.
вот с если пройти по ссылке http://www.kv.by/index2003034702.htm
определение... Это вообще для слайдов... но не важно...

Я этого всего не читал... просто сейчас для Вас поискал... И не учил это.. просто я ЗНАЮ что это определение верно. Вот и всё... а количество градаций измерить не просто, да и не важно оно - Вы же сами писали. что нет разницы между 16бит и 8бит, а вот числовая разница там огромная, и Маргулис так пишет... так зачем Вам 32бита? ну как дети - чем больше тем круче...
16 - достаточно, поверьте... более чем достаточно...

Одно - джипег, другое из рава. Что, кто-то сможет сделать из джипега, то же что из рава? Смешно!

На этих снимках четко видно, что на джипеге небо вылетает - на раве - нет. Еще вопросы есть? А про "вытягивание" теней - по-моему, даже горе-цветокорректор знать может...

А вообще, в теории, с помощью 16 бит, можно информации передать больше, чем 8 и 12 бит. Только вот камеры в 16 бит пока не снимают( в своем роде - зря, возможно - в будущем - будут). Поэтому, в цифровой фотографии реальным 16б взяться неоткуда. Больше, чем из рава, ниоткуда не будет. Сканеры - другая песнь... барабанники дают нереальный ДД, передаваемый только в 16 бит ТИФФ, который, впоследствии все равно урезают до 8 бит в полиграфии.. Но берут из него максимум. Оттого и картинки идут красивые...

ещё раз
при правильной конвертации всё влезает! при неправильноё не влезает!
но "правильная" имеет неприглядно низкий контраст (настоящий а не задранный)
а пипл просит хлеба и зрелищь! и им делают кривые конвертры как они просят!

да потому и неможете проследить что они для лохоф фсё искривляют! на помойку и фсе дела.

Цитата:

от:L4m3r
ещё раз
при правильной конвертации всё влезает! при неправильноё не влезает!
но "правильная" имеет неприглядно низкий контраст (настоящий а не задранный)
а пипл просит хлеба и зрелищь! и им делают кривые конвертры как они просят!

да потому и неможете проследить что они для лохоф фсё искривляют! на помойку и фсе дела.

Подробнее

Кстати говоря, в точку - примеры - смотрите выше... Все именно так...

Цитата:

от:L4m3r
ещё раз
при правильной конвертации всё влезает! при неправильноё не влезает!
но "правильная" имеет неприглядно низкий контраст (настоящий а не задранный)
а пипл просит хлеба и зрелищь! и им делают кривые конвертры как они просят!

да потому и неможете проследить что они для лохоф фсё искривляют! на помойку и фсе дела.

Подробнее

Короче практически нереально.
ЧТД всё.
надоело.


Кстати вначале я был неправ. признаю=(
прадва справедливости ради - был неправ частично, и исключительно теоретически;)

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

Вы же почему-то стали сравнивать с 8битным JPEG. Это уже кардинально другая задача - перевод большего пространства в меньшее. Без потерь невозможно теоретически (без потерь только если исходное пространство содержит 256 и менее любых разных чисел).

Можно написать программу, которая байт в байт будет восстанавливать RAW из 16 битного линейного TIFF, но невозможно этого сделать для JPEG.

PS: а динамический диапазон в этом контексте вообще рядом не лежал.

про линейный не узрел :)

Цитата:

от:UnclShura
Послушайте, что за бред вы тут нафлудили? Исходная посылка была что RAW содержит больше информации чем 16битный линейный TIFF. Ну так это не правда. Любой программист вам это скажет. Это-ж элементарнейшая задача преобразования меньшего чистового пространства (12 бит RAW) в большее (16 бит TIFF). Если речь идет о нелинейном TIFF, то все зависит от параметров гамма-кривой и в хрудшем случае в тенях (или в светах?) у вас слипнутся несколько уровней (кривая там более пологая).

Вы же почему-то стали сравнивать с 8битным JPEG. Это уже кардинально другая задача - перевод большего пространства в меньшее. Без потерь невозможно теоретически (без потерь только если исходное пространство содержит 256 и менее любых разных чисел).

Можно написать программу, которая байт в байт будет восстанавливать RAW из 16 битного линейного TIFF, но невозможно этого сделать для JPEG.

PS: а динамический диапазон в этом контексте вообще рядом не лежал.

Подробнее

Да нет, любому вменяемому человеку, даже не будь он программист, ясно, что 16, больше 12, и, следовательно, информации, может нести больше (но не на порядок). Но откуда ей взяться, при меньшей, чем 16 бит, разрядности АЦП камеры??? Как ни крути... сканер, с 16 битным АЦП - да, может выдать 16-битник более наполнный информацией, чем камерный рав. Но вот информация о градациях цвета, больших, чем 256, чем она поможет зрителю? Ее все равно не увидеть. Но она нужна при обработке... Оттуда и идея, о бесполезности обработке в шопе файлов 8-бит, тем более убитых джипеговской интерполяцией. Потому и тянутся равы, потому что, исходно, там данных больше, чем в джипеге, вот и все. Но потом, на заключительном этапе, мы лишнее урезаем, до 8 бит и зритель получает нормальную картинку, не зная что и где "тянулось".

более того, информации о больше чем 256 градациях там насамм деле просто нет сколько б там ни был ацп

Цитата:

от:UnclShura
Послушайте, что за бред вы тут нафлудили? Исходная посылка была что RAW содержит больше информации чем 16битный линейный TIFF. Ну так это не правда. Любой программист вам это скажет. Это-ж элементарнейшая задача преобразования меньшего чистового пространства (12 бит RAW) в большее (16 бит TIFF). Если речь идет о нелинейном TIFF, то все зависит от параметров гамма-кривой и в хрудшем случае в тенях (или в светах?) у вас слипнутся несколько уровней (кривая там более пологая).

Вы же почему-то стали сравнивать с 8битным JPEG. Это уже кардинально другая задача - перевод большего пространства в меньшее. Без потерь невозможно теоретически (без потерь только если исходное пространство содержит 256 и менее любых разных чисел).

Можно написать программу, которая байт в байт будет восстанавливать RAW из 16 битного линейного TIFF, но невозможно этого сделать для JPEG.

PS: а динамический диапазон в этом контексте вообще рядом не лежал.

Подробнее

Извините, но вы не в теме. совсем

Точнее всё правильно но на последних 7(примерно) страницах речь идёт именно о ДД.
Сравнивать кол-во информации в рав и чпег это идиотизм=) и этим никто не занимался=)

Цитата:

от:UnclShura
Это-ж элементарнейшая задача преобразования меньшего чистового пространства (12 бит RAW) в большее (16 бит TIFF). Если речь идет о нелинейном TIFF, то все зависит от параметров гамма-кривой и в хрудшем случае в тенях (или в светах?) у вас слипнутся несколько уровней (кривая там более пологая).

Подробнее

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

Что получется в светах:

4095 -> 65528
4094 -> 65520
4093 -> 65512
4092 -> 65504

В тенях еще лучше:

0 -> 0
1 -> 1024
2 -> 1448
3 -> 1773

То есть ничего не слипается, и даже такие значения как "4094 и три восьмых" (которые запросто могут получиться при итерполяции) будут в 16-тибитном TIFF'е отличаться от "4094 2/8" и "4094 4/8".

А вот при переобразовании цвета запросто могут возникнуть невосполнимые потери - если цвет, зафиксированный камерой, не влезает в охват того цветового пространства, в которое идет конвертация, то есть R, G или B после преобразования получилось отрицательным, то его просто усекут до 0, и ничем его потом не вытянешь.

Цитата:

от:Сергей Иванов
Да нет, любому вменяемому человеку, даже не будь он программист, ясно, что 16, больше 12, и, следовательно, информации, может нести больше (но не на порядок). Но откуда ей взяться, при меньшей, чем 16 бит, разрядности АЦП камеры???

Подробнее

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

Цитата:

от:miope
А вот при переобразовании цвета запросто могут возникнуть невосполнимые потери - если цвет, зафиксированный камерой, не влезает в охват того цветового пространства, в которое идет конвертация, то есть R, G или B после преобразования получилось отрицательным, то его просто усекут до 0, и ничем его потом не вытянешь.

Подробнее

В теории не силен, но практика сказанное подтверждает.

Цитата:

от: UnclShura
]никаких преимуществ перед TIFF с точки зрения объема содержащейся в нем информации не содержит.

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