to post messages and comments.

Закончил обрабатывать сканы: #2891873 То, что я загружал, — это Generic raw book zip

Практически все страницы повёрнуты и спозиционированы автоматически в МатКАДе, кроме трёх в начале и одной в конце, где нет нумерации, по которой как по самому выступающему элементу можно позиционировать страницу. Позиционирование заключалось в том, чтобы найти, где на повёрнутом скане полезная часть страницы, откадрировать скан и обратно добавить поля абсолютно белого цвета, чтоб без теней или неправильного кадрирования, которое сделал тот, кто сканировал.

Линейкой мерил отступы на реальной книге и добивался, чтоб в обработанных сканах были примерно такие же расстояния. Вообще ширина книги 190мм, но если взять 180мм, то левые и правые страницы, расположенные друг по другом, получается, будут иметь отступы в одних и тех же местах. Так что сделал 180мм. Обложку пришлось немного аффинно сжать, ведь она-то напечатана на все честные 190мм. Но в остальном удалось воспроизвести достаточно достоверно. Правда, вот смотрю я PDF и вижу, что он считается 90мм в ширину, хотя я в PNG проставлял 300dpi pnmtopng'ом при конвертации из BMP от МатКАДа. То есть, Интернет Архив в любом случае ждёт 600 dpi.

Поворачиваю в МатКАДе сканы страниц оптимальным способом. Оптимальность определил так: если взять горизонтальные линии и наклонить под выбранным углом, а потом усреднить пикселы на каждой линии, то такие усреднения вдоль вертикального направления должны образовать картину, как можно более похожую на прямоугольный импульс. Похожесть на прямоугольный импульс определяется как сумма квадратов разности усреднённых значений на соседних линиях. Чтоб из-за разного кадрирования не возникали добавки, на всех углах берутся только такие линии, которые проходят через общий для всех вертикальный отрезок, расположенный посередине скана и отстоящий от верхнего и нижнего краёв так, чтобы в заданном диапазоне углов через него всегда можно было провести семейство наклонных линий, не выходящих за край. Поворот линий, вообще говоря, не используется, а вместо него аффинный сдвиг. Искать максимум начинаю с 0° и ±0,6°, потом рядом с максимальным из них проверяю ±0,25°, потом ±0,1°, потом ±0,5°. Дельты углов подобраны так, чтобы быть чуть внахлёст, больше, чем треть от предъидущего, но меньше половины, кроме последнего, который строго половина. Максимальный угол по модулю, таким образом, 1°, но такого реально не было, попадался максимум 0,8°. Результаты удивительно хорошо совпадают с тем, что можно циркулем намерить в ГИМПе.

При помощи avconv разделил avi на один wav и кучу bmp, загнал в MathCAD, там нетривиально обработал, получил другую кучу bmp, склеил avconv обратно.

Вообще, задумка была в том, чтобы смоделировать подлинную поддержку стерео в операционной системе или хотя бы телевизоре/ТВ-приставке. Я хотел заснять скринкаст, как я меняю размеры окна плеера, и там подставить отмасштабированную стереокартинку, как оно должно быть при той поддержке, как я хочу. А как я хочу — это чтобы инвариантом были точки на горизонте, а не на поверхности, как это обычно делается (по моему мнению, неправильно) в тех стерео 3D плеерах, что я видел. А если можно это делать, то в UI гипотетического телевизора можно показывать в ряд корректно уменьшенные каналы.

Также в стерео 3D можно физически корректно вращать картинку вокруг горизонтальной оси. И это тоже можно применить в UI, сделав Coverflow, как в iTunes, но вертикальный. Ещё подумал на тему некоторых физически некорректных операциях, которые, тем не менее, могут быть корректны в стерео. Coverflow-то по-хорошему горизонтальный! И места по горизонтали больше. Может быть, вместо честного поворота по горизонтали, который для стерео невозможен, сделать такое подобие «поворота», чтобы по горизонтали пиксели нелинейно сжимались/разжимались, а по вертикали оставались нетронутыми, а потом обрезать лишнее и вписать в рамку. Насколько это будет выглядеть естественно? Может быть достаточно, чтобы реализовать в реальном ТВ.

В качестве сырья выбрал Duke Nukem 3D, только не в режиме анаглиф, а в режиме Crystal Eyes VR. Пожалел потом об этом. Вообще, хотелось записать Дюка в цветном стерео 3D, для зрелищности, но геморроя получилось прилично. В анаглифе Duke Nukem 3D кадры по сути в 16 градациях серого, но зато они синхронны, а в Crystal Eyes VR они чередуются. Захватывал DOSBox'ом, он захватил в 61fps всяких разных кадров, но из них много бракованных, когда одна половина кадра отрисована, а другая — нет. И сами кадры для левого и правого глаз меняются по очереди где-то с частотой 21 кадр в секунду (то есть, 10fps в одном ракурсе), при этом то один, то другой отстаёт от другого, и смотреть на отдельные кадры тяжело, они не сходятся, но в движении получается ещё терпимо. Пока больше всего времени потратил именно на преобразование кривых 61fps в нормальные 24fps так, чтобы отслеживать не изменившиеся кадры, браковать плохие, и из оставшихся хороших делать по возможности когерентное видео. До поворотов дело так и не дошло.

Нашёл в MathCAD такую штуку, как Scripted Component. Оказывается, с её помощью можно даже в Интернет лазить. Наваял на сервере генератор данных в том формате, в котором в MathCAD будет легко парсить, и получил матрицу с актуальными данными на пару сотен строк прямо в документе MathCAD. Мешает кеширование, а именно, MathCAD на время работы с документом запоминает результаты для разных текстов скрипта, и если поменять URL в тексте скрипта, то перезапросит с сервера и пересчитает, а если потом вернуть URL назад, то результаты вернутся на старые. Попытался починить, добавив входную переменную и подав туда runif(1,0,1), случайное число, то есть. Помогло или нет, пока не понял, те данные, которые я умею вытягивать, не менялись за то время, когда я уже починил, но ещё не закрыл документ.

А неплохо будет загнать в MathCAD ещё данные с нескольких сервисов, Яндекса и ВКонтакте хотя бы.

У меня ощущение, что маны к маткаду не расчитаны на программистов. Вот не могу ничего найти про пространства имён и видимость "объектов". Интересно, если б я сразу начал это писать на питончике, проебался бы я с гуями столько, сколько я ебусь с реализацией алгоритмов в маткаде. Как препод в нём может что-то написать? Ладно. Начал — закончу.

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

Страшное дерьмище этот маткад. Мало того, что неудобный, так ещё и хрен распечатаешь результат, ибо он делает решения длинными как хз что (в несколько страниц/экранов, без переноса строк), а экспортирует только в rtf или html, причём всё делает картинками.