Тут на самом деле только одна задача. Детектирование фона. Она интересна и ее можно пообсуждать.
Особенно если это мусорное ведро было снято не на хромокее а просто на какой-то рандомной подложке.
А остальное - это скрипты. Отцентрировать. Сделать 3 копии каскадом.
А во вторых непонятно что такое честная оценка модели? Ты привел две гистограммы и одна из них явно ошибочная. Потому что сильно большие различия. Такого быть не должно. Ты делал shuffle для всей совокупности?
У меня был Intel Atom 32х бит тоже 13 года. Я родителям покупал. Вместе с Window-XP.
Нормально там и youtube можно было смотерть.
Давайте будем честны. Ну не игровая эта платформа Debian. Тем более что если искать
дрова по состоянию на 2013 год то найдете то что как раз и было 10 лет назад в статусе
поддержки игр.
Есть известный доклад Алименкова на тему JMS и он там где-то рекомендует вместо пересылки по MQ толстых файлов - складывать их в любое key-value хранилище и передавать по MQ только линку на файл.
С моей точки зрения это правда имеет смысл но только в том случае если чтение файла - опционально. Тоесть потребитель может захотеть читать файл а может и нет.
Александр Ананьев, почему. Не факт. Шрифты и векторные фигурки он рисует нормально. Насчет пикселей я не уверен. Ну я-бы протестировал еще раз. Последний раз я игрался лет 7 назад в графику.
Хрен его знает какой тут фильтр. Можешь приаттачить 2 фото. Например слева чтоб было такое фото с дымкой. А справа - ты чуть наклонил объектив и снял нормально. Тогда может люди подскажут комбинацию фильтров.
MrakLula, я не знаю что такое "напрямую". Но мне показалось визуально что перформанс
при работе с SDL в Windows был быстрее чем если-бы я рисовал это GDI+ на Bitmap context
и отображал бы этот bitmap по событию OnPaint(HDC hdc). Вот. Если кто-то может объяснить
почему работа с SDL быстрее чем c GDI+ - то я был бы рад. Я не могу объяснить но мне для
себе и не особо нужно. Просто так вижу.
forced, смотри It доклады и конференции очень крупных компаний которые уже что-то сделали и хвастаются как у них там все ловко и хитро. Тут особенно ценен опыт докладчика который не теоретик а как раз зашел со стороны инженерной. Тоесть он уже горел в performance issues, он видел сложные баги которые никакой теоретик не придумает просто в силу синергии многих технологий. И как он эти баги решал. Мне например было интеренсно послушать доклады про протокол Http3/Quic и просто понять что все мои представления о скорости TCP были немного другие. Вот. Много докладов было в разделах Amazon (AWS) кажется где крупные компании (авиа, транспорт, продажи) хвастаются где они чего соптимизировали.
В целом векторы оптимизации - почти всегда это event sourcing, partitioning, ослабление уровней ACID
и все в условиях когда бизнес этому удовлетворяет.
Вот. А EAV - это взгляд из 20-го века. Он безнадежно устарел и его обычно читают старые и дряхлые преподаватели-куколды которые только и помнят что Турбо-Паскаль и БД Информикс. Современные БД
поддерживают документы блобы в XML/JSON и не нужен тебе ЕАВ аж никогда.
Нормализации нет предела. Можно считать что руководители и исполнители - это суть персоны. И их персональность - это тоже реляция в данной модели.
Вобщем слушай автор. В Mongo и в Cassandra и в Couchdb данные лежат не в нормалях в агрегатах.
И это считается best practices. Я не хочу сказать что тебе нужны агрегаты. Просто существуют
в природе и такие задачи и они вполне себе живут. Особенно если данные исторические
и больше не меняются. Или меняются только как журнал (append only) или исторические
метаданные.
Особенно если это мусорное ведро было снято не на хромокее а просто на какой-то рандомной подложке.
А остальное - это скрипты. Отцентрировать. Сделать 3 копии каскадом.