Image Master

Финальные замечания о своих намерениях, вернее, их крайне урезанный вариант. 1. Видеокамеру купить не успел, придется снимать на что было год назад, но зато с 2 комплектами батарей. 2. Game Gear приносить не планирую (хотя это можно изменить, если понадобится), зато будут flash-картриджи для черно-белого Game Boy. 3. Мысль принести показать Game Boy камеру и принтер почти накрылась - владелец уезжает из Москвы как раз на дни ГС - но, если очень повезет, принесу на заключительный день гейминга. 4. Погода ужасная - бегать туда-сюда (наподобие первых двух дней ГС-2009) совсем не смогу... 5. Большой Апдейт-1. PC-сервер таки запущен, что значит: a) независимость хостинга и доступности фото-видео материалов от использования PS3 (если оно будет) для гейминга и б) наличие самой возможности этого хостинга. Никаких хрендексов и пр. в этом году, слава Богу, терпеть не придется. 6. Большой Апдейт-2. Прочитал немного на форуме о планах народа, в частности, об эвенте. Совместимости со мной не обнаружил. Мне там совсем скучать, что ли, придется? Или лучше в этот день отсыпаться? И во второй тогда автоматом тоже? А, ну и конечно. Читать всё, что связано с темой ГС-2010, отмечаться, что мне интересно и т.п., было решительно некогда, и так уже около одного часа спать осталось... Что к официальному времени не успею, и Сонику понятно...

Моя тема стандартна http://imtech.homelinux.org/program/doc/adv2010.doc

Появилось, что показать. Вот: Сие есть изображение меня, снятое на Game Boy камеру и напечатанное на Game Boy принтере. При сканировании старался передать уровень темного/светлого как можно ближе к оригиналу.

Изображения здесь: http://imtech.homelinux.org/photo/cis/2010...2010/index.html В этот раз у меня были только мобильник и PSP-камера, так что "зеркальным" не чета. Зато есть немного видео. (прошу прощения, что только сейчас, вечером спать завалился, не доделав)

Уважаемые поклонники персонажа Sonic the Hedgehog, и особенно - одноименного мультсериала! Наконец готов с радостью представить на ваш суд вашему вниманию изготовленную мной посвященную ему маленькую "демку" для ARM7TDMI (Game Boy Advance) http://narod.ru/disk/15218826000/SATAM2.GBA.html (должна нормально пойти на эмуляторе; я запускаю через M3 adapter) Можно считать, что это также посвящено моему более-менее вхождению в ваш коллектив (хотел еще в дни глобального слета сделать, но сильно тормозил) и кроме того - тем дням, когда я впервые познакомился с упомянутым сериалом (январь 2006 г.), загрузив его с этого сайта в формате Real Video. (to administration: так и не смог решить, какой раздел подходит для этой публикации. Если что, пожалуйста, перенесите по своему усмотрению)

Итак, что я обещал... 1. Иллюстрации ко второму алгоритму для SatAM. Вроде бы дополнительной постеризации эмулятор не вносит. (конечно, это не те кадры, что были выше для первого алгоритма) Остальные иллюстрации второго алгоритма для SatAM можно посмотреть здесь (41 шт.). 2. Новенькое. Я уже давно хотел расширить репертуар этим сюжетом, но возможности первого алгоритма не позволяли это сделать. Теперь, после внесения усовершенствований во второй алгоритм, обретает жизнь Sonic Adventure DX. http://narod.ru/disk/19805105000/SADX1.GBA.html (31.8 Мб) http://narod.ru/disk/19805195000/SADX2.GBA.html (31.8 Мб) Здесь два варианта, я не буду подробно комментировать разницу между ними, а лучше подожду впечатлений от пользователей.

Всем привет. Что произошло за это время, или Небольшое обновление. (если лень читать, см. страницу версий) 0. Опечатки и т.п.: в предыдущем файле отсутствовал заголовок (а я только сейчас заметил). Приношу свои извинения. Исправленный файл здесь: http://narod.ru/disk/19621610000/SatAM5.GBA.html 1. Был написан усовершенствованный вариант алгоритма, позволяющий отбрасывать некоторые данные и уменьшать размер файла по сравнению с классическим вариантом. При этом, разумеется, вносятся дополнительные потери, количество которых (в условной метрике) можно задавать по желанию. Ниже несколько примеров, в порядке увеличения этого параметра (и соответственно получаемой экономии). Также быо применено дополнительное сжатие звука с потерями, для чего был написан алгоритм его распаковки "на лету" в фоновом режиме (а основная программа занималась распаковкой видео в оставшееся время). Во всех приводимых ниже программах используется фоновая распаковка аудио. Классический вариант (30.1 Мб) - сжатие по обычному алгоритму для сравнения с новым (а реально это результат теста новой программы-енкодера, перед началом работ по внесению новшеств в алгоритм видеосжатия) Новый вариант, уровень 1 (28.5 Мб) Новый вариант, уровень 2 (27.3 Мб) Новый вариант, уровень 3 (25.6 Мб) Новый вариант, уровень 4 (24.3 Мб) Новый вариант, уровень 5 (23.3 Мб) Посмотрите, какое впечатление от дополнительных потерь, как работает на каких карточках и пр. Прошу прощения, что здесь без изображений. Картинки, на мой взгляд, не очень информативны, потому что основа алгоритма та же, а доп. потери относительно невелики. Дальше всякая отсебятина. При работе над усовершенствованным вариантом, особенно - алгоритмом распаковки звука, пришлось столкнуться со всякими интересными явлениями, не только глюками эмулятора (когда звук я мог услышать лишь на реальной системе (после исправления всех ошибок) или в другом эмуляторе, не имеющем функций отладчика), но и глюками ассемблера (!), когда команды формируются неверно, нормальные инструкции отвергаются как недопустимые, а адреса считаются неправильно... Пришлось побороть и эти мелочи программирования. Отсебятина-2. Вариант, обозначенный выше как "классический", повергает меня в недоумение. Он работает, хотя "по логике" не должен. В нем не используется отбрасывание данных, значит, нет экономии в скорости в алгоритме видео. Алгоритм видео занимает 96% времени процессора (оценка - из того наблюдения, что запущенный на полной скорости без звука и синхронизации он давал примерно 25 кадров в секунду, а для воспроизведения надо 24). Написанный мной столь коряво алгоритм распаковки звука занимает 1000 тактов на каждые 16 точек (для обоих каналов вместе) (оценка по ручному подсчету числа выполняемых команд, с поправкой на то, что обращение к памяти занимает больше), при частоте дискретизации 32 кГц это 1/8 времени процессора, не менее 12%. А здесь они на одном процессоре вместе. 96% + 12% - это явно больше его возможностей... Но тем не менее работает... 2. Был написан второй алгоритм (другой, не такой, как выше) для сжатия видео. В настоящее время готова для демонстрации его классическая реализация (пока - без собственных нововведений вроде тех, которым посвящен предыдущий пункт применительно к первому алгоритму). В этом случае, разумеется, тоже применено дополнительное сжатие звука с потерями и его распаковка в фоновом режиме. Алгоритм 2, классический вариант (23.4 Мб) Прошу поделиться впечатлениями от работы этого алгоритма, сравнения его с первым и т.д. Также обращаю внимание - размер файла, сжатого классической версией второго алгоритма, соответствует лучшему сжатию, даваемому усовершенствованным первым. Так что при внесении аналогичных усовершенствований во второй (чем я собираюсь заняться в ближайшее время) можно ожидать довольно интересных результатов. Stay tuned... Более подробные сведения (даты создания, точные размеры файлов) можно найти на странице версий. P.S. Я знаю, что по второму пункту нужна иллюстрация, она будет позже.

Действительно, сэкономить можно еще довольно много. Представляю обновленный вариант первой программы - слегка измененный "движок", меньший размер данных при тех же потерях. ссылка на файл, обновленный архив версий. Stormwind, если тебе лень сообщать допустимый размер файла для "3в1", попробуй эту версию, надеюсь, она достаточно меньше. Особенно прошу личное мнение о точности синхронизации видео и звука, т.к. у меня стабильное ощущение, что я пытаюсь получить от процессора больше вычислительной мощности, чем он способен дать (интересует именно независимое мнение). Также интересует впечатление о количестве потерь в изображении и звуке, в сравнении с предыдущей версией. LinesPrower, рекомендую вернуться, т.к. здесь уже довольно много новшеств по сравнению с классической реализацией. И собственные замечания. Исходные данные получены тем же алгоритмом подбора цветов, что и ранее; кодер полностью переписан, но добавлять оптимизацию в эту часть было лень, т.к. внимание уделял оптимизации по размеру. По ходу разработки измененного алгоритма наблюдались такие явления, как потеря совместимости со всё большим числом эмуляторов (то есть обнаружение ошибок в них), а также что эмуляторы, раньше работавшие на полной скорости, теперь могут не справиться, и т.п. В "BATGBA" из-за глюка теперь не работает звук (на реальной системе всё нормально), жаль, хороший был отладчик.

Еще немного про "3в1". Есть ли возможность выяснить точный максимальный размер файла, который можно туда загрузить? (на всякий случай повторю: принципиальный максимум 32 мб = 33554432 байта, на него я и ориентируюсь) При "втором" способе запуска, когда пока не работает, есть ли на экране кроме надписи "GAME BOY" надпись "Nintendo"? Тот же вопрос при запуске работающих игр в этом режиме. И надо ли их было как-то "патчить" перед этим, или они работали и без изменений? Про SCD - я бы рад был сделать картинку больше, но в оригинале размер 256x112. Полосы будут.

Значит, у меня получилось. Именно про штатный режим я могу узнать однозначно, т.к. он везде одинаков. А "программный запуск", видимо, уже плод фантазии создателей ус-ва... Интересно, можно ли сделать, чтобы и с ним работало, но для этого нужен как минимум очень подробный мануал на саму штуку (вплоть до кода, которым они пользуются для этого), или же эксперименты с более простыми примерами. Есть ли при этом виде запуска надпись "nintendo" на экране gba bios'а? И есть ли она при том же виде запуска работающих игр? Еще один вопрос к тебе - есть ли субъективные претензии к воспроизведению (на консоли, конечно), прежде всего, насколько сильно достаёт "эффект рваного экрана" при смене кадров? Под впечатлением от упрека за SatAM, где с его 24fps это было неизбежно, я попытался здесь сделать всё как можно лучше, но скорости немного не хватило. Немного об искажениях и их неприятных последствиях. В настоящее время исследую вопрос, можно ли сделать лучше изображение при том же алгоритме. Готовых для показа результатов нет, но главное - на компьютере, при выводе с точностью 8 бит на канал, постеризация, шум, ложные контуры и их дрожание заметны существенно меньше. Во многих случаях не заметны вовсе. Большая часть неприятностей вызвана именно округлением до 15 бит на GBA. Попробую создать программу-кодер, "согласованную" с примененным мною здесь алгоритмом отображения (целочисленный, 5 бит на канал). upd: вот программа для windows, позволяющая воспроизводить как с постеризацией, так и без. здесь Можно просмотреть видео из всех моих выложенных ранее GBA файлов (автоматически считается точка начала данных; кстати, это же число определяет размер собственно GBA программы, т.е. исполняемой части rom-файла), по желанию моделируя постеризацию (алгоритм с упрощенным умножением, как на GBA, и округление до 15 бит) или используя "максимально точный" (floating point, с округлением до 24 бит только на выходе) алгоритм. По крайней мере, должно быть достаточно, чтобы оценить качество видео при отсутствии GBA-ограничений. Внимание! При включении постеризации происходит простейшее отсечение трех младших бит, от этого изображение темнеет, его нельзя непосредственно сравнивать с первоначальным (для этого надо было бы еще осуществить "растяжение" [0;248] -> [0;255] для R и B и [0;252] -> [0;255] для G, которого я не делаю, чтобы не вносить вторичных ошибок округления); с изображением на реальной системе его тоже не стоит сравнивать, потому что там чуть другая зависимость яркости от выводимого числа. Эта модель годится, чтобы наглядно показать разницу в заметности "сильного шума на однотонных областях" при наличии и отсутствии 15-битного ограничения, но для оптимизации видео под GBA ее еще придется дорабатывать. Разумеется, входные данные - размер кадра и их число в секунду - надо указывать вручную и правильно. Для SatAM это 240x160x24fps, Sonic CD 240x112x15fps.

Прийти смогу только вечером

Еще немного эксклюзивного фото-видео от меня (с другого аппарата) здесь.

Так тоже можно. Но пусть скажут и другие. И вообще, время уже подошло, определенность приветствуется.

Архив с изображениями с 20-го. Почти полный, с одного аппарата. здесь.

Удобнее 28-го. 29-го дела (впрочем, возможно недолгие).

Тогда BIOS и проверяет заголовок картриджа. Попробовал его добавить. У меня работает, hard reset система проходит нормально. Загрузить можно отсюда: SatAM, Sonic CD. Каков допустимый размер того, что можно записать? Хотя бы с точностью до килобайта.

Насколько я понял, ты сначала (отдельно от приставок) записываешь данные в свою штуку, а потом включаешь систему с ней как с обычным картриджем? Вот тут-то BIOS и проверяет заголовок, а у меня он пустой. Все описания заголовка ROM, какие я видел, были неполными. Ты знаешь программы, добавляющие заголовок автоматически?

Как-то я привык к своему картриджу, сложно и представить возможные ограничения других систем. У твоей штуки есть инструкция или readme, чтобы мне почитать? Да, и еще, так и забыл сказать, т.к. это подразумевается. Я код просто компилировал, сигнатуры nintendo он не содержит. Я это не чувствую, т.к. при запуске m3 adapter подставляет свою (а большинство эмуляторов исполняют что есть без проверок). Но если сделать rom-картридж с этим кодом, он работать не будет (bios проверяет "фирменность" содержимого перед запуском). Соответственно не будут работать flash- и другие системы, опирающиеся на информацию из заголовка, которого здесь просто нет. Вроде в интернете куча программ, автоматически добавляющих заголовок к коду, но можешь дать ссылку?

В Измайловский парк было бы очень здорово... поддерживаю.

Ровно 32 мегабайта, это 32768 кб, где 1 кб - это 1024 байта. Мне в начале немного не хватило, получилось 32.08 мб, но была секундная пауза в начале. Я из нее полсекунды выкинул, получилось как сейчас. Могу еще вторые полсекунды выкинуть. Но если устройство, например, позволяет использовать 16-мегабайтные оригиналы, а 32-мегабайтные - нет, то этим мелким кусочком ничего не решить.

Размер своего файла я знаю; я не знаю, какие требования у твоего устройства, в частности, поможет ли чему-нибудь то относительно небольшое уменьшение, которое я могу сделать.

Там я занял все доступные 32 мб. Попробуй Sonic CD (чуть выше ссылка), он поменьше. Я не знаю, как работают разные flash-карты и пр. средства. Есть ровно 32 мб адресного пространства ROM-памяти, доступные для использования, вот я их и занял. M3 adapter достаточно точно имитирует фирменный картридж, и на нем у меня всё работает. Грузит файл с SD-карточки в свою flash-память и передает управление на ее начало, после этого отличия его от обычного ROMа и не обнаружишь. Но если устройство использует какую-то другую схему, часть памяти продолжает занимать под свои нужды, я не могу подсказать, как и что тут делать. Могу сделать GBA-файл поменьше, но не намного, примерно на 250 кб. Это поможет?

Да, всё правильно. Здорово. И рассказать кратко - у меня бы не получилось (пытаюсь научиться). Кстати, теперь я могу заслуженно сказать: "Я пишу понятный код". Писать так была моя привычка, когда делал свои первые программы для GBA (хотя, впрочем, я до сих пор в состоянии "первых шагов"). А в данном случае это еще и пригодилось - позволило достичь нужной скорости. А зачем он вообще нужен? IMHO его наличие - это "роспись в бессилии" разработчиков системы создать достаточно быструю память. Кстати, внутренняя память (в частности, из которой исполняется код в этой программе) на GBA без wait states, но всё равно обращение к памяти на ARM7TDMI - минимум три такта (чтение) или два такта (запись), быстрее не сделаешь. Это как раз одно из очень полезных качеств на "родине" этого алгоритма (или, может быть, ставилось как одно из требований при разработке). Подробнее позже. Хотя, полагаю, в общем случае, просто для сжатия изображений, оно скорее создает ограничения (прежде всего по степени/эффективности сжатия), чем помогает. Это опять же, смотря с чем сравнивать, особенно в таких задачах (также частично см. ниже, частично - потом), для каких его делали. Лично я бы, например, так не сказал. Совсем. Даже с учетом того, что несжатый оригинал для GBA был бы 15-битным (хотя из полного, конечно, лучше делать, удобнее при распаковке и ближе к оригиналу получится), и даже если пренебречь ограничениями производительности, имеющимися на GBA. Это, но для каждого по-своему, думаю, можно сказать обо всех алгоритмах сжатия с потерями. Так что зачисление этого в недостатки - самое большее, дело вкуса. Лично меня, например, очень-очень сильно достали характерные искажения от любых ДКП-методов. И в том чсиле поэтому я был рад изучить алгоритм принципиально другой (хотя, конечно, другой не во всём, блочность-то осталась). И уж тем более был рад сам написать программу на эту тему. А что удалось еще и на его основе видео сделать, в некотором смысле полноценное (без пропуска кадров) - в это даже еще как-то до конца не поверил. "Характерные"-то они да, но характерные по-другому. Например, в отличие от ДКП-методов, создающих неприятные осцилляции (ringing) на тонких линиях, резких границах и т.п., этот алгоритм очень хорошо сохраняет границы (а в мульфильме, когда попадается одна линия на однотонном фоне, она сохраняется так хорошо, что вообще не заметно, что оно сжато с потерями), что, насколько я знаю, явилось одной из главных причин выбора именно такого метода, а не ДКП-шного, там, где его применяют (или, опять же, такое требование ставилось при разработке). Иногда попадаются изображения, сначала сжатые с потерями ДКП-квантованием, а потом распакованные и сжатые этим методом. Так вот, "из-под" него видно, что ранее изображение "побывало под" ДКП! Мне кажется, интересное наблюдение. Стандартный. Только, насколько помню, есть какое-то несущественное отличие, порядок битов обратный, кажется. Если до сих пор не очевидно, могу сказать так: ну кто наконец назовет его? Получит приз! (как раз встреча скоро намечается) Конечно влияет, я же говорю, потенциал (у меня) еще не раскрыт. Многие стандартные кодеры получают такое хорошее изображение, что я могу очень долго и много смотреть на результат и так и не заподозрить, что было сжатие с потерями, тем более с двухцветной палитрой. Кодер же у меня работает очень тормознуто и хреново. Вначале происходит индексация (нахождение палитры для приближения) 4х4-пиксельной картинки до двух цветов с использованием того же самого давнишнего тупого метода, который я написал и использовал в своих экспериментах по индексации полноцветного изображения до 16 цветов (или вообще до n). Здесь я в лоб использую тот же самый алгоритм (написанный мною чисто на основе фантазии, без малейшего представления о том, как работают коммерческие индексаторы), только в качестве количества цветов в него подставлено два. Потом еще применяется простейшая (уже во времена написания алгоритма сжатия придуманная) "оптимизация" (замедляющая процесс еще на порядок), после чего по найденным по палитре цветам выбираются ближайшие и записываются в результат. Кстати, вначале я не верил, что при таком хранении может получиться вообще что-то похожее на оригинал. Первый опыт с двухцветной палитрой показал, что почти так и есть, хотя сходство прослеживалось. Потом я придумал "оптимизацию", и полученное изображение стало иногда вообще быть очень похожим на оригинал (но не во всех блоках). А дальше доводить до ума я частично поленился, частично попытался и не получилось (плохо попытался, с ошибкой). Наверняка методом, близким к полному перебору, можно даже при плохом начальном приближении получить что-то хорошее, но это будет очень медленно даже по сравнению с "оптимизацией", выставленной на 100 попыток перебора и потому уже весьма всё замедляющей (так был получен этот пример). Здесь, наверно, следует сделать тему по обсуждению "Алгоритма получения двухцветной палитры из 4х4-пиксельного блока". Сначала название метода в студию, а потом уже и об обсуждении работы кодера подумаем... to be continued... Обидно, не очень много времени на столь интересный сюжет. Отвечать собираюсь в порядке поступления вопросов. Однако... super... так вот в чем дело Есть учебные заведения, где этому учат? Или в смысле - самостоятельного изучения по интересам? А вот тут подробнее. И наверняка лично. Дело в том, что есть еще добрый десяток процессоров, которые частично из интереса, частично из уважения к приставкам хотелось бы освоить... http://imtest.narod.ru/personal/misc/ADV2.DOC Просто с GBA так совпало, что некоторое время назад купил m3 adapter для игр, а он же позволяет запускать любой код. Тогда тем более круто... Разобраться только по коду, не имея возможности выполнить по шагам и увидеть результат... Да с вами опасно иметь дело! Почти удобен для отладки BATGBA, и в нем идет более-менее. Самый же удобный для меня Mappy, только жаль последний сильно не дописан (то, что я видел), там не будет работать. Как мне показалось, в той статье автор донельзя упрощал и пропускал операции, и то, что осталось, работало заметно быстрее. Я бы сказал, скорее громоздкая - большое кол-во однотипных операций. Да. Для такого объема можно сказать, что проблемы. Имеющиеся 32 кб - это чуть меньше, чем полный кадр в 8-битном режиме. Другая же память уже очень медленная для столь интенсивного обмена. Хотя теоретически, ради интереса можно попробовать что угодно - например, эта программа родилась как раз из аналогичного эксперимента ("а что получится, если..."). Этот вопрос у меня уже как минимум с 2000 года, присоединяюсь. Точно всё настолько плохо по скорости? Однажды, кстати, я задавался вопросом, что будет, если оставить как раз 3 ненулевых коэффициента. Можно попробовать, что же это всё-таки будет. А если делать блоки другого размера при том же числе ненулевых к-тов? Например, для блоков 8х8 будет быстрее или медленнее? Конечно, извини за дилетантский вопрос, давно не занимался внесением этого вида искажений. Да мы же сами сейчас обсуждаем контрпример... Если бы тут еще был разбор последовательности битов, это бы было жутко сложно, я бы не решился такое писать даже начать. А для простейшего алгоритма вон результат готов. Это я еще не говорю, как медленно бы работало это самое жутко сложное... (в моей мега-примитивной программе (для компьютера), читающей JPEG, похоже, как раз декодер Хаффмана является самой медленной частью, хоть я делал это через двоичное дерево) Похоже, есть шанс на усовершенствование/альтернативы моего примера. Это всегда welcome, конечно. Для меня - проигрыш. Сейчас очень модно всюду переводить в YUV и уменьшать разрешение U и V как минимум вдвое по обоим измерениям. И от этого изображение очень сильно портится, мне вообще хочется на такое не смотреть (при том, что о других видах искажений я еще даже не начал говорить) (кстати, мультфильм - хороший пример того, где так делать особенно не следует). Отсутствие этого вида искажений - еще одно облегчение, которое мне подарил пока еще не названный читателями алгоритм. Видимо, пора мне выкладывать оригинал (после уменьшения, тот, что подвергался сжатию). Там действительно такой шум. Плюс округление - больше всего заметна ведь граница между соседними 15-битными градациями и ее колебания туда-сюда по полю кадра, а ведь это как раз то самое место, где Насчет же устойчивости... напомни определение... а пока могу сказать, что сейчас еще алгоритм подбора не очень хорош, по сравнению с возможным, но не думаю, что он обладает какими-либо столь сильными специфическими недостатками вроде ее отсутствия. Я же никак не фильтрую сигнал (в т.ч.по времени), а приближаю каждый кадр независимо, алгоритмом, который писался для статичных картинок (и так и работает пока что). То, что часто колеблется целый блок, видимо, получается тоже из-за простоты алгоритма подбора и округления. Потом скажу. Хотя еще улучшать и улучшать. Можно опубликовать оригинал и провести конкурс: кто напишет алгоритм, приближающий лучше к оригиналу. Можно как чисто свой, можно как улучшение того, что уже есть у меня. Пока, чтобы скрасить ожидание, интересующимся могу предложить следующие вопросы: каким образом осуществляется синхронизация видео со звуком? в каком формате хранится звук? какова точная частота кадров видео? Кстати, для желающих попробовать более вычислительно сложные алгоритмы на GBA есть еще графический режим номер 5 - разрешение 160x128, 15 бит rgb bitmap, 2 видеостраницы. Правда, я на реальной системе его еще ни разу не включал. Можно попробовать для "маленького" экрана что-то сделать... update: Ну вот, творение номер 2, видео на том же движке для Sonic CD, enjoy: http://narod.ru/disk/15672553000/soniccd.gba.html P.S. На этот раз оригинал был в масштабе 100% и формате Intel Video 4.3, уже с очень сильными искажениями, так что выглядит далеко не так хорошо, как SatAM.

В данном случае - точно, не примерно. Смотря с чем и как сравнивать. В случае сжатия с потерями - да, вообще говоря, можно, только полезных данных останется так мало, что, например, лично я бы задался вопросом - а зачем? а надо ли? ты хочешь примерно 1 кб на кадр... кстати, почти так (даже еще чуть меньше) обстоят дела в realvideo-файлах, в которых хранится этот сериал на данном сайте. Конечно, да, именно в таком виде я и смотрел всё в первый раз, и было понятно и нравилось, но ты уверен, что не хочешь, чтобы изображение было получше? Изначально там 8 кадров в секунду, но даже RealVideo с его фрактальным сжатием во многих местах не уложился в 1 кб на кадр и был вынужден пропускать часть кадров, чтобы в оставшихся было видно хотя бы что-нибудь. И потом, это всё в принципе, когда нет ограничений на быстродействие. А здесь у нас GBA, ARM7TDMI @ 16 MHz. Реально ли на нем сделать ДКП-квантование + фрактальное сжатие (на распаковку) в реальном времени, пусть даже для 8- кадров в секунду? Хотя этот вопрос получается открытым, после знакомства с той заметкой я начал сомневаться в полной невозможности этого... Что касается этого, я думаю, он берется от: 1) шума в исходном видео 2) потерь от сжатия, в том числе - из-за несовершенства алгоритма, примененного мной 3) округления до 15 бит на дисплее GBA 4) приближений, примененных мной при распаковке 5) дополнительного округления, которое может делать эмулятор, если запущено не на реальной системе С п. 1 и 3 я сейчас ничего не могу поделать (кстати, шум в оригинале далеко не на последнем месте здесь), и они не имеют отношения к сжатию и данному алгоритму в частности. Полагаю, что основной эффект как раз от сочетания 1-3; шум, будучи округленным до 15 бит, начинает так обращать на себя внимание, да еще, возможно, "блочность" изображения заметна как из-за сочетания "блочной природы" алгоритма с округлением, так и из-за упрощенного метода подбора цветов, не раскрывающего полный потенциал (в смысле принципиально достижимой близости сжатого изображения к оригиналу) этого метода хранения данных. Попробовав несколько разных эмуляторов, с удивлением убедился в наличии п.5. Это скорее исключение, но тоже есть. Да, видеостраница лишь одна, поэтому прямо на экран, блок за блоком... уже сам видел в коде... Но тут ничего не поделаешь, исходных кадров 24 в секунду, на экране 60 полей, поэтому несинхронность и tearing неизбежны в этом случае... Если бы было в целое число раз меньше - тогда было бы лучше, конечно. Но не сильно, из-за отсутствия буфера (а хранить данные во "внешней" ОЗУ бесполезно, так как копирование туда-сюда было бы неприемлемо медленным в этом случае; конечно, при 8 fps об этом можно думать, но при 24 - скорее всего, нет). Насчет эмуляторов - как там буферизация, согласование с экраном компьютера и т.п., я не знаю (да и разное везде), так что в общем случае, скорее всего, выглядит хуже, чем в реальности. И еще, впечатление действительно отличается на разных системах. На первом GBA SP, например, вообще всё смотрится безупречно, постеризация и потери от сжатия практически совсем не бросаются в глаза. А несинхронность как раз, наоборот, хорошо заметна. to be continued

Взаимно. Кстати, если ты за один день освоил команды ARM и разобрался в алгоритме по коду программы, то это действительно здорово. (тогда же заглянул в код в пошаговом режиме, прикидывая, насколько по нему легко что-то понять. Но следующее же сообщение все показало) Каким отладчиком пользовался? Спасибо за информацию. Интересно, что это вообще сделали, и особенно интересно, что утверждается достижение использования 16 млн тактов на 1 секунду (что как раз как на GBA). Но... 0) Разрешение намного меньше, чем у GBA, и лишь 15 кадров в секунду 1) Речь о подготовке YUV-данных, а надо еще в RGB перевести и вывести 2) Подчеркнута "заточка" на приложения типа видеоконференций, когда большую часть времени большая часть изображения статична (фон), и за счет компенсации движений расчеты для нее пропускаются, что дает сильную экономию времени 3) IDCT: 3a) ориентация на данные с сильными потерями, когда ненулевых коэффициентов немного и 3б) для тех данных, которые всё-таки есть, упоминается дополнительное уничтожение (игнорирование) малых по модулю коэффициентов - опять же, для как можно большей экономии времени расчетов 2-3 - довольно узкий частный случай (для которого, в том числе, вышележащий мультфильм является контр-примером) Но, честно говоря, я полагал, что для алгоритмов, испольщующих ДКП-квантование и компенсацию движений, процессора GBA принципиально не хватит, а тут хотя бы что-то. Я полагаю, стоит говорить о 16 битах, потому что факт неиспользования одного бита мало позволит сэкономить - потребуются сдвиги и т.п. И потом, не забываем, что оригинал 24-битный. Размер составляет около 111 мб и 167 мб соответственно. 32 мегабайта. to be continued