>> Легко представляю. Выгружаем в равку данные с камеры, прямо в байеровском формате.
>> А дальше вот прямо на байеровском формате и оперируем. _ДО_ процедуры дебайера.
> А смысл?Я про процессинг равок. И это вообще-то уже на стороне dark table или подобных софтин должно происходить. Ну это если raw обрабаьывать и рассматривать workflow в целом.
> И вы серьезно полагаете, что в адройде с этим кто-то будет возится?
Хорошая опечатка :). Честно - не знаю как в "ад"роиде. Но от него на самом деле требуется с рыбью ногу: сдампить отсчеты матрицы как видеть и не выделываться. Остальное сделает darktable. Поэтому на самом деле если raw обрабатывать то единственное требование чтобы сдампили сигнал с минимумом художеств. Остальное сделает софтина типа сабжа, в чем собственно и пойнт. А вот если они дампануть сигнал с матрицы с минимумом художеств не могут - ну тогда вся идея и накрывается медным тазом. В случае RAW чем меньше процессинга на стороне камеры - тем лучше, блин. Потому что цель всего этого прогнать весь пайплайн самому и лучше или просто иначе чем нечто вшитое в image processor или что там у кого. Да, у многих ведроидов есть image processor в SoC с "улучшалками". И вот эти "улучшалки" может и делают жыпег для хомяков лучше. Но вот если кто хочет raw отпроцессить, ему это ну совсем не в кассу. Потому что отольется где-нибудь дурными артефактами. Софт обрабатывающий raw ожидает нормальные отсчеты с матрицы, а не всякие художества. И алгоритмы все пишутся под эти допущения. А когда это не так - начинаются дурны приколы с странными артефактами.
> Они даже в jpeg нормальный шумодав реализовать не могут - при нехватке света
> тупо занижают темные участки превращая их в черноту.
В андроиде вообще фото реализованы как-то странно. До неких пор оно raw совсем не умело в своем горбатом ява-апи. А потом вроде сделали но опционально и я понятия не имею что ведро делает до того как равку выгрузить. И насколько эта равка именно дамп того что на матрице было без художеств image processor в soc и прочих веселий. В image acelerator soc может и шумодав в принципе быть. И прочее масштабирование под видоискатель в реалтайме. Но понятно с каким качеством. Хотя это очень от SoC зависит, акселераторы этого самого каждый лепит и юзает в меру своей дури. В n900 fcam достаточно умен чтобы выгрузить именно то что от него хотят: raw с минимальным процессингом. Такой raw неплохо обрабатываеся.
>> Как я понимаю некоторые модули DarkTable именно это и делают,
> AFAIK только для выкидывания битых пикселей.
А raw denoise не на RAW оперирует? Он вроде для жыпегов совсем недоступен становится. Да и вообще, если жыпег вышел с шумом то это факап, DCT в целом плохо относится к ВЕНЗАПНЫМ изменениям.
> Я думал что вы про аппаратную реализацию в контроллере матрицы.
Нет, я про processing pipeline когда с матрицы вынули RAW и загнали таки в сабжа. А с матрицей бывает по разному. Во первых некоторые мобилочные камеры бывают довольно умные и могут поумничать на своей стороне линка, еще до контроллера. Но там настраивается по чему-то типа i2c что камера должна делать. Что она может и как она картинку будет грузить зависит от конкретного модуля AFAIK. В целом ему заказывают по i2c желаемый формат и он долбит по основной жирной шине в нем. Если там будет байер - ну значит байер. Этого байера можно софтом ухватить. Во вторых - сам по себе контроллер камеры в SoC обычно довольно глупая железка, типа display controller (CRTC), только в обратную сторону. И сам он никакого процессинга не делает. Если прямо на его стороне вынуть - получите то что сенсор отгрузил (какой там в модуле камеы процессинг - второй вопрос). А акселератор обработки картинок обычно отдельная железка в SoC и софт перекидывает картинки с камеры в акселератор а тот делает heavy lifting.
Хотя бывают и более чудесатые штуки. У техасских инструментов вроде как целый сервисный проц с своей фирмварой занимается такими вещами и он в принципе и сам может своим кодом утянуть картинку с камеры и запихнуть в хардварный аксель. Может и еще кто так делает. Но все-таки контроллер камеры и аксель - две разные периферийные железки. Даже у монстров типа техаса.
> Никогда не видел шумодава не убирающего цветной шум и добавляющего тонкую сетку.
Я про те артефакты которые вы мне показывали в другом треде, где на чем-то типа травы какие-то цветные пятна довольно крупноблочной природы.
> Да и как я сказал - у меня на смарте сходная
> структура шума из raw - хотя софт и железо совершенно другое.
> ИМХО это какой-то артефакт самого байерового фильтра.
В принципе возможно. Но вообще на том же n900 я вижу вроде вполне обычный такой шум. Как у всего остального, только сильнее ессно. В отличие от зеркалок шум начинается уже на iso 200...400 наверное. Поэтому да, звездное небо этим не пофоткаешь. Вот матрицу чуть побольше и объективчик посветосильне но без превращения в мегамонстра с проприетарными алгоритмами и килограммом стекла было бы прикольно. Ну по типу action camera современых, только с уклоном больще в фото и без стремной проприетари :)
> Не, когда темно - сразу видно по экрану - падает fps и
> вместо темных полутонов - черный.
Это врубился шумодав усредняющий несколько кадров скорее всего. Но ниоткуда не следует что он врубается при первом намеке на шум. Поскольку он роняет FPS и выдет к размазне - его врубают только когда иначе уже ну совсем никак. Ну как, если вы усредните несколько кадров а юзер трясанул рукой - понятно что будет.
> Я о том и говорю (http://knk.square7.ch/debayer). Сравните good.png и bad.png - разница
> один флаг при обработке dcraw (-f Interpolate RGGB as four colors).
Вот я про эти картинки. У вас даже "good" картинка содержит какие-то странные зеленые пятна на стеблях как будто там был шум его жпегом пожали пополам с плохим шумодавом. Может это конечно нехватка битов или какие там ошибки дискретизации, но при таком осещении их вроде бы и быть особо не должно...
