Итак, поковырявшись немного с libraw, я плюнул: разобраться в недрах такого бешеного количества кода просто нереально! Поэтому пока выбираю более медленную, но все-таки работающую "Self Similarity Driven Demosaicking". В принципе, цветопередача получается вполне нормальная, я вывел на монитор эту картинку и после обработки получил:
Саму утилиту тоже чуть подправил: добавил простой "калькулятор экспозиций" (надо его по звездному небу проверить, в комнате он давал сходимость на 3-5 итерациях). К сожалению, авторы вышеозвученного метода дебайеризации не разрешают выкладывать измененный вариант своего кода — только пользоваться в научных или академических целях. Саму утилиту я чуть изменил: добавил туда работу с libgd, при ее помощи собственно загружаю tiff и сохраняю цветной jpeg с отметкой времени. Чтобы не мучиться с fits-файлами, я в утилите sbig340 при сохранении файлов модифицирую mtime так, чтобы оно соответствовало времени начала экспозиции. Его и вывожу на изображение. Если будет необходимо выводить еще и длительность экспозиции, придется сохранять выхлоп в FITS (возможно, для поиска звезд tiff'а не хватит).
В принципе, получилось вполне KISS и юниксвейно: одна утилита собирает изображения, другая генерирует цветную картинку. Возможно, будет еще и третья, считающая процент облачности. Автоэкспозицию думаю возложить на самого демона, работающего с камерой. Допишу, как будет время, "демонизатор". Думаю, на первых порах пинать его снаружи нет необходимости — пусть будет "демон в себе".
UPD вытащил камеру в окно. Жаль, что с макетных мастерских светит хороший фонарь, но уже по кадрам понятно, что для звездного неба надо будет немного переиначить алгоритм вычисления оптимальной экспозиции: попытка впихнуть медиану в примерно середину диапазона приводит к конкретному пересвету. Как пример — три экспозиции:
Экспозиция 20 секунд
Экспозиция 30 секунд
Экспозиция 50 секунд
На третьем кадре мимо проехала машина, а Венеру затянула туча. Марс с Венерой лучше всего видно на втором кадре.
В общем, нужно брать камеру, и ехать подальше от засветки. Ну или допиливать все непосредственно во время эксплуатации (этот вариант ближе к реальности, т.к. сколько же all-sky у меня в кабинете будет стоять? Народ требует зрелищ!).
Начинаю думать, что скоро современное искусство целиком уйдёт в инженерную область. Там и смысл есть и эстетика вполне соответствует. Картинки кстати тоже красивые.
У меня "современное искусство" ассоциируется только с размазанными по стенам экскрементами и прибитым к брусчатке гениталиям. В прошлом году у нас в поселке была "выставка". Экскрементов в чистом виде, к счастью, не было, но "говна и палок" хватало.
Дык, вот и интересно: как сообщить библиотеке, что у меня сырые некодированные uint16_t в порядке BGGR. Хотя, на фоне 1-2минутных экспозиций те 4-5 секунд, что работает дебайеризатор — фигня.
А изображение переворачивать на 180° (чтобы был не BGGR, а RGGB), а потом обратно? Или все-таки есть интерфейс для задания порядка фильтров в квадрате?
Ну вот такую же строчку (строчки) можно прицепить к imgdata.params.custom_camera_strings (это char **, соответственно последняя строчка в этом массиве должна быть NULL) И дальше оно типа само.
Но там есть бага, там срабатывает по последнему размеру, а не по первому (а custom - обрабатываются первыми), поэтому кодак все едино придется убирать.
Формат строчки описан тут: https://www.rawdigger.ru/usermanual/preferences (последний раздел, Поддержка нестандартных камер)
Но если через недельку пнете по E-mail (или ответив на этот комментарий) - будет ОК. Я со срочным скорее всего разделаюсь, а делов то там - ну на пару часов отсилы, скорее меньше.
В прыдущих постах казалось, что артефакты на картинках у вас создаются на этапе дебайеризации. Но проблемы, наверное, возникают на каком-то другом этапе.
Вот эти места выглядят ненормально: https://i.imgur.com/hVNVMOj.png
Напоминает проблемы блокого кодирования. Но у вас джипеги приличного уровня сжатия (quality = 90, YCbCr4:4:4). И если исходник был бы качественный, то такие артефакты не должны были появиться.
Простые "горячие пиксели", которые сбивают с толку алгоритм. Специально сравнил jpeg с tiff — там то же самое. Еще на матрице несколько битых пикселей есть. Но за ту цену, что ее купили (в интернете 2.5 килобакса, значит, после растаможки и накладных все 5 получилось) это нормально. Даже за 10 килобаксов чипы хреновые.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
no subject
no subject
В прошлом году у нас в поселке была "выставка". Экскрементов в чистом виде, к счастью, не было, но "говна и палок" хватало.
no subject
no subject
no subject
С этим проблем у топикстартера нет.
Демозаики и прочего постпроцессинга в rawspeed нет.
А как декодер - отличная библиотека (libraw умеет ее использовать в качестве декодера)
no subject
no subject
no subject
no subject
no subject
Формат данных там - YCbCr. Из экономии, вероятно.
no subject
no subject
no subject
no subject
И LibRaw::open_buffer()
no subject
no subject
Можно еще ручками imgdata.idata.filters задавать (менять)
no subject
no subject
прицепить к
imgdata.params.custom_camera_strings (это char **, соответственно последняя строчка в этом массиве должна быть NULL)
И дальше оно типа само.
Но там есть бага, там срабатывает по последнему размеру, а не по первому (а custom - обрабатываются первыми), поэтому кодак все едино придется убирать.
Формат строчки описан тут: https://www.rawdigger.ru/usermanual/preferences
(последний раздел, Поддержка нестандартных камер)
no subject
no subject
Ее основное назначение - разбирать файлики (и не только данные, но и всякие EXIF/etc) от "настоящих фотокамер"
Сама по себе дебайеризайция - не проблема. Ну возьмите OpenCV
no subject
no subject
То есть вот интерфейса вида "open_bayer" не хватает.
Всякие писатели обработки с андроидных камер - будут рады.
То есть вот надо дать возможность собственно ту же "строчку", но задавать через API. Те же ~15 параметров.
Я приделаю, но сроков не обещаю, потому что как-то вот совсем другим занимаюсь.
no subject
no subject
Мне особо не горит. Если будет интерфейс в официальной ветке, так вообще будет здорово!
no subject
На самом деле - просят примерно пару раз в год.
no subject
Вот эти места выглядят ненормально:
https://i.imgur.com/hVNVMOj.png
Напоминает проблемы блокого кодирования. Но у вас джипеги приличного уровня сжатия (quality = 90, YCbCr4:4:4). И если исходник был бы качественный, то такие артефакты не должны были появиться.
no subject