• avatar Flexx
  • 4
Неплохо бы ещё в конце сделать главу с итогом, где тезисно перечислить ответы, которые совпали у всех или большинства.
  • avatar Vinnny
  • 3
насчёт выводов. мне как организатору эти мысли людей крайне интересны. в целом многие описывают желание выставляться на «идеальном демопати». жаль в реальности всё немного по-другому, и люди это понимают, поддерживая по мере своих сил всё что могут.
  • avatar Vinnny
  • 3
изначально я писал 16 сценерам. 50% — тоже неплохо.
nodeus , а что ты имел ввиду, когда отделял демосцену от компьютерного творчества? Я вроде как и понимаю мысль, но хотелось бы поподробнее.
Любопытно, что только 8 человек удосужились что-то написать. Какие-нибудь выводы для себя удалось сделать? А то я, например, почитал всех, было любопытно, но не могу сказать, чтобы что-то в голове поменялось.
Птички бегают ржачно по земле.
  • avatar Shiru
  • 2
Обзор клонов Joust для ZX Spectrum был в The Spectrum Show #67: www.youtube.com/watch?v=NWsPGfnFvhw
  • avatar nyuk
  • 3
Готово расписание событий демопати 29-30 апреля.

И как следствие, более точный срок дедлайна: 2018/04/29 15:00 (MSK)
Не жалею совершенно. Если посмотреть сугубо профессиональные трофеи от спектрумизма, то в сухом остатке имею:
1. Первую программу, написанную 21 год назад на асме. Привет нынешним выпускникам университетов! :)
2. Получил хорошее представление по оптимизации систем, работе баз данных, работе файловых систем, структур данных, кэшей.
3. Умение поставить пару пикселей где надо.
4. Веб-движок, который развивается и кормит меня уже десять лет. Писался с заделом под ZX-Art.
Мне кажется подобный тул по сравнению картинок наверное лучше пилить, тестировать и запускать чисто локально, раз уж применимость столь узкая — для каких-то частных исследований. Нагрузку он даст приличиную, а смысла грузить общий сервер для узкой задачи — никакого.
это, конечно, при условии, что текущая ситуация всё же будет поправлена по плану, который я выше набросал :)
Я думаю, что нет проблем иметь похожие работы или даже какой-то процент дублей в скриншотах к продам. А в галереях авторов всё равно всё выбрано вручную.
Так как хочется сделать именно агрегатор, то полная аккуратность, вероятнее всего, принципиально недостижима.
Зачем? Если без разницы сколько у нас дублей разной степени похожести и схожих скриншотов — то наверное не зачем. Если мы хотим быть уверены, что у нас в базе не затесались похожие картинки, например по каким-то причинам загруженные в разных авторов, или иметь возможность сравнивать скриншоты по степени схожести, то проводить подобные проверки время от времени было бы полезно. При росте базы появление дублей и бОльшего количества схожих картинок, мне кажется, неизбежен.
Можно даже не считать пиксели, можно сжать картинку любым паковщиком и посмотреть размер. Скорее всего чем больше размер сжатой картинки — тем больше различий.
Да, я о чем-то таком и думал. + для ускорения — можно сначала отсеить тупо по разнице атрибутов — в разы быстрее. Хотя, наверное, ты это и имел ввиду.
  • avatar Shiru
  • 1
Я бы сходу предложил такой вариант, для частного случая ZX графики: вычитаем цвет каждого пикселя одной картинки из другой. Если они совпадают на 100%, остаётся чёрный экран. Если нет, остаётся N пикселей, тем больше, чем больше различий.

В любом случае полностью автоматически искать нечёткие дубли сложно, но можно строить список потенциальных дублей по некоторому порогу, чтобы дальше их оценил человек.
  • avatar Shiru
  • 1
Иван Рощин в статье про конверсию графики для ч/б мониторов с увеличением градаций яркости (цвета = разные яркости в ч/б) оценивал качество конверсии по степени сходства с картинкой до конверсии.

www.ivr.webzone.ru/articles/bw/app_1.htm
Да я просто люблю упоротые алгоритмы. При необходимости придумать хитрый способ — не проблема. Но вопрос — зачем, да)
Кстати, приведенная картинка похожа процентов на 70, если правильно подойти к вопросу. Треть экрана 1-в-1 + очень много пересечений в верхних долях.
  • avatar nyuk
  • 2
еще можно нейронную сеть прикрутить, обучить её как надо, и через год проблема этих самых 10-20 дублей будет решена :)
Звучит как инструкция «как нарисовать сову» :)
Какие есть мысли по хеш-функции? Я видел только такой рецепт — картинка уменьшается до микроразмера, постеризуется и каждый пиксель превращается в кусок хэша. Это хорошо работает с большими картинками, но повторно использованные куски (одни и те же спрайты, например) оно не покажет.

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

И всё же мой главный вопрос — а зачем :) Похожая графика уже объединена по авторам и по играм. Дубликатов больших заставок штук 10-20, и это в основном версии с разными логотипами (Where time stoods still)