Обсуждаем мат. алгоритмы работы с RGB панелями

Предлагаю здесь обсуждать алгоритмы обработки цветов, преобразований координат и прочее связанное с выводом на HUB75 RGB панели

Материалы по теме
LED dimming using Binary Code Modulation


Библиотеки для работы с RGB панелями:

Библиотека	платформа	примечание
DMD_STM32	STM, RP2040	автор на форуме @bort707
ESP32-HUB75-MatrixPanel-DMA	ESP32	контрибьютор на форуме @vortigont

Проекты на форуме с поддержкой HUB75 панелей
WiFi лампа/гирлянда/информер ws2812/HUB75
пиксель-арт из вышивки

 

[bort707]

Насколько я помню 128х64 со сканом 32 это тупо две панели 64х64 соединенные последовательно в одном корпусе.

нет, не так. У одной матрицы 128х64 и двух 64х64 порядок обхода строк будет разный, поэтому тупо заменить одно на другое нельзя.
Но вообще любые ХАБ75 матрицы, у которых скан равен половине высоты - обрабатываются по одному алгоритму. Поэтому в моей библиотеке, к примеру, вы можете добавить любую подобную матрицу с любым экзотическим размером - хоть 80х40, хоть 96х48, да хоть 104х52 (бывает и такое чудо - без изменений в коде.

Автор делал для себя выложил как есть.

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



Ладно, не буду отвлекать
@vortigont, Вы писали что планируете переписывать библиотеку ЕСП32 для хаб панелей. Бкдет интересно посмотреть. Может и посоветую что, у МРфаптастика работа с координатами не слишком удобно написана, имхо, из-за чего туда трудно добавлять новые типы панелей.

 

[vortigont]

У одной матрицы 128х64 и двух 64х64 порядок обхода строк будет разный

почему разный-то? У матрицы со сканом в половину высоты размер сдвигового регистра равен ширине матрицы, по-другому сделать там не получится. Вроде как встречались особо уродские матрицы на 4-х битных дешифраторах где E пин был задействован каскадом, но то другая тема. ИМХО такие матрицы это пережиток прошлого.

писали что планируете переписывать библиотеку ЕСП32 для хаб панелей

я когда-то работал над либой от фаптастика, но потом забросил эти панели. Планирую ли переписывать - не знаю, на все нужно время. Текущая архитектура либы фаптастика мне не нравится. Это наследние прошлого - завязка на адафрут и координаты прямоугольной панели. Я обсуждал с ним что ее было бы неплохо декомпозировать на ядро, работающее с и2с и буфер, привязаный к размеру сдвигового регистра, а не к размерности панели. А трансляцию координат оставить на классы более высого уровня. Но тогда обсуждение сошлось к сохранению совместимости, т.к. у либы уже большая аудитория и это слишком сложные изменения. Потом я это дело забросил. Кстати, адафрут там тоже вообще сбоку приплеку и больше мешает. Вообще адафрут тоже страдает тяжелым наследием и его надо переписывать на шаблоны. Так что тут работы непочатый край.
Я уже оформил часть своих идей в отдельную либу LedFB, она не привязана к формату цветов, а трансляция пикселей в ней пристёгивается к буферу сбоку. Через неё я запускаю один и тот же код эффектов на адресных лентах, хаб панели и на линуксе в окошке через ArduinoOnPC. Но она еще в ранней стадии развития.

а что за ваша библиотека? Поделитесь посмотреть

рабочие эффекты поломались. По моему все контролы ,посбивались и субпиксели

мы вроде договаривались что о проблемах сообщать нужно в развернутом виде с конкретными примерами. Я на скорую руку потыкал пяток любимых эффектов, каких-либо заметных глазу косяков не увидел. Что значит "посбивались субпиксили" мне не ведомо

скачал... архив 2.5 Гб для проекта, размером в лучшем случае 10 мегабайт

спасибо что предупредили, даже качать не буду.

 

[bort707]

матрицы со сканом в половину высоты размер сдвигового регистра равен ширине матрицы

Да, Вы правы, что-то я притупил

адафрут тоже страдает тяжелым наследием и его надо переписывать на шаблоны.

Согласен. Адафруит старье, это и плохо и хорошо. Для меня его главная проблема - 16битный цвет,. А плюс его в том, что для него очень многое уже написано. В частности формат фонтов Gfx используется в десятках библиотек, для него есть конвертеры из TTF и куча готовых шрифтов.

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

У меня в либе Dmd_STM32 примерно так и сделано. В результате я относительно легко могу добавлять поддержку не только панелей разных размеров, но и многоскановые панели с завороченным соединением строк. Это мое главное преимущество по сравнению с другими подобными библиотеками, поскольку почти во всех других отношениях моя библиотека проигрывает...

 

[vortigont]

Для меня его главная проблема - 16битный цвет

ну вот да, я о том же. Причем в основном то используют его обертку, которая ничего кроме вызова попиксельного рисования в наследуемом классе не делает. Оно даже не привязанно к конкретному устройству вывода, а у них в заголовке до сих пор болтаются инклуды от SPI I2C шины.
Это проблема всех бородатых проектов, они обрастают таким количеством стороннего кода от них зависимого, что там уже никто не хочет ничего трогать дабы не вызвать гнев и бурление в массах. Я поэтому пока туплю с текстом в этом проекте, что текущая реализация адафрута никак не лезет в мою либу на шаблонах. А писать костыли мне не хочется. Надо изучить вопрос с лицензией и переписать обертку адафрута на что-то более гибкое с тем же апи сохранив работу со шрифтами и пр.
Так а что за либа то Dmd_STM32, где глянуть? Как там на стм32 с памятью под хаб панели? Большой перерасход получается? У вас параллельный вывод организован?

 

[bort707]

Так а что за либа то Dmd_STM32

На гитхабе https://github.com/board707/DMD_STM32

Как там на стм32 с памятью под хаб панели? Большой перерасход получается?

Там минимальная избыточность по памяти, на каждую 64х32 панель нужно только 3кб оперативки при одинарном буфере. Так что даже на младших stm32f1 вполне можно запустить пару панелей с двойной буферизацией., а на старших stm32f4 вообще проблем нет. Кроме СТМ либа поддерживает контроллеры RP2040, там тоже с памятью все хорошо.

У вас параллельный вывод организован?

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

 

[vortigont]

64х32 панель нужно только 3кб оперативки при одинарном буфере

это как это так? 64х32х3 (24 битный цвет) = 6144 байт только данные пикселей в чистом виде без учета какой-то организации на BCM и дрыгания остальными пинами. Кстати, а какая частота Clk получается на стм? RP2040 я не щупал. Интересно вообще, но чипы без радио уже как-то совсем скучно и специфично по нынешним временам.
В либе фаптастика память уходит как не в себя, оч большой овехед, но зато полностью весь буфер выводится без единого прерывания.
У меня были идеи и на этот счет, можно сократить расход памяти вдвое, но руки не дошли.

 

[bort707]

это как это так? 64х32х3 (24 битный цвет) = 6144 байт только данные пикселей

Я ж написал, что устаревший Адафруит моя боль В адафруите при обработке 16 битный цвет, а при выводе на панель так вообще остается 4 бита на цвет - вот и выходит 3кб. Никаких других накладных расходов на BCM у меня нет, все управление построено на аппаратных таймерах. Используется одно прерывание на вывод каждого буфера. Сами точки выводятся на матрицу ногодрыгом на stm32F1 и через DMA на stm32F4. Частота вывода порядка 6 МГц в первом случае и около 11 МГц во втором. На рп2040 все делается через встроенную pio- машину, там частота вывода теоретически может быть до 55 МГц - но столько уже не тянут сами панели, так что у меня стоит 16мгц

В либе фаптастика память уходит как не в себя, оч большой овехед,

Да, я тоже как-то обсуждал с ним расход памяти. Но там надо в корне переделать библиотеку, чтобы это изменить.
Кстати, хоть у него и постулируется 24битный цвет, но если собрать дисплей из десятка панелей - из-за расхода памяти и ограничений алгоритма глубина цвета будет автоматически понижена чуть ли не до моих 4бит, в то время как мой код тянет 16 панелей 64х32 без проблем.

Даже при неограниченной памяти частота обновления будет падать с ростом динны каскада

Понятно что частота будет падать, это очевидно. Однако падение частоты можно замедлить.

Бороться с этим можно 2мя способами - загрублять алгорим BCM теряя в динамическом диапазоне (то что реализованно в либе фаптастика) или снижать разрядность цветов, тем самым снижая нагрузку на BCM.

а можно об этом подробнее? Разве это не одно и то же?

В моем случае я использую возможность отдельно управлять яркостью каждого битового слоя BCM. Таким образом, в моем случае частота с ростом битности цвета падает не так быстро. Например при переходе от 4хбитного цвета к 8битному длительность экспозиции растет не в 16 раз, а только в 3.

Вообще для информера где в основном текст выводится даже 256 цветов вполне хватит.

256 это уже много Для вывесок у меня есть режим 1битного цвета - получается 8 цветов, включая черный Зато можно соединять десятки панелей, например для расписания на вокзале самое то.

 

[vortigont]

а можно об этом подробнее? Разве это не одно и то же?

Например при переходе от 4хбитного цвета к 8битному длительность экспозиции растет не в 16 раз, а только в 3.

не одно и тоже. Результат то один, снижается общее время экспозиции строки, но характер вносимых искажений разный.
У фаптастика работает так: допустим требуется 8 бит на пиксель, т.е. условно на строку должно быть 256 "проходов" для реализации полного динамического диапазона на цвет. Считается время за которое будет проэкспонирована вся панель, получается, допустим 30 герц, что ниже условно приемлемой частоты в 100 герц. Алгорим пересчитывается и находится максмальная битность при которой частота будет не мнее 100 условных герц. Допустим получается 6 бит, т.е. число проходов на одну строку составит 64, младшие биты цветности получают линейную экспозицию, а не экспоненциальную. Т.е. динамический дипазон скукоживается нелинейно, в тенях он резко падает и вносятся шумы, аналогичные шумам квантования потеряной разрядности. При этом размер памяти требуемый под буфер получается такой же как если бы алгорим БЦМ работал на полной 8 битной глубине.
Если снижать разрядность БЦМ но не ломать экспоненту, то число возможных оттенков уменьшается соответственно снижению разрядности цвета, но шума от перехода экспонента-линейность нет. Но для этого нужно реализовать более точный алгорим понижения цветности. Насколько я помню в либе фаптастика этого нет, хотя я давно в нее заглядывал, возможно там уже что-то поменялось.

Как у вас сделанно алгоритм я не глядел еще, но смысл тот же если при увеличении разрядности цвета экспозиция у вас не растет по экспоненте, то вы зашумливаете алгоритм БЦМ при этом тратя память на лишние биты цветности (это если у вас в либе какой-то свой буфер под панель, а не просто кадровый буфер под адафрут).

P.S. вообще у меня были мысли реализовать шумовое маскирование с гамма коррекцией, когда ошибки кванования переносятся в область старших битов с учётом того что человеческий глаз менее восприимчив к нему в этой области. Интересная задача на обработку, но текущий дизайн либы фаптаскика не очень удобен для этого, пока только на уровне идеи.

 

[bort707]

младшие биты цветности получают линейную экспозицию, а не экспоненциальную

Правильно ли я понял, что вместо экспозиции 1-2-4-8 периодов биты показываются по схеме 1-2-3-4? Или вообще 1-1-1-1?
Но в чем смысл искажать биты, разве не проще их вовсе отбросить?

Как у вас сделанно алгоритм я не глядел еще

У меня никак не сделано, я же еще не добавлял 24битный цвет. Пока только примериваюсь, как сделать.

 

[vortigont]

вместо экспозиции 1-2-4-8 периодов биты показываются по схеме 1-2-3-4? Или вообще 1-1-1-1?

да, именно так. Не помню как конкретно у фаптастика, но смыл именно такой.

в чем смысл искажать биты, разве не проще их вовсе отбросить?

конечно проще! Но выглядить это будет еще более по-уродски. К примеру у вас есть 256 градаций серого, вы отбрасываете, ну пусть последние 8. И у вас есть некий текст, одна строка которого выводится на условном тоне 7, другая на условном тоне 3, третья на условном тоне 1. Вы ожидаете что все 3 строки должны быть видимыми. Но отбросив биты, вы получите что все 3 строки будут нарисованы черным "невидимым" цветом.

Дописал выше комментарий про маскирование.

 

[bort707]

@vortigont, спасибо за разъяснение. У меня была идейка, как эмулировать экспоненциальную экспозицию не слишком увеличивая длительность цикла .
Вкратце смысл в том, чтобы для старших бит варьировать длительность, а для младших - время засветки управлением пином OE.

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

А можно подробнее? Я, к сожалению, не математик

 

[vortigont]

@bort707, вы ба в кратце описали как работает ваша либа что бы мне в коде не копаться долго, так будет проще думать в вашу сторону. Что вы имели ввиду под контролем БЦМ на каждый пиксель я не понял. Кадровый буфер у вас хранится как есть в 16 битном цвете 565 под адафрут? Как формируется последовательность бцм на ногах контроллера? Вычисляется по таймеру или где-то формируется отдельный короткий ДМА буфер? Если есть возможность что-то вычислять на лету, то вариантов что-то покрутить намного больше.
На эту тему много информации в сети, я не то что бы плотно этим занимался, но в целом есть несколько подходов для маскирования шумов квантования и алгоритмов оверсемплинга - спектральный (читай яркость), пространственный и временной. Спектральные алгоримы довольно сложны. Но есть варианты. На БЦМ смысл в следующем - самая чувсвительная область для глаза это градиенты в тенях, т.е. как раз когда в пикселе значимые только младшие биты. Для светодиодов глаз нелинейно воспринимает яркость модулируемую ШИМом. Т.е. грубо говоря для 256 градаций серого разницу между двумя пикселеми светящими на 1 и 5 видно намного сильнее чем между 250 и 255. На этом можно сыграть перераспределив веса бит в зависимости от суммарной величины всех значимых бит, т.е. в тусклых пикселях мы храним как можно больше данных, а в ярких свободно выбрасываем младшие разряды. Напр эта модель описывается в пространстве CIE_1931. Можно вычислить таблицу преобразования 8 битной яркости в, напр., 6 битную (64 градации) и сократить время засветки вчетверо. Тут если пример реализации формулы.
Получим

    0,    0,    1,    1,    2,    2,    3,    3,    4,    5,    5,    6,    7,    8,    9,   10,
   12,   13,   14,   16,   18,   20,   22,   24,   26,   28,   31,   33,   36,   39,   42,   45,
   49,   52,   56,   60,   64,   68,   73,   77,   82,   87,   92,   98,  103,  109,  115,  122,
  128,  135,  142,  149,  156,  164,  172,  180,  189,  197,  206,  215,  225,  235,  245,  255,

Первый один бит мы теряем в ноль, чудес не бывает. Но для остальных получаем что тусклые пиксели нарастают довольно быстро, а яркие ужимаются в смежные цвета намного шире, градиенты в тенях будут выглядить намного приятнее, а что там творится в яркой части глаз все равно не разберёт.
Но, мы же жадные? Один младший бит таки терять не хочется и надо бы его тоже как-то вытянуть. Можно! Мы ведь только что нарастили частоту обновления всей панели, а у хаб75 она должна быть довольно большая (ну пусть условные 100Гц). Это очень хорошо подходит для временного размытия! Есть у нас один пиксель со значением в 1 младшем бите, который мы отбросили по таблице выше. А значит что бы его вернуть нам нужно получить от панели пол кванта яркости от 64х - разносим эти пол кванта во времени. Нечётные кадры обновления всей панели считаем эти пиксели равными нулю (потухшими), чётные - равным единице. Да, он будет шуметь на частоте половины частоты обновления матрицы, ну да и ладно. Если таких пикселей будет немного, то на высокой частоте это будет незаметно. Таким же макаром можно размазывать биты в пространстве, но то уже сильно сложнее для реализации в маленьком контроллере.

 

[bort707]

Можно вычислить таблицу преобразования 8 битной яркости в, напр., 6 битную (64 градации) и сократить время засветки вчетверо.

Спасибо за объяснения.
Если я вас верно понял, приведенная таблица описывает обратное преобразование - из 6-битного цвета в 8битный(если считать что входной индекс это номер элемента, а выходной - значение а клетке). В целом принцип понятен

вы ба в кратце описали как работает ваша либа что бы мне в коде не копаться ....
буфер у вас хранится как есть в 16 битном цвете 565 под адафрут?

Нет, буфер сразу формируется в виде, подготовленном для вывода на матрицу. Каждый байт буфера содержит состояние пинов R0-G0-B0-R1-G1-B1 одного пикселя из верхней и нижней половин панели. Для младших серий СТМ состояние управляющих пинов в буфере не хранится вовсе, для старших добавляется пин CLK. Пиксели следуют в порядке их вывода , все геометрические преобразования в случае сложных матриц выполняются до записи в буфер. Каждый битовый слой (bit-plane) хранится отдельно, начиная от младших битов к старшим.
Работает это все по классическому BCM - то есть по прерыванию таймера данные очередного битового слоя загружаются в матрицу, после чего на таймере запускается новый интервал, пропорциональный весу бита. Процесс повторяется по числу сканов.
Яркость управляется PWM на отдельном таймере, синхронизированным с основным.

 

[vortigont]

приведенная таблица описывает обратное преобразование - из 6-битного цвета в 8битный

ну вам же наоборот нужно понизить разрядность, из 8 получить 6, или из получить 4, аналогично.
Таблица это для общего понимания принципа, я просто скрипт дернул под пример для 6 битного ШИМа.
Читать ее следует так - все отсутствующие значения в диапазоне 0-255 схопываются к ближайшему меньшему/большему. Тогда видно что в зоне начальных значений величины присутствуют все подряд, и далее с ростом растёт число пропусков, ближе к старшим значениям отбрасываются уже по 8-10 идущих подряд величин. Для градаций серого это значит что с понижением разрядности расширяется динамический диапазон в тенях и сужается в ярких участках. С другой стороны это "вытаскивает" тени и снижает общую контрастность, тут интересен баланс. Таблица неточная, т.к. в ней есть повторяющиеся значения несколько штук. В итоге это должен быть вектор с 256 элементами и значениями 0-63. Для цветов в формате 565 нужны свои поправки, т.к. там и разрядность на цвет разная. Это надо всё обсчитывать на более точных формулах с плавающей запятой и исследовать как оно выглядит, готового решения у меня нет. Я хотел этим позаниматься на досуге, но пока руки не дошли. Оставляю заметки на будущее.

 

[bort707]

В итоге это должен быть вектор с 256 элементами и значениями 0-63.

Именно. Но у Вас это таблица с 64 элементами и значениями 0-255
Поэтому я и написал, что читать ее следует наоборот. Похоже я все понял верно.
Если Вам нужны какие-то пояснения по моей либе - буду рад ответить

 

[vortigont]

@bort707, ну можно сказать и так Она, просто немного под другое написана была ) я не стал сильно ковыряться )
А общая яркость панели в вашей либе как управляется?

 

[bort707]

общая яркость панели в вашей либе как управляется?

PWM на пин OE через отдельный таймер. Яркость может быть разной для каждого bitplane. Это позволяет управлять вкладом бита в общую картинку, меняя яркость а не время экспозиции и этим сокращать общий цикл вывода на матрицу.

 

[vortigont]

и этим сокращать общий цикл вывода на матрицу

так время вывода строки не зависит от яркости, разве нет? Какое бы значение не было у пикселя, вам нужно каждую строку "прокачать" столько раз, сколько суммарно насчитает БЦМ по весам.
У фаптастика яркость регулируется отдельным битов общего ДМА буфера - это адский расход памяти и зависимость разрядности яркости от длинны строки. Но с другой стороны из-за особенностей I2S эта память все равно теряется впустую.

 

[bort707]

Какое бы значение не было у пикселя, вам нужно каждую строку "прокачать" столько раз, сколько суммарно насчитает БЦМ по весам

Но добиться этого можно по разному.

• Можно вывести каждый битовый слой столько раз, сколько насчитает БЦМ, Так, если не ошибаюсь, работает алгоритм фантастика.
• Можно выводить каждый битовый слой только один раз, но варьировать длительность засветки - это классический БЦМ.
• А можно задавать вес БЦМ бита, оставляя длительность для всех слоев одинаковой, но подсвечивая младшие биты с пониженной яркостью..

Два первых метода требуют длительность последовательности N**2-1, где N - разрядность цвета в битах. Например, для 8битного цвета длительность всего цикла будет 255 единиц. В последнем методе в предельном случае длительность цикла всего N. То есть всего 8 единиц для 8 бит, в 32 раза быстрее классического БЦМ. Но за это приходится платить сильным снижением общей яркости картинки, поэтому наиболее правильно комбинировать методы 2 и 3. Старшие биты засвечиваем с полной яркостью и изменяем время экспозиции, младшие - с единичной длительностью и ШИМ. К примеру, если при 8битном цвете вывести 4 бита через ШИМ и 4 через классический БЦМ, можно сократить цикл с 255 интервалов до 19, потеряв в яркости всего около 15%

 

[vortigont]

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

Варианты 1 и 2 это одно и тоже, просто в 2) предполагается что можно остановить клок и перестатать качать данные и просто светить какое-то время то что попало в защелку. Иначе данные поступают в регистр непрерывно и время засветки равно времени заполнения регистра (без учета регулировки яркости).

А в 3м случае снижать время экспозии младших битов через завижку OE - время заполнения регистра-то от этого не меняется? Плюс как при этом рулить яркостью панели? Еще больше увеличивать частоту ШИМ и еще больше сокращать время засветки? Для длинной цепочки панелей, наверное, это приемлимый вариант.

Вообще я не знаю как делают развертку панелей профессиональные контроллеры на FPGA (конкретных данных и алгоритмов специально не искал), но оба этих подхода (имею ввиду 1+2 и 3) не есть хороши с точки зрения мерцания панели. У фаптастика, да, у него одна строка пикселей экспонируется по очереди битами всех весов по порядку в соотвествие с БЦМ алгоритмом (если не считать перехода где экспонента убирается). У вас по схеме 3 тоже самое. Т.е. если замедлить клок, то по панели сверху вниз бежит одна яркая полоса и время её засветки (считаем что яркость 100%) больше времени заполнения регистра и кратно битности БЦМ. Тогда как оно должно работать немного по-другому - регистр всегда заполняется данными следующей строки пока предыдущая экспонируется за время равное времени этого заполнения. Т.е. картинка нарезается по строкам слоями столько раз сколько суммарно положенно по битности БЦМ, а частота строчной развертки равна скорости заполнения регистра и не зависит от битности БЦМ. БЦМ влияет на частоту кадровой развертки - один слой всей картинки целиком для младшего бита, два раза слой целиком для 2го бита т.д. Увеличение частоты строчной развертки будет сильно лучше смотреться в плане нагрузки на глаза.
У меня была мысля переписать алгоритм фаптастика, но там будет сильно сложнее формировать ДМА буфер и порядок формирования связанных списков, а с учетом того что у него всё привязано к геометрии панели это вообще муторно. Опять же закинул эту идею в долгий ящик.

 

[bort707]

Варианты 1 и 2 это одно и тоже, просто в 2) предполагается что можно остановить клок и перестатать качать данные и просто светить какое-то время то что попало в защелку

Ну да. Честно говоря, когда я впервые разобрался, как работает либа фаптастика , я был очень удивлен. Вариант 1 представляется мне излишне избыточным. Возьмем, к примеру, 8битный цвет. Самвй старший бит в последовательности имеет вес 128, верно? Метод фаптастика означает, что мы 128 раз подряд посылаем в матрицу одни и те же данные. Зачем?
С моей точки зрения, это похоже на то, как будто человек пошел в туалет и каждые 10 сек заново нажимает выключатель, хотя свет и так горит. В варианте 2 мы не грузим панель одним и тем же 128 раз, а посылаем данные, выключаем клок и потом ждем 128 циклов. Контроллер в это время может заниматься чем-то совсем другим.

Что касается метода 3, мне кажется мы друг друга просто не поняли Рассуждения про то, что метод 3 будет работать только на медленных сценах мне кажутся необоснованными. Уменьшение времени вывода на матрицу в любом случае благо - а эта метода позволят поднять частоту кадров более чем 10 раз по сравнению с вариантами 1 и 2.
Но в прочем не будем спорить. Каждый идет своим путем

 

[vortigont]

Вы, похоже, пропустили большую часть моего сообщения про строчную развёртку )
В либе фаптастика клок никогда не останавливается, он там дармовой через ДМА. То что там выводится одна и таже строка несколько раз это специфика реализации. Как ни крути, но базовый квант временени в этих панелях один - время за которое заполняется сдвиговый регистр целиком, назовём его T. И если абстрагироваться от регулировки яркости панели методом ШИМа, то бишь гашения панели на какое-то время (а дабы не быть голословным и не болтать о коне в ваккуме возмем панель у которой яркость регулируется аппаратно токовыми драйверами, таких сейчас много), то 3й метод выглядит абсурдно. Вы просто гасите панель и называете это увеличением вывода частоты кадров. Кадр один - но строчная развёртка должна пробежать по матрице 2^n раз по алгоритму БЦМ. Это определяет динамический диапазон - дискретную разницу между самой яркой и самой тусклой точкой. Поэтому я и говорю что если картинка у вас статичная (кадр, залитый 100% белым), то математически вы должны всегда экспонировать белую строку - это может быть как схема когда каждое время T зажигается последующая строка или когда одна строка горит несколько периодов Т, это влияет лишь на метод строковой развёртки, но не меняет динамический диапазон.
А по алгоритму 3 у вас за один период Т может экспонироваться строка целиком, а может течение периода Т быть частично или совсем погашена. На половину периода, на четверть и т.д. У вас тот же метод что и в либе фаптастика только с точностью до наоборот - у него одна и таже строка экспонируется несколько периодов подряд кратно весу, а у вас таже самая строка гаснет на время кратное доле веса. Почему это плохо для медленных сцен - здесь я неверно выразился, не медленных в плане движения по кадру объектов, а в плане наличия контрастных ярких объектов. И это плохо по той же причине по которой вреден ШИМованый свет низкой частоты - пока источник света погашен, окружающие предметы или глаз движется и появляется эффект стробоскопа. По методу 1+2 по матрице двигается непрерывно светящаяся полоса, да, сама полоса движется, но свет от нее постоянный. А по методу 3 эта полоса вдобавок к своему движению по вертикали еще постоянно стробит БЦМом.
Я не спорю за то что есть правильный путь или неправильный. Для каждого случая можно найти свою область применения. Тут интересен сам поис компромисов.

 

[bort707]

Как ни крути, но базовый квант временени в этих панелях один - время за которое заполняется сдвиговый регистр целиком, назовём его T.

Именно так! Я бы даже сказал что в этом и соль! Мы не можем сократить время заполнения регистра, потому что это определяется пропускной способностью матрицы. Но мы можем сократить число таких запонений в цикле.
Для показа полного кадра в методе 1 требуется время 255*Т, а в методе 3 - только 8*Т. Конечно, вы правы что управление яркостью увеличивает мерцание картинки на низких частотах. Однако поскольку метод 3 потенциально в 32 раза быстрее , то бороться с мерцанием можно увеличивая частоту кадра.

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

 

[bort707]

Вы, похоже, пропустили большую часть моего сообщения про строчную развёртку )

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