Я бы даже сказал, что она практически везде лучше (как минимум не хуже), чем по байтамСообщение от svofski
Мандрила я неупорядоченно дизернул этой утилитой. Твои примеры позже посмотрю.
Над вейвлетами применительно к вектору я не думал, но почему бы и нет. Правда у меня нет серьезных планов по сжатию картинок, вроде и востребованности особой нет, всех более-менее устраивают имеющиеся решения.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Это не столько ради сжатия, скорее ради эффекта проявления изображения. Если рандом, упаковать по маршруту, если прогрессивно, то и сохранять прогрессивно.
Но интерес обсуждать тут это у меня пару сообщений назад почему-то пропал.
Больше игр нет
Ordered дизерилку и твои примеры глянул. Признаюсь, что диагонального варианта до сих пор не видел, он своеобразный, возможно где-то подойдет для художественного эффекта. А в общем случае я все же за Байера.
Что касается проявления полноэкранной картинки, то есть еще варианты, например типастеганография. Если полутоновое изображение (для ч/б ТВ, с 16 оттенками) то можно саму программу скромно расположить в младшем бите изображения в уголке. Если подобрать картинку, то будет не очень заметно. С цветными сложнее, разве что очень повезет с картинкой и палитрой.
Ну и совсем дубовый вариант и тоже не всеподходящий. Программу максимально компактируем, рисуем напрямую там где не пересекаемся с кодом, а туда, где пересекаемся, в конце распаковываем остаток картинки.
Я не могу отдать предпочтение какому-то одному способу дизера на все случаи жизни. Но диагональный интересный. Напоминает журнальный принт, при этом прикольно выглядит даже при таком невысоком разрешении, особенно некоторые удачные сочетания цветов.
Это скорее непочатый край. Никто особенно и не думает -- покажу ка я Вектором картинку. Ну просто практическая ценность этого невелика из-за непропорциональности объема памяти. Если ты например делаешь демку и нарисовал к ней какой-нибудь графоний, получается, что у тебя вот и вся демка. Совместить упаковку и интересный эффект это одновременно и способ немножко сместить баланс памяти в чуть более выгодную сторону и прикрыть тормознутость чем-то, на что может быть интересно смотреть, особенно если жужжит ви53 и все вокруг кричат амига.
Вот например, очень часто встречающийся эффект -- большая картинка, то есть высотой больше одного экрана, вертикально скроллится. Отличный кейс для вертикального скролла и распаковки на лету. Правда из-за столбцовой организации памяти не получится пользоваться самой картинкой как буфером, это вот очень жаль.
Зато мы можем сделать 128 (32*4) параллельных dzx0 с буферами прямо на скроллящемся экране. Эх, не ту вещь я назвал гигачадом.
- - - Добавлено - - -
Да, я тоже пробовал этой сначала. Прикольно, что есть заточка на специфические палитры и компы и даже Вектор не забыт. Я пытался загрузить твою палитру, но чего-то не задалось. Кроме того там пока нету упорядоченных дизеров, надеюсь еще будут. Пока мне проще довести картинку до требуемого пиксельформата в IrfanView, сохранить в png и остальное уже сконвертить скриптом. Не знаю, чем ты получал свой pic и pal, но подозреваю, что тоже какой-то самодельной штукой.
Больше игр нет
Да, я скорее о малой востребованности, а не о наличии очень хороших упаковщиков/распаковщиков картинок для вектора, которые окончательно закрывают этот вопрос.
Кстати про байты vs пиксели. Количественно можно оценить сжав для сравнения bmp - он сжимается лучше и zx0 и особенно ripом. А если еще порядок обхода сменить с построчного на поблочный, то будет еще лучше.
Насчет прогрессивной детализации самый простой и приземленный вариант мне видится так - делим картинку на четные и нечетные столбцы. Четные пакуем, нечетные можно не паковать. Выводим нечетные, потом на их место распаковываем четные и тоже выводим. Полета фантазии тут нет, но схема рабочая.
Гигачад128 даже немного пугает, я бы пожалуй в описанном случае предпочел (для простоты) построчную распаковку в буфер.
- - - Добавлено - - -
Да, состряпал преобразование rmb->pic, а pal - это просто первые 16 байт rmb. DaDither хорошая утилита, но там, кончено не все есть. Привлекает простота использования, а то мне не очень хотелось сдувать пыль со своих старых матлабовских дизерилок, вспоминать как ими пользоваться и подбирать параметры.
Последний раз редактировалось ivagor; 09.09.2022 в 14:30. Причина: исправил rmp на rmb
Из всего озвученного, как ни странно, гигачад128 это чуть ли не самое простое, потому что по сути надо просто изменить параметр n_tasks и прописать адрес первого буфера $8000. Процедуру записи в AY можно оставить для устрашения
Это конечно же способ. Не знаю насчет зрелищности, но наверное с минимумом накладных расходов.
Про байты vs пиксели: твой пример с проявлением мандрила по пикселям можно считать потолком пиксельной производительности. Там можно оптимизировать итд, но любой алгоритм себе потребует еще больше, так что для оценки норм.
Больше игр нет
Увы, но скорее всего это так, сделать быстрее 10 секунд сложно. Для сравнения мой старый выводильщик bmp полноэкранную картинку выводит за 13 секунд.
Так к слову сказать, полноэкранная цветная картинка с половинным горизонтальным разрешением может смотреться вполне себе очень даже. На C64 "multicolor bitmap mode" тому пример.
Больше игр нет
Можно вспомнить и более близкий пример - роббо sunami с атариевской графикой. Кроме нижней строки статуса все в половинном разрешении, смотрится и на векторе нормально. Для полного счастья не хватает только такого аппаратного режима графики, чтобы памяти в 2 раза меньше занимал.
Раз уж атари, то всегда вспоминается Montezuma's Revenge. Знаю знаю, Амбал очень крут и я согласен. Но он не играет кукарачу и вот как-то не то.
- - - Добавлено - - -
Еще один дизерятник, тоже со своими забавными пресетами, но не поддерживает диагоналей: https://doodad.dev/dither-me-this/
Больше игр нет
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
