К одному и томуже градиенту вначале применил пологую кривую, затем применил autolevels. Наверху RGB 8 бит, внизу RGB 16 зы. Более наглядный пример. Вид примененной кривой показан (вначале применяется кривая, затем автолевелс), где 16 бит, а где 8 я думаю понятно:
"Видишь суслика? - Нет! - И я не вижу. А он есть!"(с)"ДМБ" Прсто масштаб разный у расчёски)). У 16битной зубчиков поболе будет. Хотя об этом и речь, о плавности градиента. Согласен - мой косяк, был не прав.
зря конечно вы вытащили личное сообщение в форум, но впрочем что сделано что сделано. пока бессонница отчего бы не прокомментировать упаси боже ни в коей мере не претендую на истину в последней инстанции, просто высказываю свое мнение хорошо что написали согласен совершенно, даже и не думал спорить по этому вопросу. вопрос то собственно в другом. нет и не будет камеры у которой битность RAW'a меньше или равна битности JPEG'a. не потому что это невозможно, а потому что противоречит здравому смыслу. это про АЦП и сенсоры лень долго искать, взял из Wiki ==== В фотографии динамический диапазон принято измерять в единицах экспозиции (шаг, стоп, EV), то есть логарифмом по основанию 2, реже — десятичным логарифмом (обозначается буквой D). 1EV = 0,3D. Характеристика «динамический диапазон» также используется для форматов файлов, используемых для записи фотографий. В этом случае он назначается авторами конкретного формата файла, исходя из тех целей, для которых этот формат будет использоваться. Например, ДД JPEG определяется 8-битным представлением цвета и стандартом sRGB и равен 11,7EV (из них лишь 8-9EV реально полезны) ==== на мой взгляд для сырых данных прямая аналогия. добавлю что я писал о ДД RAW файлов(любых). вы же почему то приплели сюда пентакс. ну что еще. посмотрите исходник dcraw. он с открытым кодом. я полюбопытствовал. при конвертации по умолчанию (без востановления светлых зон) там идет сначала вычисление черной точки. т.е. начала диапазона что есть по сути отсекание младших незначащих бит, затем извлечение с заданной кривой до конца диапазона. т.е. до 65535, все что выше - отсекается.
К сожалению моя квалификация не позволяет мне что-то определённое вытащить из исходников,... Я, собственно, никакой не программист... Я юрист по образованию и милиционер по профессии... Программистом я хотел стать, когда заканчивал школу... Однако моя квалификация позволяет мне всё же чётко представлять, что такое 8-ми, 16-ти битное представление света... Также моя квалификация совершенно не понимает, что Вы имели в виду, когда написали вот это: Я не знаю, что Вы имели в виду... У меня просто, возможно, знаний не хватает... Но мои познания в обсуждаемом вопросе заставляют меня сделать вывод, что это ахинея какая-то... Объясните, пожалуйста, по какой причине Вы взяли из 12 битного значения только серединные 8 бит... Ни с конца, ни с начала... А именно с середины... Я прошу без пальцев, а если можно с самого начала... Объясните мне, пожалуйста... Вот в этой строчке: 00|00111100|00 Как получилось так, что в 12 битах мы имеем 5,8% от максимума, а когда Вы "перевели" в 8 бит, то получилось уже 23%... Следуя вообще Вашей же логике... Если мы возьмём файл 16-ти битный ТИФФ (не JPG для чистоты эксперимента) с занятым полностью диапазоном... Так, чтобы гистограмма была от края до края... После этого переведём этот файл в 8-бит, то у нас сразу же должны потеряться часть теней и часть светов, т.к. они, как Вы говорите, будут за диапазоном?....
ну это же пример. не считается так грубо конечно. хотя если гамма кривая линейная, то что то типа такого и происходит. а 23% из 5.8% получается потому что правая часть отбрасывается. т.е. сначала анализируются все данные и определяется что будет началом и собственно черным цветом и это значение вычитается из основных данных. после этого отбрасывается все что по значению больше 65535. диапазон возможных значений яркости сужается. хотя может быть я тут в чем-то туплю и вас неподопонимаю. ну если тифф обрабатывать алгоритмом dcraw (что в корне неправильно, но исключительно для чистоты эксперимента ), то потеряется значительная часть светов. тени теряться не будут. часть теней потеряется при установке вручную значения точки черного больше 0. для минимизации этих потерь делают регулировку контраста (что происходит к примеру при конвертации из 16битного тиффа в 8битый средствами фотошопа к примеру. поэтому ДД в нем не меняется, а меняется количество оттенков о чем собственно пишет JSeven), и различные алгоритмы восстановления информации в зонах светов. как работают честно сказать не знаю, не копал в этом направлении. в dcraw есть какая функция для смешения инфы из зоны светов с чем то. но навскидку не понял как это работает. PS. извините что пишу весьма сумбурно ну как умею.
Не знаю где вы тут пытаетесь приплести прямую аналогию, но вы хоть не читайте между строк, обратите внимание на фразу "и стандартом sRGB", она там не просто так. Еще раз для непонятливых, ДД сенсора и битность АЦП там или РАВа не связаны напрямую. Никак, если сюда не начинать вплетать дополнительные параметры, о которых _ни слова_ не было в ваших изначальных постах и бредовых вычислениях со сдвигами битов, которые вы каким-то образом соотносили с обязательным изменением яркости на стоп. Ну поймите вы, нет такого. Не работает так. Вы хоть мозг включите чуть-чуть, если по вашей же ссылке ДД jpeg в стандарте sRGB 11.7EV, а его битность 8 бит, откуда там, ну откуда будет яркость изменятся сразу на стоп при сдвиге битности на единицу??? Не может и не будет такого, т.к. если бы это было так, то и ДД jpeg в стандарте sRGB был бы 8 стопов, но нет этого. Сами хотябы прочитайте то, что цитируете, включайте голову хоть иногда. >ДД RAW файлов(любых). вы же почему то приплели сюда пентакс. Почему приплел вам не ясно? Вы действительно настолько непонятливы? RAW файл у пентакса 22 битный. ДД у пентакса 10 стопов. RAW файл у А200 несжатый 12 битов. ДД 10 стопов. Все еще непонятно, что нет связи? Бред извините, сивой кобылы. Вы хоть сами прочитали, что цитировали с вики? jpg: _________ 00000001 11111111 __________ Что, разница 8 стопов??? Вы сами при этом цитировали, что в стандарте sRGB ДД 11,7 EV, а разница между 00000001 и 11111111 это практически максимум в 8 битном представлении.
ну допустим, по первых, сырой рав файл все таки это не sRGB, который уже является результатом некоторой обработки. во вторых, я вам не справочник писать в постах ВСЕ нюансы сразу. ну в третьих, мне не нравится тон ваших постов и постоянные нападки. если я неправ, скажите как именно правильно. только не надо больше про сенсоры пентакса и рав файлы его же. эти банальности про ДД и битность равов даже комментировать нет желания. все что об этом думал уже написал в постах выше. если вы конечно читали.
Я вам сразу писал и в каждом сообщении повторял конкретно где вы неправы, но у вас явно проблемы с пониманием. Бредятина. Никак не связана битность RAWа с ДД сенсора. Зазубрите, если наизусть если не способны понять это. Есть МАССА примеров, наглядно иллюстрирующих это. Те, у кого мозг работает, уже поняли давно. Бред сивой кобылы. Сказать, как правильно? Правильно так: 000011110000 - оригинальный рав 011110000000 - exp плюс неизвестно сколько, сколько - сказать нельзя, к sRGB данный RAW на данный момент никакого отношения не имеет, никто не знает сколько там будет exp+, это зависит от параметров сенсора, его калибровки, от характера АЦП, и вообще железа, от параметров конвертации в конце концов если речь о результате на мониторе. 000000011110 - exp минус неизвестно сколько, аналогичным образом. Почему это не надо? Самый наглядный пример ошибочности вашей псевдо-теории, Вы признаете это наконец, или же поясните куда делся "суперДД" у 22битного RAW-а? Ведь по вашей теории: 000000000000011100000 - оригинальный рав 111000000000000000000 - exp + 13 стопов 000000000000000000111 - exp - 5 стопов. А это БРЕД. ДД у РАВа K10D измеряли, там порядка 10 стопов, а никакие не 13 или 20
Сдаётся мне, что у нас какая-то каша получилась... Мы немножко не о том говорим... Я Вас понял про смещение битов... Вот тут: 00|0011110000 - оригинальный рав 01|1110000000 - exp +3 00|00000111|10 - exp -3 Вы имели в виду, что когда Вы сдвигаете все 1111 в лево... (сорри за такое выражение), Вы умножаете на 2 получается, то есть как бы увеличиваете программно +1 стоп экспозиции... Я правильно понял?... То есть, как бы, при умножении на на 4 (х2х2) всё умещается в 8 бит, а при умножении уже на 8 (х2х2х2) уже в 8 бит никак не влезть... Я правильно истолковал Вашу схему? Если правильно, то тогда у Вас действительно каша получилась... Вы совершенно исказили всю картину.... Дело-то в том, что перевод из 12 в 8 (или из 16 в 8) проиходит совсем не так, как Вы тут представили... Естественн, что если умножать и делить и т.д. 12-ти битные значения, то в конеце концов они выйдут из 8-ми бит.. (Ну это тоже каламбур, но как бы сейчас ясно станет, что я имею в виду))))))) Если нам надо "убрать" из 12 бит лишние 4, это не значит, что мы их просто отсекаем... Это значит, что мы пересчитываем исходя из пропорции... И 5,6% от максимума так и должны остаться 5,6% от максимума... Только если в 12 битах максимум это 4095, то в 8 битах этот максимум уже 255... Далее, если всё исправить в вашем рассуждении и перевести всё в нормальный вид... Вот у нас есть в 12 битах это число: 000011110000 Теперь переводит всё в 8 битное представление: 000011110000 х 1111111 / 111111111111 = 00001110 Теперь повторяем Вашу же схему 00001110 exp 0 00011100 exp +1 00111000 exp +2 01110000 exp +3 11100000 exp +4 Ничего никуда не вышло... Давайте для лучшего восприятия переведём всё в десятеричные цифры. Для 12 бит, то есть для 0 - 4095 240 -------------------- экс. 0 240х2 = 480 ------------ экс. +1 240х2х2 = 960 ---------- экс. +2 240х2х2х2 =1920---------экс. +3 240х2х2х2х2 = 3840 ------экс. +4 Теперь те же самые значения для 8 бит, то есть 0 -255 14 ---------------- экс. 0 14х2=28----------- экс. +1 14х2х2=56 --------- экс. +2 14х2х2х2=112 ------ экс. +3 14х2х2х2х2 = 224 ---экс. +4 И там и там мы из диапазона не вышли.... +4 ЭКСПОЗИЦИИ мы имеем и там и там... Кстати тут можно заметить "проблемы" возникающие при расчётах в 8-ми битном режиме... Так как каждый раз нам приходится округлять значение до нужных нам 8-ми бит, а с каждым действием погрешность накапливается, то в конце получается, что если 3840 (12 бит) это 94% то 224 (8 бит) это только 88%... В этом то и проблема... Она существует и все про неё знают... НО!!! Как бы увидеть её в реальной работе затруднительно... Если можно говорить о преимуществе 12 бит над 8, то о преимуществе 14 бит над 12 бит уже говорить просто смешно... Как опять же неплохо заметил коллега -=BooM=- Как бы разница теоретически есть, но практически её нет... В любом случае ДД тут совершенно не причём... Можно говорить, что в определённых случаях (наверное такие случаи бывают) на самых краях диапазона из-за недостатка, скажем так, занков после запятой ( Надеюсь все меня поняли...) В 8-ми битном режиме могут потеряться некоторые детали в тенях... То есть, если в 16 битном режиме точка будет иметь значение 0000000000000001, то для 8-ми битного режима это значение будет каким????????? 1 или 0? Смотря как окрглять... Скорее наверное 0, чем 1... НО!!!! Тут речь идёт вообще не о 2х стопах, а эфимерных вещах... О сусликах, которых не видно, но они есть... Давайте доведём ситуацию до асурда и попробуем сделать то же самое с 6-ти битным файлом... Допустим в 6-ти битах пресловутый пиксель со значением 000011110000 будет иметь значение: 000011 000110 001100 011000 110000 Опять же все те же самые 4 стопа экспозиции... Другое дело, что градиент уже такой огромный, что потерялись детали в тенях и в светах исключительно для того, что для них не нашлось подходящего значения...
Хотя, как правильно заметил колега JSeven это никакой не сдвиг экспозиции... Это хрен знает что за арифметика и какое оно имеет оношение к реальному файлу, который надо чуть подправить вообще не ясно... Тут можно вообще дойти до идиотизма... Допустим тут 36 бит... И чё? 000000000000000000000000000000000001 ТУТ ДД 36 стопов?
спасибо я вполне способен это понять. все еще надеюсь и вы тоже способны понять из вашего же поста откуда вы вытаскиваете информацию при 12 битном раве, и даже о боже чуть больше из 14 битного. предложите производителям 8битный рав. или даже 4 битный, куда уж мелочится. они это оценят сполна. такая экономия флешек. люди включившие мозг давно уже пишут 4 битный рав. с такой откровенной тупостью признаться редко встречался. ну замените "3" на "x", что изменится? столкните мозги с мертвой точки, а то закисли уже. вот где бред так бред. вы реально понимаете как можно измерить, не посчитать, а именно измерить динамический диапазон файла? вы вообще в своем уме? и в уме ли вообще или просто тупо бездумно пересказываете статьи из интернета? и я же просил не поднимать тему пентакс равов...
почитал ваши выкладки. и вполне понимаю что вам обидно терять лишние биты но просто попробуйте сконвертировать рав именно с полным диапазоном. получите серую блеклую бесцветную картинку. спорить не буду. на любителя. собственно, повторю фразу вашего коллеги JSeven - вы можете хоть в инопланетян верить. ну и я наверное тоже я заканчиваю этот бесполезный спор.
Азбуку чтоли перечитайте, если по русски не понимаете? Чем больше битность, тем больше оттенков внутри динамического диапазона. Ессено, чем больше битность, тем больше информации о деталях соответсвенно при неизменном ДД, поэтому те кто действительно включил мозг, хотят больше битности, но чтобы иметь больше информации о деталях и оттенках. А тот, у кого мозги куриные, думают что чем больше битность, тем больше ДД и порют чушь вроде "хотя удивительно что вы не видите связи между ДД сенсора и требуемой разрядностью рава, но... воля ваша" Что изменится? Изменится бредатина которую вы написали, на чтото более реалистичное. Читайте внимательно: Это бред сивой кобылы. Чтото более реалистичное. Но ты писал именно первое. А какое дело, какие неудобные вопросы вы там просили поднимать, а какие нет??? Вы можете много чего просить. Можете попросить чтить вас как истину в последней инстанции. Простой пример, К10D, пишет равы 22 битные. Вы только и умеете пустой треп разводить, или прокомментируете всеже, как 22 битный РАВ повлиял на ДД сенсора камеры К10D? Ведь Вы именно это утверждаете: "хотя удивительно что вы не видите связи между ДД сенсора и требуемой разрядностью рава, но... воля ваша" Поясните связь, и вопрос будет закрыт. А я пока ничего не слышал от вас, кроме неуместных просьб "ой, я на это не буду отвечать" Сколько надо вас носом тыкать в ваши собственные слова, чтобы вы перестали их перевирать, и подмахивать что вы там якобы о чем то другом говорили? Все понятно, это называется нечего сказать. Ни одного объективного аргумента в пользу жести из разряда "вы не видите связи между ДД сенсора и требуемой разрядностью рава" мы так и не увидели, только пустой треп.
Почитал... обозвали друг друга... техноонанизмом покидались... А зачем? Для меня, дремучего, все просто - снимаю в RAW, потому что cRAW отличается размером. Чисто интуитивно чую, что это хуже, а значит и на фиг не надо. Это единственный критерий. Раз другой формат для экономии, значит экономия может быть только на качестве. Это бездоказательно, а просто интуитивно. Ни с кем спорить не собираюсь, просто высказал свое мнение. ИМХО.
Silver Не... Ну реально, объясните мне и Jseven... Как это Вы так привязали "умножение на два" к "увеличению экспозиции на стоп"... Допустим мы имеем 12-ти битовое значение пикселя равное 1 (единица) Это всего-то 0,0244% от всего диапазона... Умножаем на 2 и получаем 000000000010 Получаем 0,488% от всего диапазона... Это что? У нас на стоп ярче стало всё?
Ню-ню... Все зависит от того, какая картинка была на входе. Вы вообще знаете ,что такое HDR и зачем нужен брекетинг экспозиции??? Я тоже повторю фразу НАШЕГО коллеги - "вы можете хоть в инопланетян верить" (с) JSeven.
Fyarik, ну мне кажется с тов. Silver все понятно Один пустой треп... Человек свято уверен, что если какойто цвет в RAW файле помечен как "1", а другой цвет помечен как "4", то обязательно то что фиксировал сенсор во втором случае обязательно на 2 стопа ярче. Не зависимо от того, какой был сенсор, какой был АЦП, какова битность, какой алгоритм перевода аналогового сигнала с сенсора в цифры. Единственный аргумент у него "аха", причем простейшие примеры, где ДД и битность совсем не совпадают или очень не совпадают, из которых явно следует что ерунда все это - он пропускает мимо ушей и просит "об этом больше не упоминать" И как такому чтото объяснить, если любой аргумент человек "просит" больше не упоминать ? Ну хоть в графе "положение" он не врет, жаль только, что даже учиться не хочет
