Solitaire is an output-feedback mode stream cipher.
Насколько я могу судить, обратная связь по выходу затрагивает только изменение гаммы, непосредственно после генерации каждого символа ключевой последовательности. У меня это отражено во фразе:
На самом деле я почти в самом начале разработки отчаялся и хотел выдать юзер скрипт, чтобы пользователь сам подбирал удачные оттенки… Но все же это не гуд. Нужен полностью автономный алгоритм.
Очень даже хорошо справляется Ваш алгоритм. Правда на выходе почти у каждого оттенка есть сильно похожий на него…
Да и просмотрев Ваши работы, заметил ту же пропасть, что и у меня. Некоторые, даже довольно часто встречающиеся цвета он совсем не выводит… Я откомментировал в пикассе 2 самые выделяющиеся работы.
Ну если абстрагироваться до твоего варианта, то я по сути, пытаюсь найти центр облака подобных и выделить центровой цвет, тем самым убиваю большое количество точек вокруг облака. После нескольких итераций, остаются довольно отчетливые отдельно-стоящие островки, которые как раз и необходимы.
Но тут возникает самая большая трудность, это обработка облака. С одной стороны необходимо выделить центр, что уже является трудоемкий задачей, а с другой стороны этот центр должен выбирать. В моем алгоритме есть такая зависимость, что цвет A похож на B и цвет С похож на В, но А не похож на С. Соответственно центру А необходимо выбирать, поглощать цвет В или нет, но по сути такое реализовать крайне сложно.
Т.к. я все преследую умеренную ресурсоемкость, то и решение должно быть крайне простым, поэтому я даже и не пытаюсь лезть в дебри подобных алгоритмов. Проще всего задействовать человеческий фактор по окончании обработки, пусть человек доделывает все, как надо.
Но я думаю, что следующим шагом обработки я возьму HSV координаты, т.к. с помощью них крайне легко определить похожесть цвета и яркость цвета.
Яркость точки определятся количеством вхождений цвета?
Определить доминирующий цвет или цвета на самом деле не трудная задача. Куда труднее выбрать контрастные цвета. Возможно изображение будет изобиловать какими-то 4 превалирующими оттенками, которые будут занимать 98% изображения, но если где-то посередине появится цвет, контрастный остальным, окружающим его и он займет оставшиеся 2% изображения, то он не попадет в список «доминирующих», но должен попасть в список основных тонов изображения.
Я решаю это проблему практически в лоб и каждый раз лишь заостряю инструмент, но не создаю нового подхода… Соответственно, если в следующий раз меня опять припрет усовершенствовать приложение, т.е. я его буду переписывать с 0.
Я постараюсь поподробнее рассмотреть этот вариант, хотя локальные максимумы еще ни о чем не говорят. Доминирующие тона — это не просто самые часто встречающиеся цвета, а в то же время и контрастные. Этими контрастными цветами может быть цвет губной помады, маленький зеленый листок посреди снега итд. Он не обязательно будет превалировать в количестве, но будет тут же заметен глазам и поэтому в идеале он должен попасть в выдачу. Собственно я именно эту цель и преследовал, хотя работать еще много есть над чем…
Я писал про 2 допущения, которые делаются при анализе изображения.
1. Шаг выборки пикселей (10px)
2. Количество возвращаемых цветов
На изображении куда больше бежевых оттенков (особенно учитывая градиент), также возможно голубые оттенки просто не попали в шаг в том количестве, в котором попали бежевые.
На локалке пробежался по каждому 2 пикселю и увеличил количество яркостных интервалов до 4. Вот, что получил:
Я забыл упомянуть, что алгоритм был описан в прошлой статье.
Цвета он берет из самого изображения, но их он сглаживает при наличии подобных цветов. Т.е. если есть градиент на изображении, то он выдаст некое среднее из этого градиента (с учетом яркости само собой).
Если, к примеру, изображение наполнено белым (255,255,255) цветом на 90% и серым (200,200,200) на 10%, то в итоге он должен выдать серый (250,250,250)
Насколько я могу судить, обратная связь по выходу затрагивает только изменение гаммы, непосредственно после генерации каждого символа ключевой последовательности. У меня это отражено во фразе:
*акцент сделать на «поговорить о политике»*
Да и просмотрев Ваши работы, заметил ту же пропасть, что и у меня. Некоторые, даже довольно часто встречающиеся цвета он совсем не выводит… Я откомментировал в пикассе 2 самые выделяющиеся работы.
Но тут возникает самая большая трудность, это обработка облака. С одной стороны необходимо выделить центр, что уже является трудоемкий задачей, а с другой стороны этот центр должен выбирать. В моем алгоритме есть такая зависимость, что цвет A похож на B и цвет С похож на В, но А не похож на С. Соответственно центру А необходимо выбирать, поглощать цвет В или нет, но по сути такое реализовать крайне сложно.
Т.к. я все преследую умеренную ресурсоемкость, то и решение должно быть крайне простым, поэтому я даже и не пытаюсь лезть в дебри подобных алгоритмов. Проще всего задействовать человеческий фактор по окончании обработки, пусть человек доделывает все, как надо.
Но я думаю, что следующим шагом обработки я возьму HSV координаты, т.к. с помощью них крайне легко определить похожесть цвета и яркость цвета.
Определить доминирующий цвет или цвета на самом деле не трудная задача. Куда труднее выбрать контрастные цвета. Возможно изображение будет изобиловать какими-то 4 превалирующими оттенками, которые будут занимать 98% изображения, но если где-то посередине появится цвет, контрастный остальным, окружающим его и он займет оставшиеся 2% изображения, то он не попадет в список «доминирующих», но должен попасть в список основных тонов изображения.
Я решаю это проблему практически в лоб и каждый раз лишь заостряю инструмент, но не создаю нового подхода… Соответственно, если в следующий раз меня опять припрет усовершенствовать приложение, т.е. я его буду переписывать с 0.
Исчез зеленый. В общем я уже нашел, как сделать этот алгоритм еще более крутым и адекватным, но на это требуется еще одна чесотка рук =)
А собственно сколько Вам необходимо цветов?
1. Шаг выборки пикселей (10px)
2. Количество возвращаемых цветов
На изображении куда больше бежевых оттенков (особенно учитывая градиент), также возможно голубые оттенки просто не попали в шаг в том количестве, в котором попали бежевые.
На локалке пробежался по каждому 2 пикселю и увеличил количество яркостных интервалов до 4. Вот, что получил:
Цвета он берет из самого изображения, но их он сглаживает при наличии подобных цветов. Т.е. если есть градиент на изображении, то он выдаст некое среднее из этого градиента (с учетом яркости само собой).
Если, к примеру, изображение наполнено белым (255,255,255) цветом на 90% и серым (200,200,200) на 10%, то в итоге он должен выдать серый (250,250,250)