Алгоитм получения случайного цвета

[ARV]

в моём проекте DIGISCRIPT для формирования случайных чисел я использую функцию rand(). все её ограничения по длине псевдослучайной последовательности мне известны и никак не мешают. для получения случайного байта в первой версии проекта я тупо отбрасывал старший байт возвращаемого rand() значения, а для формирования еще меньших чисел, использовал результат операции %, т.е. если хотел получить случайное число не более 25, то делал так: rand() % 25
во второй версии я учел недостатки вышеописанного подхода и теперь использую такой вариант получения случайного числа с ограничением:

Код: Выделить всё

int range_rand(int range){
   return (rand() * (uint32_t)range)/RAND_MAX;
}

наверное, можно еще как-то улучшить... но сейчас вопрос о другом.

вопрос о том, что для получения случайного цвета используется эта самая функция range_rand(0x100), которая определяет условный номер оттенка. и часто бывает так, что она возвращает, например, подряд 1 и 2 или 5 и 7, т.е. достаточно близкие оттенки, глазом воспринимаемые, как одинаковые.

так вот, в чем, собственно, вопрос: как улучшить выбор случайного номера оттенка из диапазона 0...255 так, чтобы не возникало подряд два близких оттенка?

пока применяю вариант проверки: пока получаю номер оттенка, отличающийся от предыдущего меньше, чем на заданную величину, повторяю вызов функции случайного числа. оно вроде работает, но не так, чтобы я был совсем доволен...

что посоветуете?

[ПростоНуб]

ARV, прибавляйте к текущему цвету, например, 4, а затем псевдослучайное число в интервале от 0 до 247 (255-4*2)

[ARV]

чевой-то не понял... допустим, текущий цвет 5. я прибавил 4, получил 9. запросил случайное число от 0 до 247 и получил 6.
как это мне помогло?

[ПростоНуб]

ARV, хорошо, пусть текущий цвет 5. 5+4=9. Теперь прибавляем случайное число от 0 до 248 (так правильней, но не суть). Если оно 0, то 5+4+0=9. Если 248, то 5+4+248=257=1.
То есть, прежний цвет 5 будет отличаться от нового, как минимум, на +-4. Вы же это хотели?

[ARV]

а, вон оно чо! я как-то слово "прибавляйте" отнес только к числу 4, а что еще и случайное надо прибавлять, это как-то ускользнуло.
теперь понятно.

[Ivanoff-iv]

ну, да, весьма логично, если переменная 8бит:
рнд (247) принимает значения от 0 до 247
плюс 4 - и будет от 4 до 251 (от 4 до -4 если тип сигнед чар)
если к нему добавить х то в ответе будет х' отличающееся от х не менее чем на 4 в любую сторону...
правда разом на 100% яркость не изменится, т.к. для этого алгоритма 255 сосед 0...

[ПростоНуб]

Ivanoff-iv, можно допилить алгоритм. Прибавлять к текущему цвету MIN(3,255-c)+1, а случайное числоа брать не до 256-2*4, 255-MIN(3,255-c)-MIN(4,c) - где с - текущий цвет.
То есть, для цветов от 0 до 3 допускать суммарное приращение вплоть до 255, а для цветов 252-255 начинать приращение с нуля.

ARV, благодарить у Вас не принято?

[ARV]

правда разом на 100% яркость не изменится, т.к. для этого алгоритма 255 сосед 0...

не понял, при чем тут яркость, но индекс 0...255 это условный "градус" цветового круга в модели HSV, т.е. и 0 и 255 - это оттенки яркокрасного цвета

благодарить у Вас не принято?

у нас не принято выпрашивать.

[Ivanoff-iv]

[uquote="ARV",url="/forum/viewtopic.php?p=3649495#p3649495"]индекс 0...255 это условный "градус" цветового круга[/uquote] тогда ладно...[uquote="ARV",url="/forum/viewtopic.php?p=3649495#p3649495"]

благодарить у Вас не принято?

у нас не принято выпрашивать.[/uquote]
смотри ПростоНуб, сейчас ещё и должен останешься...

[ARV]

я возвращаюсь к теме о генерации случайноо цвета.
предложенный выше алгоритм особого эффекта не дает.
генератор псевдослучайной последовательности из avr-libc слишком часто выдает числа, находящиеся рядом, например 2015 и 2000. поскольку я "масштабирую" это число к диапазону 0-255, то естественно, что результат получается один и тот же...
то есть проблема в генераторе случайных чисел есть, и она мешает жить... истинная случайность, как для криптографии не нужна, нужна "красивая" случайность, то есть чтобы после красного почти всегда был не-красный, а после голубого был не-голубой.
хуже всего еще то, что при поиске случайных файлов, наблюдается тот же эффект: значительно чаще "выпадают" файлы с номером где-то в середине списка, чем на краю...
все это огорчает.

нет ли каких идей для исправления этой ситуации? грубо говоря, нужна функция rnd(int x), которая бы возвращала число от 0 до x (не включая), и при этом вероятность того, что два раза подряд она выдаст одинаковое число была ненулевой, но более-менее малой, а распределение тем не менее стремилось к равномерному?

возможно, есть какой-то принципиально альтернативынй способ управления случайным цветом и номером файла... но я не могу никак его найти...

[Eddy_Em]

Ну ты как не электронщик прямо! Делай srand из канала АЦП, на котором антенна болтается.
А чтобы реально кошерный набор случайных цветов генерить, сначала проиндексируй их - сделай 256 базовых цветов, из них и выбирай.
По крайней мере, обязательно нужно уйти от модели RGB. Можно, например, HSV использовать…
// а, увидел, тут уже HSV используется.. Ну, а ГСЧ все-таки должен быть аппаратным. Можно копить энтропию из промежутков между внешними прерываниями, АЦП (как я уже говорил), еще чего-нибудь.. Абы источников случайных величин было как можно больше. Тогда получим примерно гауссиану. Ее при помощи математики легко в равномерное распределение преобразовать.

[ARV]

антенна на канале АЦП будет давать четкую корелляцию с сетью. поскольку в моем устройстве идет привязка к интервалам по 10 мс, сомневаюсь, что эта идея даст хоть сколько-нибудь лучший результат, чем то, что есть сейчас...

не нужна истинная случайность, я уже говорил. нужна простая, "человеческая", красивая последовательность, которую просто сложно предсказать зрителю

[Eddy_Em]

Ну так псевдослучайные числа - на то и псевдослучайные, что фигня полная…
Можно фликкер-шум использовать. Там, правда, 1/f, но все лучше, чем псевдослучайные числа.

[alexander.k]

А если считать хеш-функцию от текущего цвета и принимать результат за новый цвет? Если цвет 24 битный, то можно crc32 использовать, и обнулять младший или старший байт. На выбор.

[ARV]

допустим, для цвета это могло бы быть интерсным, а как на счет номера файла? тоже от текущего номера считать?
и какую хеш-функцию можете предложить?

[arkhnchul]

продолжать выбивать случайные числа, пока выпавшее значение не станет отличаться от текущего цвета/номера более некоторой дельты - самое то имхо.

из "большого" stdlib попытаться утащить реализацию генератора с равномерным распределением - какого-нибудь lrand48

[Ivanoff-iv]

если кажется, что рандом неправильный - исправь! крути доску как одинокий шахматист: Учет=рнд(х), Унечет=(рнд(х)+х/2)%х
или на треть оборота - также, только добавляй поочереди 0, х/3, 2х/3...
и твои рядомстоящие результаты окажутся совсем не рядом

[ARV]

продолжать выбивать случайные числа, пока выпавшее значение не станет отличаться от текущего цвета/номера более некоторой дельты - самое то имхо

нет, это плохо: слишком недетерминированная длительность генерации числа в этом случае. мои эксперименты показывают, что подряд может быть больше десятка "близких" чисел.

крути доску как одинокий шахматист

уже интересней... попробую экспериментально проверить, как это скажется на наблюдаемый результат.

[Radan]

Посмотрите здесь: http://forum.avr.ru/algoritm-poluchenii ... 9256598560&

[ARV]

[uquote="Radan",url="/forum/viewtopic.php?p=3741727#p3741727"]Посмотрите здесь: http://forum.avr.ru/algoritm-poluchenii ... 9256598560&[/uquote]Спасибо, попробую.