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

То есть надо сделать какую-то популярную фриварь - и будет счастье?

> это означает, что потом их Windows Update обновит при обнаружении каких-то security-проблем в них. Что полезно.

По-моему это абсолютно бесполезно. Вот совсем.

А запутаться в версиях DLL-ей и перестать работать для 20% юзеров - запросто случится.

> и даже больше чем MSIE (который основные потроха держит в системе).

Правильный, хотя и не для всех ход - уметь пользоваться тем, что уже есть в Виндах. А тем, чего нет - не пользоваться, ограничивать себя. У меня весь UI на всех работах уже несколько лет построен на IWebBrowser (см. пару статей в моём ЖЖ). Это значит, что если в системе есть IE6 (а он есть всегда), у меня программа размером 150K делает красивенькие кнопочки с картиночками, тулбарчиками и всякой такой фигнёй (ну HTML-же). И переносится под WebKit лёгким движением руки. Ну собственно оно лёгким движением руки переносится в чистый Веб и становится онлайн-приложением (сервер на чистом C).

А вот всякие уроды типа Гугла для тех же примерно целей всю фрибсдю с собой носят.

Ещё важно все .exe-шники проверять всегда на VirusTotal.com.
Там должен быть строго 0 срабатываний.
Если не 0 - Гугла обзывает вредным сайтом в поиске, что дико вредно для продаж, и есть подозрение, что M$ тоже это учитывает в своих пакостях.

99% всех баг в zlib меня абсолютно не касаются. Они же аффектят какие-нибудь мультитомные 64-х битные архивы с именами файлов в юникоде. А у меня она, например, распаковывает 2048 байт в буффере в памяти, которые сама же и запаковала.

Некоторые мои знакомые шараварщики компилируются VC6. И это, в целом, разумно, хотя я так не могу, меня тошнит.

> При этом, меня больше волнуют легальные юзеры, которых никак нельзя обижать зазря.

Угу. И по-моему это легче обеспечить, если твоя защита писана на коленке и влазит на экран.

> А вот скажи еще, а ты честно купил у MS (VeriSign) ключ, которым все подписываешь или забил на это все?

Я раньше не покупал, потому что было ненужно. А теперь, видимо, куплю через месяц-другой, чтобы облегчить страдания с IE9, которые ещё усиливаются в W8. Верисайн продает за $100 на год с купоном, см. swrus и гуглу.

Дело не в отдельных алгоритмах, а во всем пайплайне.

Там, на самом деле, и дела относительно немного (кроме, быть может, переноса всяких демозаик и demosaic packs) и дело само по себе - благородное.

Но. В свое время (давно) я попытался спроектировать библиотеку-raw-конвертор. Т.е всю из себя такую гибкую, чтобы в любую стадию можно было встроиться (а иначе нет смысла) - и получается что а) надо навязывать свою идеологию б) гибко и эффективно - антонимы.

Ну я поплакал в углу и зарекся постпроцессинг в dcraw трогать содержательно.
Т.е. тот же плоский RAW-буфер понадобился мне лично - ну я его и сделал совместимо с этим кодом. А в сам код - не полезу, хотя от контрибьюторов приму с удовольствием.

А архитектурно можно как угодно, можно даже не убирать за собой, recycle() всю память выделенную через calloc/malloc подберет (но при последовательных вызовах с разными параметрами - не подберет и все распухнет)

У меня все функции работают с плоским буфером, просто нужно флаг поставить, так что тут переделок мало.

Ну, если архитектурно так можно, то пожалуйста, могу сделать и так.

Но у меня есть встречное предложение. Можно ли сделать эту функцию, чтобы она задавала выходной формат данных, и уровень предобработки (удалять черный/нет)? Скажем, тут же решается вопрос с float, пожалуйста, сиди пиши свой raw конвертер.

И пожалуй этот способ - более хакерский, но более простой.

Обнулять (сохранив значения) надо в rawdata.color.black/cblack[]
А восстанавливать после raw2image_ex - в rawdata.color и imgdata.color

Ну самый разумный вариант, на самом деле, это встроиться *до* raw2image_ex и ковыряться прямо в raw-буфере.

Ну то есть
- аллоцировать себе плоский буфер (а не 4 компонента)
- порезвиться там (и тогда вам все эти ужасы вроде своих макросов для байера не нужны), копируя данные из сохраненных raw
- подменить указатель на буфер перед raw2image_ex
- освободить буфер и вернуть указатель после raw2image_ex()

При этом черная рамка тоже доступн (в отличие от работы с image[]). Проблема в том, что для разных камер информативная часть там может быть сильно разной

Ну, хорошо, можно сделать удаление черного только при флаге? И ставить этот флаг или сбрасывать?

Я, кстати, хотел попробывать написать удаление "по черной рамке", это реально может помочь).

То есть там несколько фаз процессинга:
- копирование raw-данных из заначки
- вычитание черного
- поворот для fuji
- кроп
были объединены с целью получения быстрого кропа (чтобы окошко под мышкой можно было показывать в реалтайме).

При этом все запчасти (кроме, возможно, кропа) остались т.е. теоретически можно для if(O.wf_debanding) их звать по частям и будет щастье. Но в случае кропа - медленное.

не понял. Кроп делается после удаления черного?

Ну и?

Еще раз, я же пока писал - отлаживал кучу раз. Или рисовал "вымышленные данные для отладки", ну, фейковый raw, который потом "проявлял"

И неплохо помню, что уровень черного был не 0.

Теперь не так?