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

ну тогда ловить нужно вообще всё catch(...) - прийти от пользователя ведь что-угодно может, а выпускать наружу, как я понял нельзя

Точнее, bad_alloc вообще до кучи появилась.
А избежать (возможных) ексепшенов в IO-layer (который может быть подменен пользователем) - через nothrow все едино нельзя.

1) в смысле как часто? если часто, то эту chain можно преобразовать
2) Почему? Возможные проблемы с ABI?
3) раз exceptions нежелательны, то например есть nothrow new: http://www.cplusplus.com/reference/std/new/nothrow/
char* p = new (nothrow) char [1048576];
имхо более эстетично, чем делать new прям в try/catch(std::bad_alloc)

Дык говорю же, OpenCL-код тестировать (и профайлить). На AMD и NVidia.

src/libraw_cxx.cpp
пара вопросов :
1. LibRaw::get_decoder_info не часто вызывается?
2. смешаны exceptions и return codes - в итоге приходится заниматься и тем и тем. зачем? Ведь для C-api есть libraw_c_api.cpp, сюда и можно напихать try/catch

дык оно вообще всё "кастом" - материнка какя-то левая, слотов расширения нет вовсе и даже БП собран "он боард" + водяное отопление охлаждение.

...но компоновка любопытная, да-с.

>> Да, странного - потому что идея что 3.5" не нужны еще не проникла в мозги. <<
Правда, что ли ?? :-))

для меня страным является желание воткнуть "крутую видяху", понатыкать "по углам" приводов, утрамбовать это всё в коробку от конфет туфлей и засунуть "в шкаф".
...и чем NAS не устраивает тоже непонятно.

>> ...Конечно, при таком расположении БП в верхнем-заднем (для башни) углу ставится отдельный вентилятор на выдув... <<
Ну да, и никто не ставит "напротив БП пучок" приводов... и "10-12 отсеков под 3-5" у них получаются "автоматически", причём если присмотреться, то это "отсеки" не под приводы, а под вентиляторы.

в общем, непонятно чего ты колбасишься и чего хочешь, но выглядит забавно ,-)

На текущий момент (до импорта свежей dcraw), из существенного:
- возможность поканального задания уровней черного
- Только в Win32: LibRaw::open_file (wchar_t *) т.е. возможность открывать файлы, имя которых задано в виндовой уникодной кодировке.
- 'Sony ARW2 hack' - возможность выключить деление на 4 для данных, раскодируемых из Sony ARW2.
- проковыряны дырки (сделаны вызовы), чтобы наиболее медленные фазы постпроцессинга можно было пере-имплементировать в производном классе более быстрым способом (SSE, многопоточность).

Все сделано для RawDigger, вестимо

Если используется libraw.so.5 - то катит.
Если сложнее - то не катит :)

Ну вот к примеру AHD: строится приблизительная homogenity map, и значение компонента берется (с бОльшим весом) с той стороны, которая более гомогенная. А где именно будет синий пиксел справа от текущего синего - через один или через полтора - какая хрен разница.

С ложными же цветами - шансов попасть в строго вертикальную/горизонтальную полосатость с шагом в пиксел - на практике немного.

И с ложными цветами, как я понял -- в любой горизонтали и вертикали есть все цвета.

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

А в каком смысле "не байера"? Там паттерн размером 6x6, повторяющийся. А в других камерах бывает 8x2, а у Leaf CatchLight - 16x16. А в каждом пикселе одно значение, а еще 2(3) не хватает, надо интерполировать. Не вижу разницы.

А паттерн такой, на мой взгляд, не для "демозаика", а для борьбы с муаром.

Или в цитсире нашлась PhD по такому паттерну со всеми алгоритмами, на основе которой Фуджи это и придумала, взяв на работу автора? :)))

Гы!

На самом деле, оно очень клево написано в том смысле что компактность превыше всего.
RawSpeed, к примеру, в полтора раза больше кода, вдвое меньше список камер и только распаковка, без постпроцессинга.