>Серьезные дяди, которым важно шифрование, не пользуються OpenJDK

В статье предлагается использовать OpenJDK для дешифровки класс-файлов, а не для работы систем на продакшине. Ну и, кстати говоря, OpenJDK весьма хорош, а для изучения того как работает виртуальная машина просто клад.

>любое несимметричное шифрование без приватного ключа не позволит вам расшифровать сп*зженные jar'ки — вы банально не получите байткод для своего дампа.

Если программа запускается на вашем компьютере, значит в итоге она где-то расшифровывается, и где-то в ней хранится ключ и алгоритм расшифровки (в бутстраппере обычно). Вы путаете с другим применением несимметричного шифрования — лицензионные ключи и их взлом. Вот в этом случае действительно невозможно написать кейген не зная приватного ключа, если конечно алгоритм хороший и реализован без косяков

Да, это я прочитал, что «сигнал обрабатывается фильтрами». Вопрос как раз в том, что делает этот фильтр, описываемый той формулой?
Фильтры бывают разные — усредняющие, полосовые и т.д.
Вот и интересно, что в конкретном случае делается со входным сигналом?

Что именно делает фильтр шумоподавления, приведенный в начале статьи?

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

Если вершины многоугольника заданы целочисленными координатами (или заданы по какой-то сетке), то достаточно сместить на пол-клетки исходную точку, и проводить луч уже от такой новой точки. Тогда не придется рассматривать различные случаи когда луч проходит по одной или нескольким граням многоугольника. Здесь есть еще пара нюансов в виде того, что такой проход надо делать два раза (X+0.5, X-0.5), но в целом имплементировать и тестить гораздо проще.

Причем резистивный экран лагает гораздо меньше. Видать сказывается простота конструкции и определения координат.

Интересно, а в чем вообще причина таких лагов?
Ведь 100мс это очень много для современных процессоров, контроллеров, АЦП и прочех составляющих.
Вроде бы, проблема не в ОС, т.к. нажатие на хардварные кнопки отрабатываются моментально (на андроиде, как минимум), значит контроллер емкостного экрана выдает как раз те самые 100мс. Но вот где именно тормоза, непонятно — емкость меряться должна быть быстро. Единственное, что приходит в голову — задержку дают алгоритмы устранения помех, сглаживания траектории и пр.

Для телевиков стабилизатор в тушке уже неэффективен, т.к. требуется слишком большая амплитуда колебаний, т.е. чем больше фокусное, тем на большое расстояние надо смещать матрицу чтобы компенсировать одинаковый наклон камеры.
А если стаб в объективе — то фокусное расстояние уже не играет особой роли.

А, пожалуйста:

Сильно лучше не стало, т.к. исходное изображение пережато жипегом и буквы там высотой 4-5 пикселей. Лучше давайте нормальные исходники, а такой троллинг :)

Две минуты на лист — это вы загнули. Разделять все не требуется, достаточно чтобы вся необходимая информация читалась и сканировалась — не нужно отрывать кардиограммы и рецепты. Текст заклеивают не так часто. Пролистайте целиком свою карточку и разогните все, что нужно чтобы увидеть прикрытый текст снизу — уверен, что это у вас замет не 3 часа, как вы написали (100 листов по две минуты), а минут 10-20.
Так что, при отладке процесса и необходимой сноровке, секунд 5-10 на страницу вполне реально.

Их уже достаточно — Focus Magic, Topaz InFocus и пр.
Работают, правда, весьма неудовлетворительно на реальных картинках (но на сайте картинки впечатляют)

При повороте вокруг нодальной точки объектива смещение объектов переднего и заднего планов не происходит совсем. Если поворот не вокруг этой точки, то небольшое смещение есть, но оно ооочень мало для объектов, которые находятся хотя бы дальше нескольких метров. А вот угловое смещение (из-за которого и идет смаз) на порядки превышает смещение из-за паралакса
Ссылка

Сейчас специально распечатал на бумаге текст и сфоткал фотиком с ручной настройкой фокуса так, чтобы текст не читался. Вот что получилось:



Далее берем скрипт:

% Load image
I = im2double(imread('IMG_6637.JPG'));
I = edgetaper(I, PSF);
figure(1); imshow(I); title('Исходное изображение');

PSF = fspecial('disk', 70);

estimated_nsr = 0.001;
Restored = deconvwnr(I, PSF, estimated_nsr);
imwrite(Restored, 'IMG_6637_Restored.JPG', 'jpg');
figure(3), imshow(Restored), title('Wiener');

И получаем:



Расфокусировка, еще раз напоминаю, реальная, а не синтетическая. Если хотите, могу выложить исходник. Параметры подобрал на скорую руку, наверное, можно еще улучшить качество.

Круто, я максимум что могу прочитать — это I, had, a :)

«Увы оно не малое, и на больших выдержках системы стабилизации его компенсировать не в состоянии.»

Оптическая стабилизация в этом случае не в состоянии исправить смаз только потому, что амплитуда колебаний при больших выдержках превышает пределы компенсации, да и точность слежения датчиков падает (накапливаются ошибки). Параллельные перемещения стабилизаторы вообще не способны компенсировать, только угловые.
Вики — Стабилизация изображений

«в случае с поворотом фотика относительно некоторой оси… картина абсолютно такая же — для объектов на разном расстоянии разное смещение на матрице :)) „

Простой эксперимент — поводите глазами вправо влево, смещаются ли объекты друг относительно друга? Нет, потому что не меняется положение центра оптической оси. Также и в фотике.

Все так, только вы привели схему для параллельного сдвига фотика — оно есть, но практически ни на что не влияет в силу малости. Это надо на многие сантиметры фотик дернуть, чтобы появились видимые смазы.
А вот небольшие повороты вокруг оптической оси — это именно то, что является доминирующей причиной смазов в реальных условиях, здесь достаточно повернуть фотик на доли миллиметра, чтобы появился огромный смаз. Именно его устраняют оптические стабилизаторы:

Стабилизация изображения — это технология, применяемая в фото- и видеосъёмочной технике, механически компенсирующая собственные угловые движения камеры

И вот в этом случае расстояние до объекта роли не играет

Могу пример с Astra Image дать:

очень даже влияет, так как ближние объекты сдвигаются на меньшее расстояние чем дальние, и блюр будет разных «масштабов».

Вы, наверное, путаете с дефокусом — там действительно степень размытия зависит от расстояния до объекта. А при повороте фотика все объекты на матрице сдвигаются на одинаковое количество пикселей (в идеале)

1) В разделе «Заключение» как раз есть похожий пример с размытием источника света (справа внизу от машины блик) — вполне восстанавливается, как видно
2) Разницы особо нету — что объект движется относительно камеры, что наоборот, результат одинаковый.

«предметы для камеры на разном расстоянии, а для редактора эта информация недоступна»
Для моушин блюр расстояние до камеры практически не влияет (за исключением паралакса, но он крайне мал). Опять же посмотрите на мой пример восстановления реального смаза — качество вполне хорошее, значит PSF близка к истинной.
3) Для моушен блюр примерно так и делают — на основе анализа картинки восстанавливают траекторию смаза. Посмотрите ссылки в разделе P.S. Там и программу скачать можно и поиграться с восстановлением реальных картинок.

Этим как раз blind deconvolution занимается :)
По этой теме много научных статей появилось в последнее время.

Конкретно на первой картинке до хабраката — там тип «lens blur» в терминах фотошопа, а в качестве PSF — просто круг диаметром 15, это видно из скрипта «PSF = fspecial('disk', 15);».
В остальных примерах из скрипта также можно понять тип применяемого искажения.