Свежие комментарии

Это InnoSetup

Проблема защиты меня будет волновать месяца через два. Да и то, я думаю что не будет.

Это Armadillo? Они все такие, видимо. Плюс они имеют тенденцию вдруг умирать, или отсрачивать компатибилити с новой OS на годик-другой.

Так у вас значения черного будут сохранены в кармане - вычитай не хочу

Ну а как сделать вычитание нулей после дебауризации, если вот например, хочется?

А то, допустим, есть пиксель -2, сосед +2. Логично, что между ними должен быть "0". А если вычитать сначала - будет "1".

Не нужен для этого флаг.

Сохраните в карман imgdata.rawdata.color.black/cblack, а эти поля - обнулите.
Вот вам и невычитание.
А потом - восстановите. в imgdata.color - по желанию, в imgdata.rawdata - обязательно

Я же писал вчера про это.

raw2image_ex и так перетяжелена, не надо бы туда больше ничего добавлять.....

raw2image_ex делает сразу
- распихивание в image[]
- вычитание черного (кроме PhaseOne)
- поворот для Fuju (если Fuji)
- кроп.

raw2image - именно для тех, кто хочет raw-данные в старом (4 слоя, 3 элемента в каждом пикселе - нули) формате.

Вот например в примере 4channels именно оно, чтобы переписывать этот пример поменьше :)

Ну так сейчас в imgdata.rawimage[] - "как оно у камеры", а после raw2image() (не _ex) - 4 плоскости с заполненным одним элементом. Как нравится, так и кушай.

Реально идея что кому-то нужны RAW-данные оказалась очень оптимистичной. Да, нужны, но таких программ мало. Почти все пользователи - используют постпроцессинг (и огорчают этим меня)

Ну хочется какую-то стройность соблюдать, иначае для float так, для этого эдак, короче, жесть.

Скажем, есть raw2image_ex - его не планируется сейчас исключать из кода?

В таком случае, либо сделать копию raw2image_ex_f, либо сделать параметр.

То есть, в идеале, вот есть libraw, он как должен данные выдавать? В хелпе написано "в том варианте, как попросит пользователь, один бауер, 4 канала, 4 плоскости, но сейчас только так.

Там же написано :)
Если заказано половинное разрешение - делает его.
Если не установлено four_color_rgb - копирует второй зеленый канал в первый там где надо.

Ну да. Но я зацепился глазом за флаги декодера - а они описывают то, что в imgdata.rawimage.

На мой взгляд, надо делать вызов *вместо* dcraw_process (назвать его process_fp(), например).
Результат, да, класть в imagef[][4] или что-то подобное.

В этом случае нужно обязательно переписать вычитание черного, scale_colors() /если нужна/, pre_interpolate(), какую-то интерполяцию, convert_to_rgb() ну и какой-то вывод в 16 бит: dcraw_mem_image() или писалку тиффов-PPM. Лучше, конечно, обе.

Более того, можно вообще начинать только с интересных вам видов байера (самых простых, как у canon), а на неинтересные честно говорить "не поддерживаем, извини".

А все что вам лично не нужно - не переносить в новый пайплайн. Пущай волонтеры поработают, если кому надо.

В смысле, придумать такой "декодер", который выдает все в float?

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

Так. У меня такие предложения. Добавить вот это:

unsigned int imagemode;
ushort (*image) [4];
float (*imagef)[4];

LIBRAW_DECODER_FLOAT = 1<<5,
LIBRAW_DECODER_DONOTSUBBLACK = 1<<6,
LIBRAW_DECODER_ALLOWNEGFLOAT = 1<<7,

Ну и переделать код raw2image_ex. Кстати, заодно поправив, чтобы внутри цикла умножения не встречалось, если уж есть желания чтобы оно быстрее работало.

По умолчанию ничего не изменится, а для меня ну и для желающих будет всё, что нужно.

В смысле, я готов это всё переписать, если архитектурных нет противоречий.

Идёт?