Tulon
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Admig314
Цитата:| Последняя, преобразование в BW и собственно вывод - очень долго. Оно и понятно, разрешение все-таки 1200. Качество результата просто отличное! |
Сейчас при увеличении разрешения вывода в два раза, производительность падает аж в 16 раз! Просто ужас. А все из-за того, что я когда-то подобрал идеальные параметры для полиномиального фильтра (тот самый Savitzky-Golay) для 300 DPI, а для более высоких разрешений просто увеличиваю размер окна фильтрации. А ведь можно вместо увеличения размера окна понижать степень полинома, а можно и то и другое сразу. В общем я сейчас как раз занимаюсь подбором хороших параметров для разных разрешений, чтобы размер окна держать в разумных пределах.
Также пробовал для поднятия производительности генерировать код, заточенный под конткретные размеры окна и под конкретный процессор прямо во время выполнения программы (с помощью LLVM). Получил ускорение в четыре раза, в независимости от разрешения. Но архитектура этого LLVM показалась мне настолько убогой, что желание его использовать быстро пропало.
Кому сильно интересны мои претензии (а поймут это только программисты, да и то далеко не все), вот:
1. Почему ExecutionEngine может быть только в одном экземпляре? Разработчики утверждают, что ради производительности. А я, как Станиславский скажу "НЕ ВЕРЮ!".
2. Ладно, допустим поверил. Тогда почему он не Singleton а обычный класс?
3. А почему он не делает межпотоковую синхронизацию, а вместо этого просто выставляет свой мьютекс в публичный доступ? Надо полагать тоже ради производительности?
4. Не люблю фабричные методы, которые возвращают мне объекты по указателю. Люблю чтобы по умному указателю, пусть даже по auto_ptr. А то совершенно непонятно, кто владеет этим объектом и кто должен его удалять.
В общем такой многообещающий проект, но такая говеная архитектура.
Цитата:| Однако визуально картинка кажется несколько жирноватой, контуры букв утолщенные против желаемого. Дело здесь, думается, в том, что когда электронный макет печатается в типографии, краска в зависимости от сорта бумаги слегка расплывается. Если теперь результат отсканировать, обработать "by ST" и снова напечатать, ужирнение будет еще больше. |
Дело тут и в этом, а также и в параметрах смягчения. Я пожалуй добавлю опцию отключения смягчения. На таком высоком разрешении оно может и не к чему.
Цитата:| Не знаю, насколько это вписывается в планы, но мне, как просто пользователю, хотелось бы видеть более тонкий результат. Или, может быть, интерактивный контроль "степени жирности" - регулировку порога при преобразовании в BW. |
Регулировка порога есть в планах, но в отдаленных.
Цитата:| Далее, на последней стадии обработки очень сильно тормозятся вообще все остальные процессы на компе. Параллельная работа становится практически невозможной. Понятно, что идет интенсивная математика, но с другой стороны тот же фотошоп не самая легкая прога, и даже если обработка в нем идет долго, то работу других процессов это не настолько сильно тормозит. Возможно ли ожидать какой-либо подвижки в этом направлении? |
Да, тут на одном только despeckle потребляется 12 байт на пиксель + еще черыре байта на одном из его этапов. Итого имеем: картинки 10000 на 14000 пикселей, Выходит 10*14*10^6*16 = больше двух гигабайт. Ого - сам не ожидал такого.
Цитата:| И еще. В корне диска C: при успешном завершении проекта регулярно создается пустая папка cache, при том что проекты у меня находятся на другом диске. |
Это интересно. У кого-нибудь еще такое наблюдается? |
Наверняка существует даже какое-нибудь теоретико-научное обоснование, почему "сначала все изделия проходят одну стадию, потом следующую" гораздо производительнее и удобнее во всех смыслах, чем "сначала одно изделие проходит все стадии, потом следующее". 
