Спасибо за все присланные источники. Насчет конверсий всё же сильно сомневаюсь.
Растянул и повернул собаку, но так и не добился попадания в контуры. Заодно попробовал её конвертнуть в монохром, не смог добиться таких деталей — может, конечно, у автора была какая-то сильно более резкая фотка, но очень сомневаюсь. Возможно, это сильно допиленная конверсия, но не попадающие контуры (в том числе и световых пятен, шея, под глазом, подсвеченный контур головы) не очень-то подтверждают эту версию. Скорее всего — аккуратная перерисовка на глаз или обрисовка контура (на атари или амиге? не представляю, как тогда это делалось).
Этому есть решения разной степени ущербности, но это всё сильно за рамками ретро-тематики. Пока что надо смириться с фактом — мобильники для быстрой работы не заморачиваются аккуратно масштабировать сайты и игнорят всё ту же гамма-коррекцию. Это мало кому нужно, поэтому вряд ли поправится в ближайшие годы.
Спасибо, звучит очень логично, и про режимы, и про цветовую температуру.
В целом, это касается любой палитры: если хочется видеть картинку в той палитре, какую задумывал автор палитры (будь то Pulsar, Orthodox или еще что), придется отключать любые надстройки и кастомизации, влияющие на гамму. То есть, любимый режим монитора изначально не подразумевает канонично правильной картинки монитора, этот функционал для того и создан, чтобы канононично «правильную» заводскую картинку настроить под себя. Правильную я взял в кавычки, потому что идеального соответствия вроде как ни одна матрица принципиально не обеспечивает, равно как и понакрутить на заводе могут тоже изрядно. Да и в цветовых профилях, скачиваемых под конкретные модели для ОС, может быть изрядная дичь внутри, практикой подтверждалось.
То есть, сама постановка вопроса такова, что для стабильно одинаковой картинки нужны стабильно одинаковые настройки железа. Одинаковость в данном обеспечивается следованием стандарту SRGB. А в других случаях одинаковость не обеспечивается вообще ничем. Если бы я не попросил попробовать поглядеть эту гифку, но большинство так и не узнало бы об особенностях своих матриц :) Повторюсь, если на гифке SRGB выглядит с границами, то это уже само по себе говорит об искажениях всех картинок во всех палитрах.
Есть, правда, совсем ненулевая вероятность, что у кого-то матрица искажает картинку таким образом, что чудесным образом гамма попадает в оттенки той же палитры Pulsar, но вероятность этого очень невелика.
Идеальное решение требует идеального монитора, и это — главный камень преткновения. Я верю, что это со временем улучшится, просто предлагаю хотя бы цвета на него выдавать, не побоюсь этого слова, правильные. Правильные в рамках стандарта, прежде всего. И чем лучше монитор этот стандарт реализует, тем точнее будет выглядеть авторский замысел.
Спасибо!
В целом неудивительно. IPS-матрицы цветопередачу имеют сильно более аккуратную, чем TN.
zxart.ee/userfiles/images/srgb/srgb.gif — всё упирается в эту картинку. Если на ней сильные границы между левыми и правыми половинами, то цветопередача на мониторе, прямо скажем, не очень. У меня на LG 24mp59g еще веселее, у меня сетки имеют оттенки, и эти оттенки меняются в зависимости от координат картинки от зеленого к красному. Ну, тут весь монитор интересен — у него какой-то ШИМ используется, что ли, так как на некоторых оттенках синего видны вертикальные полоски.
Зато AOC показывает близко к идеальному, даже мигающие квадраты близки к сетке и смешанным, что на IPS матрицах с их откликом вообще чудо.
К сожалению, подстройка невозможна принципиальна. Пока что да, можно было бы по идее сделать ручную подстройку ZN, NN, ZB под конкретный монитор, но есть высокая вероятность, что само понятие уровней ZN, NN, ZB совершенно далеко от реала. То есть, на реале небрайтовые цвета имеют разные уровни в разных каналах, как, собственно, и брайтовые. Как минимум это можно заявить про темно-синий, который, судя по некоторым материалам и замерам, действительно был на реальном железе высветлен практически до уровня ярко-синего.
То есть, уже есть один цвет, не укладывающийся в общую схему ZN, NN, ZB, и есть сильное подозрение, что он не один, а все 15 цветов абсолютно не подчиняются стройной логике. То есть, есть вероятность, что в конечном итоге мы прийдем к варианту, когда нам каждые два цвета придется реально смешивать на лету отдельно. И, опять же, описанный в статье принцип должен это прекрасно решить, но переписать придется многое.
Несмотря на вылившееся в чатике очень неприятное и откровенно снобское отношение, я отвечу на твои претензии, чтобы эти ответы могли увидеть остальные читатели.
1. Спасибо, имя палитры в конце статьи поправил, это был копи-пейст, оставшийся вчера в два часа ночи незамеченным.
2. Я не предлагал заменить палитру втихаря на сайте, не надо распространять ложную информацию. Я просто привел пример, чтобы показать, что никакого апокалипсиса моё уточнение не вызовет, так как его все равно почти никто не заметит, если специально не показать сравнение.
3. Я специально написал, что на телефонах сравнивать не надо. Дело тут не в картинках, а дело в том, что на Hype у меня нет технической возможности заставить телефоны работать без ресэмплинга картинок. И да, ресэмплинг картинок точно так же искажает и палитру pulsar.
4. Про выбивание нужного монитора абсолютно такая же чушь написана. Да, мониторы могут быть плохими. Да, это влияет на палитру. Да, это абсолютно на сто процентов так же искажает и палитру pulsar. Да и любую другую палитру. Нет, без хорошей матрицы и калибровки монитора правильной картинки принципиально не добиться. Впрочем, как и с любой другой палитрой, так-то.
5. Да, время отклика на разных монитарх разное. Нет, это не повод игнорировать стандарт или сочинять свой.
6. Я предложил не палитру, а способ подсчета коэффициентов смешивания. В чем разница — предлагаю подумать заново, почитав статью еще раз. Более того, я настаиваю на том, что весь текущий способ задачи палитры необходимо пересмотреть и выкинуть. Уже один единственный факт того, что темно-синий на реальном ZX ярче остальных темных рушит до основания весь имеющийся способ расчета noflic. Кроме предложенного мной, ибо я взял самое примитивное, что можно придумать — тупо смешать два цвета по строгим имеющимся правилам, и этот принцип будет работать с любым набором оригинальных цветов.
7. Способов смешивания цвета очень много. Как с этим справляются выбранные через Gimp коэффициенты палитры, я уже показал. Может быть, на каком-то оборудовании оно лучше, но берусь настаивать, что конкретно SRGB пространство, на котором сейчас вы читаете хайп, имеет совершенно иные принципы.
8. На вопрос про смысл отвечу, что смысла нет. Смысла вообще ни в чем нет. Кого это беспокоит — может ложиться и помирать, а мы будем понемножку экспериментировать дальше для удовлетворения личного любопытства.
Спасибо, хорошо написано. Любопытно было узнать про vrc6 и поглядеть сравнение akumajou densetsu с ним и без.
Музыка отличная, авторам спасибо — реально очень уровень хороший.
Лекарство для браузеров. Пока что поддерживается очень криво, но вот такой вариант уже сейчас отключит фильтрацию при ресэмплинге в хроме и файрфоксе. Соответственно, и проблема гаммы отпадёт.
Любопытно, что только 8 человек удосужились что-то написать. Какие-нибудь выводы для себя удалось сделать? А то я, например, почитал всех, было любопытно, но не могу сказать, чтобы что-то в голове поменялось.
Не жалею совершенно. Если посмотреть сугубо профессиональные трофеи от спектрумизма, то в сухом остатке имею:
1. Первую программу, написанную 21 год назад на асме. Привет нынешним выпускникам университетов! :)
2. Получил хорошее представление по оптимизации систем, работе баз данных, работе файловых систем, структур данных, кэшей.
3. Умение поставить пару пикселей где надо.
4. Веб-движок, который развивается и кормит меня уже десять лет. Писался с заделом под ZX-Art.
Я думаю, что нет проблем иметь похожие работы или даже какой-то процент дублей в скриншотах к продам. А в галереях авторов всё равно всё выбрано вручную.
Так как хочется сделать именно агрегатор, то полная аккуратность, вероятнее всего, принципиально недостижима.
Звучит как инструкция «как нарисовать сову» :)
Какие есть мысли по хеш-функции? Я видел только такой рецепт — картинка уменьшается до микроразмера, постеризуется и каждый пиксель превращается в кусок хэша. Это хорошо работает с большими картинками, но повторно использованные куски (одни и те же спрайты, например) оно не покажет.
Вот эти две картинки, например, похожи очень по деталям, но не по общей композиции. Единственный вариант, как сравнить детали — поделить картинку на знакоместа (?) и отдельно прохешировать какие-то из них (не все, все не нужны), а потом найти общие вхождения.
И всё же мой главный вопрос — а зачем :) Похожая графика уже объединена по авторам и по играм. Дубликатов больших заставок штук 10-20, и это в основном версии с разными логотипами (Where time stoods still)
В принципе, поиск похожих картинок — не фантастика в целом. Другое дело, что похожих картинок раз два и обчелся, даже копии одного и того же оригинала обычно кардинально различаются.
Со скриншотами по идее можно разбить картинку на знакоместа, прохэшировать какое-то подмножество знакомест по каким-то критериям заполненности и проиндексировать картинки по вхождению знакомест. Но зачем? Да и для скринов, где спрайт на пиксель сдвинут, этот метод не сработает. Самое главное, что потребности не так много. MD5 выявит большую часть дублей, а остальное пусть остается как есть — необязательно все скриншоты рассортировывать по авторам и превращать в картинки. Пусть в галерее автора будут избранные картинки из игры, специально снятые для этой цели, а в скриншотах прода будут все скрины со всех источников в произвольных форматах.
План такой:
1. Обновить систему хранения md5 у картинок, чтобы она была общей с релизами.
2. В выбранном релизе показывать картинки и скриншоты общим списком.
3. Через md5 убрать скриншоты, которые есть в виде картинок.
4. Сделать кнопку, позволяющую быстро сделать картинку из скриншота игры с указанием авторства.
Спасибо, согласен! Так-то еще оценки надо (для топов по категориям) обязательно.
Примечание, в целом, вроде есть уже.
Формат нужен больше для системных потребностей — так проще встроить фильтр в категорию, чтобы видеть только программы под диск или под ленту.
Растянул и повернул собаку, но так и не добился попадания в контуры. Заодно попробовал её конвертнуть в монохром, не смог добиться таких деталей — может, конечно, у автора была какая-то сильно более резкая фотка, но очень сомневаюсь. Возможно, это сильно допиленная конверсия, но не попадающие контуры (в том числе и световых пятен, шея, под глазом, подсвеченный контур головы) не очень-то подтверждают эту версию. Скорее всего — аккуратная перерисовка на глаз или обрисовка контура (на атари или амиге? не представляю, как тогда это делалось).
developer.mozilla.org/ru/docs/Mozilla/Mobile/Viewport_meta_tag
Этому есть решения разной степени ущербности, но это всё сильно за рамками ретро-тематики. Пока что надо смириться с фактом — мобильники для быстрой работы не заморачиваются аккуратно масштабировать сайты и игнорят всё ту же гамма-коррекцию. Это мало кому нужно, поэтому вряд ли поправится в ближайшие годы.
В целом, это касается любой палитры: если хочется видеть картинку в той палитре, какую задумывал автор палитры (будь то Pulsar, Orthodox или еще что), придется отключать любые надстройки и кастомизации, влияющие на гамму. То есть, любимый режим монитора изначально не подразумевает канонично правильной картинки монитора, этот функционал для того и создан, чтобы канононично «правильную» заводскую картинку настроить под себя. Правильную я взял в кавычки, потому что идеального соответствия вроде как ни одна матрица принципиально не обеспечивает, равно как и понакрутить на заводе могут тоже изрядно. Да и в цветовых профилях, скачиваемых под конкретные модели для ОС, может быть изрядная дичь внутри, практикой подтверждалось.
То есть, сама постановка вопроса такова, что для стабильно одинаковой картинки нужны стабильно одинаковые настройки железа. Одинаковость в данном обеспечивается следованием стандарту SRGB. А в других случаях одинаковость не обеспечивается вообще ничем. Если бы я не попросил попробовать поглядеть эту гифку, но большинство так и не узнало бы об особенностях своих матриц :) Повторюсь, если на гифке SRGB выглядит с границами, то это уже само по себе говорит об искажениях всех картинок во всех палитрах.
Есть, правда, совсем ненулевая вероятность, что у кого-то матрица искажает картинку таким образом, что чудесным образом гамма попадает в оттенки той же палитры Pulsar, но вероятность этого очень невелика.
В целом неудивительно. IPS-матрицы цветопередачу имеют сильно более аккуратную, чем TN.
zxart.ee/userfiles/images/srgb/srgb.gif — всё упирается в эту картинку. Если на ней сильные границы между левыми и правыми половинами, то цветопередача на мониторе, прямо скажем, не очень. У меня на LG 24mp59g еще веселее, у меня сетки имеют оттенки, и эти оттенки меняются в зависимости от координат картинки от зеленого к красному. Ну, тут весь монитор интересен — у него какой-то ШИМ используется, что ли, так как на некоторых оттенках синего видны вертикальные полоски.
Зато AOC показывает близко к идеальному, даже мигающие квадраты близки к сетке и смешанным, что на IPS матрицах с их откликом вообще чудо.
То есть, уже есть один цвет, не укладывающийся в общую схему ZN, NN, ZB, и есть сильное подозрение, что он не один, а все 15 цветов абсолютно не подчиняются стройной логике. То есть, есть вероятность, что в конечном итоге мы прийдем к варианту, когда нам каждые два цвета придется реально смешивать на лету отдельно. И, опять же, описанный в статье принцип должен это прекрасно решить, но переписать придется многое.
1. Спасибо, имя палитры в конце статьи поправил, это был копи-пейст, оставшийся вчера в два часа ночи незамеченным.
2. Я не предлагал заменить палитру втихаря на сайте, не надо распространять ложную информацию. Я просто привел пример, чтобы показать, что никакого апокалипсиса моё уточнение не вызовет, так как его все равно почти никто не заметит, если специально не показать сравнение.
3. Я специально написал, что на телефонах сравнивать не надо. Дело тут не в картинках, а дело в том, что на Hype у меня нет технической возможности заставить телефоны работать без ресэмплинга картинок. И да, ресэмплинг картинок точно так же искажает и палитру pulsar.
4. Про выбивание нужного монитора абсолютно такая же чушь написана. Да, мониторы могут быть плохими. Да, это влияет на палитру. Да, это абсолютно на сто процентов так же искажает и палитру pulsar. Да и любую другую палитру. Нет, без хорошей матрицы и калибровки монитора правильной картинки принципиально не добиться. Впрочем, как и с любой другой палитрой, так-то.
5. Да, время отклика на разных монитарх разное. Нет, это не повод игнорировать стандарт или сочинять свой.
6. Я предложил не палитру, а способ подсчета коэффициентов смешивания. В чем разница — предлагаю подумать заново, почитав статью еще раз. Более того, я настаиваю на том, что весь текущий способ задачи палитры необходимо пересмотреть и выкинуть. Уже один единственный факт того, что темно-синий на реальном ZX ярче остальных темных рушит до основания весь имеющийся способ расчета noflic. Кроме предложенного мной, ибо я взял самое примитивное, что можно придумать — тупо смешать два цвета по строгим имеющимся правилам, и этот принцип будет работать с любым набором оригинальных цветов.
7. Способов смешивания цвета очень много. Как с этим справляются выбранные через Gimp коэффициенты палитры, я уже показал. Может быть, на каком-то оборудовании оно лучше, но берусь настаивать, что конкретно SRGB пространство, на котором сейчас вы читаете хайп, имеет совершенно иные принципы.
8. На вопрос про смысл отвечу, что смысла нет. Смысла вообще ни в чем нет. Кого это беспокоит — может ложиться и помирать, а мы будем понемножку экспериментировать дальше для удовлетворения личного любопытства.
Музыка отличная, авторам спасибо — реально очень уровень хороший.
1. Первую программу, написанную 21 год назад на асме. Привет нынешним выпускникам университетов! :)
2. Получил хорошее представление по оптимизации систем, работе баз данных, работе файловых систем, структур данных, кэшей.
3. Умение поставить пару пикселей где надо.
4. Веб-движок, который развивается и кормит меня уже десять лет. Писался с заделом под ZX-Art.
Так как хочется сделать именно агрегатор, то полная аккуратность, вероятнее всего, принципиально недостижима.
Какие есть мысли по хеш-функции? Я видел только такой рецепт — картинка уменьшается до микроразмера, постеризуется и каждый пиксель превращается в кусок хэша. Это хорошо работает с большими картинками, но повторно использованные куски (одни и те же спрайты, например) оно не покажет.
Вот эти две картинки, например, похожи очень по деталям, но не по общей композиции. Единственный вариант, как сравнить детали — поделить картинку на знакоместа (?) и отдельно прохешировать какие-то из них (не все, все не нужны), а потом найти общие вхождения.
И всё же мой главный вопрос — а зачем :) Похожая графика уже объединена по авторам и по играм. Дубликатов больших заставок штук 10-20, и это в основном версии с разными логотипами (Where time stoods still)
Со скриншотами по идее можно разбить картинку на знакоместа, прохэшировать какое-то подмножество знакомест по каким-то критериям заполненности и проиндексировать картинки по вхождению знакомест. Но зачем? Да и для скринов, где спрайт на пиксель сдвинут, этот метод не сработает. Самое главное, что потребности не так много. MD5 выявит большую часть дублей, а остальное пусть остается как есть — необязательно все скриншоты рассортировывать по авторам и превращать в картинки. Пусть в галерее автора будут избранные картинки из игры, специально снятые для этой цели, а в скриншотах прода будут все скрины со всех источников в произвольных форматах.
1. Обновить систему хранения md5 у картинок, чтобы она была общей с релизами.
2. В выбранном релизе показывать картинки и скриншоты общим списком.
3. Через md5 убрать скриншоты, которые есть в виде картинок.
4. Сделать кнопку, позволяющую быстро сделать картинку из скриншота игры с указанием авторства.
Примечание, в целом, вроде есть уже.
Формат нужен больше для системных потребностей — так проще встроить фильтр в категорию, чтобы видеть только программы под диск или под ленту.