> Я не сказал, что он тyпо срезает лишние биты.Downsampler не подразумевает обязательно тyпую срезку битов. Бывают продвинутые и адаптивные. Но для darktable это - отнюдь не центр фичности. А фича "до кучи". Ну то-есть если вы попросите - вам сделают формат с пониженной битностью. А если попросите - получите EXR какой-нибудь, со всеми битами на месте.
Core часть этой программы - пайплайн, в который ставятся графические алгоритмы. Ну и обзор для выбора фото над которым измываться будем. И оно может вам сохранить и EXR со всеми битами которые оно отколупало, если вам это надо.
> При переводе из 32 в 8 бит, мы теряем динамический диапазон -
Для начала, рассуждения о битах идущих с матрицы - натыкаются на тот факт что зеленые пикселы матрицы как правило расшарены на 2 соседние ячейки. По поводу чего и требуется дебайер - специфичная конверсия такого странного формата во что-то более привычное. Этот процесс не является конверсией 1 в 1, поскольку в оригинальном материале "недостача" зеленых пикселей и это подразумевает некую интерполяцию. По этому поводу возможен узкоспециализированный набор алгоритмов работающих до дебайера. При этом алгоритм работает с тем странным представлением, где зеленые пикселы расшарены на 2 ячейки. Таких алгоритмов не сильно много. В DT таковым вроде как является raw денойзер, который по идее втыкается в pipeline до дебайера. Но в DT корректный порядок модулей - проблема программы. Юзер только выбирает какие модули воткнуть и какие параметры им вкрутить.
Есть несколько моделей матриц где это не так, но это узкие частные случаи. Почти все матрицы на планете используют вот такой странный формат данных.
Кроме того, 32 бита на составляющую - как-то зело круто. Может у суперкрутых матриц такое и бывает, но обычно вроде не более 16 битов на составляющую, а с учетом динамического диапазона - эффективных битов будет и того меньше. А потом еще дебайер, который должен раздать зеленый на всех, при том что исходно его была только половина.
Реально же фото с повышенной битностью, не влезающее в динамический диапазон монитора и 8-битных файлов обычно получается если склеить несколько фото обычной битности но с разной экспозицией. При этом цифро-аналоговое преобразование делается на разных рабочих участках, уделяется внимание и слабым сигналам, и средним, а потом и корректному сохранению самых интенсивных сигналов. По поводу чего и делается несколько кадров с разной экспозицией, серией. Так можно получить существенно более высокий динамический диапазон и битность сигнала. Правда такое фоткать лучше со штативом, иначе от тряски картинки будут плохо состыкованы. Лечится enblend+enfuse (или hugin, который их на автомате дергает) но идеально состыковать серию без штатива - достаточно утомительно, а результат не всегда радует глаз (проблемы с резкостью контуров от неидеальной стыковки).
> соответственно нужен софт который позволит выбрать интересующие нас участки диапазона,
Tonemapping - далеко не основное занятие DarkTable.
> Затем экспортировать все это с дитеренгом.
DarkTable может записывать результат и в файлы типа EXR, с полной битностью. Как вы там дальше их будете обрабатывать - уже не его проблема.
> То, что darktable имеет базовую функциональность редактора,
Он не имеет функциональности редактора. Он не может открыть ранее сохраненный собой файл, отрихтовать его и записать снова. Он работает иначе.
Он заводит в пару к RAW файлу файлик с описанием трансформаций. И на лету выполняет прописанные там преобразования с теми параметрами которые там указаны. Колупание в гуе меняет только этот файлик-спутник с описанием. То-есть редактирования как такового и нет.
Задача пользователя при работе с DarkTable - воткнуть нужные модули в пайплайн и вкрутить им правильные параметры. Что в сумме позволяет сделать "конфетку" из "гoвна", при условии что в raw для этого было достаточно материала (выбитые в ноль или единицы пикселы невозможно восстановить по очевидной причине, что заставляет фотографов ругаться при виде высоконтрастных сцен).
> говорит о том, что:
> 1. некоторые алгоритмы могут быть более эффективными на не обработанном изображении
> (шумодав ориентированный на проблемы конкретных матриц).
Для начала, шумодав работающий до дебайера имеет одну редкую привилегию: ему доступны данные в их нативном виде. Дебайер подразумевает интерполяцию. Что несколько понижает точность работы алгоритмов за ним. Но т.к. алгоритмы должны быть готовы столкнуться с странным форматом данных, где зеленый лишь один на 2 пикселя - таковых алгоритмов немного. Тем более что некоторые матрицы используют иное нативное представление данных, в зависимости от их фактического устройства. Для них иной алгоритм конверсии (if any) и все алгоритмы работающие до этого конвертора опять же надо переписывать. Что не вызывает бурного энтузиазма у програмеров по понятным причинам.
> 2. пользователи хотят на выходе получать готовый LDR для отправки в интернет/печать/фотоархив.
Как уже сказано, там есть и экспорт в EXR. Как таковой downsampling и tonemapping - далеко не основное назначение этой программы и оно там лишь до кучи. Для этого есть более специализированые программы, где все это намного фичастее и навороченнее. И которые на самом деле актуальны тем кто клеит HDR из серий. На единичном кадре динамический диапазон камеры обеспечивает "отсутствие" такой проблемы. Если конечно вас не смущают "все единицы" и "все нули" на высококонтрастных сценах. За что "цифровые" фотографы не любят жесткое освещение еще больше чем "пленочные". Нормально снять контрастную сцену можно только в HDR, а это заявка на использование штатива. Ибо клеить HDR фото из кадров где тряска - весьма утомительное начинание.
> Назвать можно по-разному. Как правильно назвать программу, открывающую один формат,
> позволяющую ручную правку и сохраняющую, но в другой формат?
В данном случае это конвертор/транскодер с продвинутостями и фильтрами. Пайплайн процессинга картинки модулями, в общем. С выбором модулей которые воткнуть в пайп и их параметров. При работе с DarkTable пользователь должен выбрать правильные модули и вкатить им желаемые параметры. Маски - тоже параметры модулям, пожелание к конкретному модулю работать не по всей площади а лишь по заданному региону. Это рантайм настройки модуля по процессингу исходника. А вовсе и не данные картинки.
Кроме всего прочего, такая пайплайновая сущность программы позволяет взять пайплайн которым обработано одно фото и одной левой вкатить те же настройки другому фото с подобными проблемами. Очевидно, если трансформации не специфичны для того фото (а какие настройки модулей включить в "стиль" - выбираемо) - фото с подобными проблемами отлично пролечивается подобными же трансформациями. Что сильно сокращает время их обработки и позволяет начать пляс от намного более удачного варианта картинки чем изначальный. При похожих условиях съемки пайплайн от одного кадра может без изменений подойти к другому и дать очень приличный результат сразу.
> Какая разница, что программа делает внутри с данными?
В данном случае - гигантская. Во первых, вся работа с DarkTable - это выбор правильных модулей в пайплайн под конкретную ситуацию и твик параметров этих модулей. Понимание этой логики делает работу с программой простой и логичной. И круто экономит время на процессинге фото, позволяя делать осмысленные действия целенаправленно ведущие к желаемому рузультату. Типа применения одного "стиля" (шаблон настроек пайплайна в который включены настройки модулей) к пачке фотографий с похожими проблемами и условиями съемки, что позволяет здорово сократить время на твик модулей. Ведь если фото с более-менее одинаковой экспозицией и проблемами - то одни и те же трансформации дают похожий результат.
> Важно ведь то, что мы получаем на выходе.
Экспорт - завершающая стадия работы в DarkTable. Это потенциально lossy процесс, подразумевающий что далее работой с результатом если и будут заниматься программы, то уже другие.
> Никто не будет использовать raw+xmp как конечный результат.
Естественно. Это лишь оригиналы и настройки их процессинга через пайплайн. Ну примерно как настройки тому или иному кодеку при пожатии несжатого видео. Только у кодеков процесс обычно не подразумевает интерактивность и визуализацию, а тут поскольку кадр всего один - ему куча внимания и возможность покрутить настройки модулей пайплайна так и сяк, наблюдая сразу результат.
> Это лишь промежуточное сохранение.
DarkTable не умеет вносить изменения в графические файлы как таковой. Он умеет делать из входных данных выходные на основе данных файла-спутника с описаниями трансформаций. Пайплайн в чистом виде. А хоть и с визуализацией. По этому поводу в нем никогда не будет многих фич ожидаемых от редакторов. Этот дизайн заточен на работу с массивом данных, проталкиваемых через модуль. А возможность применить модуль не ко всей площади - вообще-то КОСТЫЛЬ, когда модулю как параметры отдают еще и рабочий регион. Это объясняет и то почему авторы DT очень долго отбрыкивались от реализации этих фич - они чужеродны исходной логике работы этой программы.
> Да для некоторых специфических задач HDR может быть конечным результатом.
RAW != HDR, для начала. Это довольно разные сущности и единичная равка как таковая обычно не считается HDR, даже не потому что биты, а потому что динамический диапазон камеры. И никаких особых средств для HDR в DT я что-то не увидел.
> включать все преобразования, дабы другие программы корректно его отображали.
В DarkTable все что касается этих преобразований - крайне минималистично. Я так понимаю что подразумевается что если вам реально надо tonemapping и при том почему-то на единичной равке (у вас такая крутая камера что динамический диапазон единичного кадра шире 8 битов на составляющую?), то подразумевается что вы сохраните нечто типа EXR и дальше возьмете более специализированные тулзы. Где по части tonemapping и прочего настроек в 20 раз больше чем в DarkTable, так что результат tonemapping потом не будет вызывать фэйспалм. Но вообще эта проблема интересует любителей HDR, клеящих несколько кадров с разной экспозицией в один. С DarkTable эта активность пересекается достаточно слабо.
> У меня есть еще более интересный пример luxrender. У него свой формат
> - flm (32 или 64 бита, не помню). В него он сохраняет все, что рендерит.
Круто. И чего?
> пользователя. Но в конце естественно все сохраняют результат в png (8
> или 16 бит).
Отлично. А что, luxrender - редактор? Название вроде намекает на то что это - рендерер, средство рендеринга.
> Blender (и 3dsmax) тоже позволяют применять модификаторы к объектам как деструктивно, так
> и цепочкой с возможностью изменения настроек в любом из звеньев.
Отлично, а теперь экспортируем какой-нибудь мувик с крутящимся в 3D допустим кубиком. А потом пробуем открыть этот мувик в блендере или максе и что-то там сделать с кубиком. В этом месте мы начинаем догадываться что формат кое-что все-таки решает. В данном случае - в мувике нет никакого "кубика". Ну и параметры вращения этого кубика или там освещение вы уже не поменяете. Поэтому обработка видео - это что угодно но только уже не редактирование 3D сцены. Ну и софт для работы с видео - не редактор 3D и все тут. Просто потому что не может вынуть кубик из сцены и отредактировать его параметры. А оперирование другими параметрами, например "от вон того кадра отличается этот и этот блок" - не имеет отношения к изначальному объекту "кубик" вообще ни разу.
Ну вот когда вы сохранили жпег - в нем вы уже не переиграете там параметры дебайера, а факт сжатия с потерями сильно ограничит и иные возможности коррекции. Не говоря о том что настройки пайплайна теряют всякий смысл - переиграть их уже не получится. Ну как вы не можете изменить в видеопотоке освещение вращающегося кубика, потому что в видеопотоке никакого кубика нет и есть только массив пикселей. Иное представление. Получаемое из оригинала необратимыми трансформациями, подразумевающими потерю некоей информации.
