> Я к тому, что непринципиально - что сжимать 12-14 бит в 8 или 20 в 8 -Это принципиально при обработке и преобразованиях: если информации нет - это совсем облом и не лечится, кроме "кисти художника". А если нужные битики все-же есть - вопрос твикания кривых передачи и проч. Как было не получится, но достаточно симпатично глазу - будет.
Человеку сложно померять на глаз контраст сцены, 5000 к 1 или 150 000 к 1. Зато человек видит что веток в ельнике не видно, а небо белесое. Если исходный материал позволял - небо и ветки "чинятся". Не совсем правильно показометрически, поскольку будет какая-то компрессия диапазона по нелинейным кривым и алгоритм tonemapping. Зато приятнее визуально. Потому что и небо и ветки бросающиеся в глаза станут без явных ляпов.
А поскольку конечный результат не показометрия как с ADC а для того чтобы людям нравится, это конечно будет замаплено в 8 битов. Но - иначе, с использованием битов исходного материала которых могло бы и не быть. А вот если их нет - номер не прокатит и придется пережить с лысым небом и/или без веток в ельнике.
> в любом случае большую часть выкидывать.
Это так, но вопрос сводится к тому что намного лучше выкинуть биты так чтобы глазу это было малозаметно. А если в ельнике веток не видно или небо лысое - всем понятно что это продолб. Лучше выкинуть биты где-нибудь еще.
> Так как если сжать 14 бит до 8 (с сохранением неба
> и деталей в тенях) то смотреться это будет как минимум не естественно и странно.
Это при условии что биты не ушли в "все 1" или "все 0". Когда делают серию из нескольких кадров с разным усилением - софт обычно удостоверяется что желаемый диапазон битов захвачен хорошо. Остальное не его дело, юзер при обработке сам разберется. А если всего один кадр - уже как повезет. Если вручную - еще и насколько лоханулся фотограф. Если в студии фотограф почти не лажает, то когда светило солцне на экран, жало время и кончались батарейки, а сцена была сложной - хорошо если результат компромиссный. А то и FAIL бывает. И придя за большой компьютер фотограф делает фэйспалм.
> Угу, а реально показывают 6 бит :)
Ну это уж совсем свинство, да и чревато, потому что повышенную битность обычно хотят те кто работает с графикой а их обдурить в их же области сложно и чревато очень плохой репутацией.
> Даже честные 8 бит есть далеко не всегда.
Сейчас уже матрицы с честными 8 битов не такая уж экзотика и 6-битные остались вроде только в дешевых офисных мониторах и недорогих потребительских устройствах.
> Те исключительные мониторы, которые действительно умеют 10 бит
> стоят на порядок дороже обычных и в обозримом будущем вряд ли станут массовыми.
Мониторы для работы с графикой никогда и не были дешевыми. А почему не станут? Есть какие-то непреодолимые технологические проблемы делать 10 битов вместо 8? Ну вон IPS с разрешением в 4К и даже вроде честными 8 битами - не экзотика особо. И стоит уже не так дико. Вообще, 6-битные матрицы в сколь-нибудь дорогих мониторах и даже гаджетах уже начинают вроде постепенно считать чем-то неприличным и простительным только для офисных мониторов, дешевых китайских гаджетов и прочих геймерских мониторов которым 144 FPS важнее чем хорошая картинка и они согласны на мерзенький но зато быстрый TFT.
>> А что, выжмете столько из иксов? :)
> Иксам все равно какое разрешение и fps - главное чтобы железо справлялось.
Это шутка такая? В CRTC тормозить нечему: он долбит себе из буфера в дисплейный интерфейс, аппаратно. И это есть не только у могучих видеокарт но и даже у большинства малохольных SoC, с хоть каким-то контроллером дисплея. Поэтому если железо вообще декларирует какой-то видеорежим - оно с ним и справляется, в самом железном понимании этого слова. Если софт чего-то не успевает, CRTC если его не трогать, долбит на автомате. А вот успеть сгенерировать кадр и положить его до того как станет пора рисовать очередной кадр и CRTC начнет его долбить в провод - проблема на стороне софта. Правда в случае крутого 3D софтом могут и шейдеры на стороне GPU быть, а в сторону CPU это может вообще никогда не летать, но это другой вопрос.
А у иксов все данные толкаются через протокол и его парсер как умолчальный режим работы. Как это будет работать с такими гигазами данных - ежику понятно.
> Вот с битностью - да, придется дописывать. Но с учетом что
> иксы умеют от 8 до 32 бит, дописать 48/64 бита не проблема.
С freesync наверное еще больше проблем будет - вся инфраструктура изначально подразумевала постоянный FPS. А тут на тебе. И если низкоуровневые кишки DRM к этому наверное частично готовы, из-за того что там в процессе войны с тирингом сильно заморачивались с вещами типа precise timestamps и page flipping, когда CRTC просто переключают на другой буфер по мере его готовности, так что тиринг невозможен из-за того что CRTC рисует или из одного полного буфера или из другого, а перекидывается между буферами только если CRTC не рисует на экран (что убивает тиринг довольно кардинально), такое наверное и переменный FPS переварит. Но вот кто и как будет объяснять юзермоду что FPS на CRTC может быть переменным...
> Нет - на практике светлая область тоже шумная. А так да - идея интересная ;)
По моим наблюдениям шум заметнее всего в темных областях. В них мало что видно, с шумом проблема в том что он не похож на оригинал сцены, это все портит. А т.к. там мало что видно - размытие никто особо не заметит, можно более агрессивно сделать чем на светлых областях и тем более границах, где малейшее смещение камеры вызовет трудноустранимый и назойливый hosting. Наверняка до чего-то такого сто раз все доперли в "обычных" (space domain) денойзерах. То что вы описали больше всего похоже на time domain denoiser, чтоли. Почему бы таким подходам не работать и в этом случае? Заодно могу себе представить "3D denoiser". Несколько кадров по сути добавляют 3-ю координату, т.е. денойзер может потенциально считать значение точки не по 1D времени или 2D плоскости а по окрестностям точки в таком себе 3D. Я почти уверен что это тоже баян.
> Наоборот - при ярком свете оптический видоискатель в не конкуренции и выдает
> те самые 10-14 бит на канал (или сколько ваше зрение позволит) ;)
Оптический - может быть. Но я же не могу сохранить сигнал с сетчатки на SD карточку, даже если меня и устраивает. Сохранять будет камера, с матрицы, по параметрам которые фотограф дал. А это не то же что в оптическом видоискателе.
> Есть такое мнение, что многим "профессионалам" религия не позволяет использовать автомат/полуавтомат :)
У зеркалок и т.п. по моим наблюдениям на работу алгоритмов автоматики забивают сами производители. Этакий infinite loop: этим не будут пользоваться - нет смысла улучшать - плохо работает, невозможно пользоваться - никто не пользуется - нет смысла улучшать :). Корпоративщики экономят на оптимизации dead code, узкая каста прокачивает ЧСВ. Остальные часто получают паршивые фоты или пользуются хомяковыми устройствами.
> Тоже и с raw - получить из него картинку лучше, чем ее
> сделала камера в jpg - весьма не тривиальная задача, требующая знаний,
> времени и цветовой профиль камеры (про который "профессионалы" забывают/не знают).
У жыпега проблема в том что если случился какой-то продолб, исправить его потом ... ээ ... ну, я например, не умею хорошо вырубать шум приправленный жпеговскими артефактами. Да и остальные операции ограничены.
>> А что за программа?
> https://github.com/abadams/ImageStack
А, я мог бы и догадаться, в презентации упоминатся же.
> Это пока бета в разработке.
Да понятно что бета.
>> - Насколько это железо поддерживается mainline?
> ХЗ, но открытое - так что все решаемо.
Решаемость может быть очень разного уровня :).
> Не думаю - проблема современных камер, что они даже на HD видео
> перегреваются через 20-30 минут.
Странно. Там что, софтварный энкодер на куче ядер? У всяких более мобилкообразных в SoC чаще всего есть аппаратный энкодер. Битрейт/качество у него конечно не рекордное, но битрйта можно разрешить и побольше, а какого-то особого нагрева даже от FullHD я у мобильных девайсов вроде не замечал. Ну то-есть аппаратный энкодер конечно трескает электричество но меньше чем проц молотящий всеми ядрами. И как-то все это обходится без вентиляторов да и даже радиатор там "неявный" (BGA отводят много тепла через шарики в плату).
> Там есть слоты расширения - в них подключаешь нужный модуль (ssd/hdd/sd/eth/wifi/etc).
Ух, блин, этак оно большое и дорогое будет пожалуй. Я не собираюсь таскать с собой HDD или SSD чтобы пофоткать, это для маньяков. Но в целом выглядит довольно интересной штукой.
> Не знаю, но очевидно да - при заявленых параметрах без него просто не реально.
Мало ли, может они в FPGA собираются запилить. В общем это надо RTFM по этому SOC :)
