> Core часть этой программы - пайплайн, в который ставятся графические алгоритмы.

Иными словами недеструктивный графический редактор.

> Кроме того, 32 бита на составляющую - как-то зело круто. Может у
> суперкрутых матриц такое и бывает, но обычно вроде не более 16
> битов на составляющую, а с учетом динамического диапазона - эффективных битов
> будет и того меньше. А потом еще дебайер, который должен раздать
> зеленый на всех, при том что исходно его была только половина.

Это понятно. Я имел ввиду, что напрямую с raw и сам darktable работать не будет, а сперва сконвертирует raw - в 32 бита на канал. Потом уже будет вся остальная обработка.

> Реально же фото с повышенной битностью, не влезающее в динамический диапазон монитора
> и 8-битных файлов обычно получается если склеить несколько фото обычной битности
> но с разной экспозицией.

Вы хотите сказать что 12-14 бит матрицы влезают в 8 бит монитора без потерь?

> Tonemapping - далеко не основное занятие DarkTable.

Всегда полагал, что это неотъемлемая часть при приведении raw к нормальному виду.

> Он не имеет функциональности редактора. Он не может открыть ранее сохраненный собой
> файл, отрихтовать его и записать снова. Он работает иначе.

http://www.darktable.org/about/features/
Import a variety of standard, raw and high dynamic range image formats (e.g. jpg, cr2, hdr, pfm, .. ).

>> 2. пользователи хотят на выходе получать готовый LDR для отправки в интернет/печать/фотоархив.
> Как уже сказано, там есть и экспорт в EXR. Как таковой downsampling
> и tonemapping - далеко не основное назначение этой программы и оно
> там лишь до кучи.

Тогда к чему весь это pipeline, если достаточно конвертера raw->exr?

> Для этого есть более специализированые программы, где
> все это намного фичастее и навороченнее.

Огласите весь список, пожалуйста! Естественно только opensource.

> И которые на самом деле
> актуальны тем кто клеит HDR из серий. На единичном кадре динамический
> диапазон камеры обеспечивает "отсутствие" такой проблемы. Если конечно вас не смущают
> "все единицы" и "все нули" на высококонтрастных сценах. За что "цифровые"
> фотографы не любят жесткое освещение еще больше чем "пленочные".

ИМХО тот же спор, что и "лампа vs транзистор", "винил vs cd"  - в одном случае мягкий клипинг в другом жесткий. А реальный динамический диапазон у всех примерно равен, да и запас приличный (при нормальной реализации).

>[оверквотинг удален]
> отличается этот и этот блок" - не имеет отношения к изначальному
> объекту "кубик" вообще ни разу.
> Ну вот когда вы сохранили жпег - в нем вы уже не
> переиграете там параметры дебайера, а факт сжатия с потерями сильно ограничит
> и иные возможности коррекции. Не говоря о том что настройки пайплайна
> теряют всякий смысл - переиграть их уже не получится. Ну как
> вы не можете изменить в видеопотоке освещение вращающегося кубика, потому что
> в видеопотоке никакого кубика нет и есть только массив пикселей. Иное
> представление. Получаемое из оригинала необратимыми трансформациями, подразумевающими
> потерю некоей информации.

Нет, неверная аналогия - blender, max и другой софт умеет pipeline для объектов и позволяет как обычное (деструктивное) редактирование, так и не деструктивное (но не для всего, а только для модификаторов объекта).