Вы меня сильно рассмешили. Этот тип файла и есть сжатый файл. И сжимать его дальше нет смысла.
Пределы адресной ленты на ардуино
- Автор темы avan
- Дата начала
Цель - отобразить текущую картинку на экране размером "128...200 строк по 330 точек" с 24-битным цветом и обновлять картинку 100 (ну, ладно, 60...) раз в секунду
любой файл - это данные.
а тут утверждали выше, что архиватор сжимает какие угодно данные без потери качества. Это неверно.
Данные с большой избыточностью - да. а в общем случае - не всегда.
еще бы. ведь сам файл jpg - это сжатая картинка
Если же брать необработанные изображения - как правило они сжимаются очень хорошо. Вы ошибаетесь, когда пишете, что много одинаковых точек подряд - это редкость. На самом деле для любых изображений характерно то, что соседние пиксели как правило имеют одинаковый или очень близкий цвет
Зачем??
То что вы написали - это не цель. Цель - это например показать на таком экране рекламный ролик
@avan, Прогресс идет , растут мощности и то, что раньше телевизоры позволить себе не могли, теперь делают очень просто. И да, качество тв сигнала по инету сильно хуже чем с диска, но тут уже вы выбирайте, шашечки или ехать. Если я хочу что то посмотреть в приличном (более-менее) качестве и без заикания, то я скачаю это и буду смотреть.
То есть Вы хотите сказать, если я сожму хотя бы в RAR или ZIP архив исполняемый файл, он потеряет часть информации?
А как же он работает тогда после распаковки?
Изучите хотя бы матчасть, прежде чем писать такое.
Правы Вы только в одном. При упаковке изображения и звука часть информации теряется в угоду компактности, но это не критично.
неверно не то, что без потери качества, а неверно, что любой файл уменьшит свой объем после сжатия.
в мои студенческие годы популярно было "скорочтение страницы по диагонали".
Типа книгу в три пальца толщиной можно прочитать за 2 часа...
Мы подсовывали таким "читунам" томик Аристотеля... Было весело....
А какую-нибудь современную тётку (что продаются даже в гастрономах) - вполне, наверное, и можно
Типа книгу в три пальца толщиной можно прочитать за 2 часа...
Мы подсовывали таким "читунам" томик Аристотеля... Было весело....
А какую-нибудь современную тётку (что продаются даже в гастрономах) - вполне, наверное, и можно
@avan, попытаюсь пооппонировать. Извините, если буду говорить о том, что Вы и так знаете, но, к сожалению, вижу, что либо намеренно, либо нет - но пропускаете.
Вторая часть "марализонского балета" состоит в том, что белый цвет в RGB состоит не из одинаковой яркости его составляющих, больше того, есть даже понятие "цветовая температура", в которой белый цвет оценивается в градусах Кельвина. Т.е., есть белый цвет 2700К, есть 6500К - и это довольно сильно отличающиеся белые. Вы об этом, наверное, знаете - LED-лампы сейчас весьма распространены (тёплый белый, холодный белый...). Для того, чтобы обеспечить яркость всех цветов в палитре приходится использовать не весь диапазон, например, зелёного, поскольку он воспринимается ярче синего. Т.е., 255, 255, 255 - это лишь код белого, конкретные величины, передаваемые на светодиоды будут отличаться и, для сохранения яркости при изменении цвета, быть всегда меньше 255. Это ещё больше ограничивает диапазон изменений яркости светодиодов.
P.S.
По поводу цели: мерцание и частота кадров - это несколько разные вещи. Вы уже упоминали телевизоры, которые перешли на 100, и даже на 400Гц развёртку, но... откуда же они брали сигнал? Правильно, с DVD (до 60Гц максимум) или с эфира (до 30Гц interleave). Для устранения мерцания и размытия при движении устройства отображения (LED-матрицы), а не для отображения сменяющейся картинки с такой частотой.
Вот и здесь нужно понимать, если Вы пытаетесь высокоскоростную картинку отобразить на лентах, то нужна жёсткая предобработки и их скорости будет всё равно недостаточно для адекватного отображения без смазывания, чем бы Вы их не управляли. Если речь идёт об относительно плавных изменениях, то обновлять со скоростью 100 Гц, или даже 60Гц - это чрезмерно.
Между входным потоком и выводом на экран стоит мощный многогигагерцовый и многозвенный "аппарат". Ethernet (или Wi-Fi) обслуживает микрокомпьютер, который принимает поток и очищает его от служебной информации, потом стоит некий аналог видеокарты (с бесчисленными параллельными обработками практически на аппаратном уровне и на умопомрачительных частотах) - расшифровывает поток и превращает его - та-дам! - в HDMI, а там... для 4К - полоса от 10Гбит/сек (и может увеличиваться до 48Гбит/сек для поддержки большей битности или частоты кадров)! Т.е., по сжатому входному потоку нельзя судить о скорости передачи на устройство отображения, которым являются в Вашем случае - адресные ленты.
Почитайте, например, здесь. Любое устройство отображения имеет нелинейную зависимость яркости от уровня подаваемого сигнала. Наше восприятие имеет тоже такую зависимость. Светодиоды, в частности, имеют слабые изменения в яркости при подаче сигналов, соответствующих самым ярким оттенкам, и сильные - при тёмных. Таким образом, при 256 уровнях на цвет, разница в уровне 255 и 256 (если нумерацию уровней делать от 1, а не от 0, как в байтовом представлении) будет абсолютно неразличима, а 1->2 - чрезмерно велика. Чтобы это устранить применяются таблицы пересчёта (как правило) - можете посмотреть проекты Алекса, там они, в большинстве случаев применяются. Описание есть также в FastLED.
Вторая часть "марализонского балета" состоит в том, что белый цвет в RGB состоит не из одинаковой яркости его составляющих, больше того, есть даже понятие "цветовая температура", в которой белый цвет оценивается в градусах Кельвина. Т.е., есть белый цвет 2700К, есть 6500К - и это довольно сильно отличающиеся белые. Вы об этом, наверное, знаете - LED-лампы сейчас весьма распространены (тёплый белый, холодный белый...). Для того, чтобы обеспечить яркость всех цветов в палитре приходится использовать не весь диапазон, например, зелёного, поскольку он воспринимается ярче синего. Т.е., 255, 255, 255 - это лишь код белого, конкретные величины, передаваемые на светодиоды будут отличаться и, для сохранения яркости при изменении цвета, быть всегда меньше 255. Это ещё больше ограничивает диапазон изменений яркости светодиодов.
P.S.
По поводу цели: мерцание и частота кадров - это несколько разные вещи. Вы уже упоминали телевизоры, которые перешли на 100, и даже на 400Гц развёртку, но... откуда же они брали сигнал? Правильно, с DVD (до 60Гц максимум) или с эфира (до 30Гц interleave). Для устранения мерцания и размытия при движении устройства отображения (LED-матрицы), а не для отображения сменяющейся картинки с такой частотой.
Вот и здесь нужно понимать, если Вы пытаетесь высокоскоростную картинку отобразить на лентах, то нужна жёсткая предобработки и их скорости будет всё равно недостаточно для адекватного отображения без смазывания, чем бы Вы их не управляли. Если речь идёт об относительно плавных изменениях, то обновлять со скоростью 100 Гц, или даже 60Гц - это чрезмерно.
Изменено:
вот-вот, сделайте это сами.
Чего вы вообще ухватились за формат JPG - какое он имеет отношение к вопросу?
Вам зачем-то понадобились пределы возможностей адресной ленты - вы их получили. Чего вы дальше со всеми спорите - непонятно.
Если уверены, что можете добиться от ленты большего - так дерзайте.
А сейчас, как я уже сказал выше, без конкретной цели это не обсуждение, а пустой флейм.
Спасибо за подробное описание, это всё понятно и полезно.
Однако в данном случае мы не делаем телевизор 4К из адресной ленты,
и, о чем я уже писал выше, не будем делать никакую обработку после считывания с флэшки.
Во-первых, на это просто не хватит времени даже на 8266 процессоре, 80 мГц,
а специальные видеоплаты с параллельной обработкой тоже не предполагаются.
Это всё задачи для других применений.
Здесь вопрос о теоретическом (и практическом) пределе для адресных лент с одной или десятком плат ардуинских.,
с задачей - принять (считать с флэшки) и отобразить.
Если огромная и непонятная статья о гамма-коррекции в википедии - это о том, о чём в Вашем абзаце после этой ссылки - то это понятно, это мы делали, начиная с конца 80-х гг. в своей аппаратуре, только не называли это так мудрёно. Собственно, если заменить ту статью в википедии Вашим абзацем - будет намного полезнее для понимания её читающих.
Но эти все пред-преобразования, я считаю, нужно делать(и мы так делаем) - на исходном этапе создания файла композиции - в компьютере, до записи файла на флэшку.
Чтобы с флэшки просто читать и загонять в ленту, без "раздумий" и преобразований и с максимально возможной скоростью.
О скорости обновления кадра.
движение цветных фигур на экране может быть и плавным, и быстрым - стробоскопическим.
О простых сдвигах всей картины речи нет - любой пиксель картинки может меняться и двигаться в любую сторону и быстро, и медленно, исчезать и стробоскопически моргать на фоне плавного изменения всей остальной картины.
К тому же, при смене кадра меняется не только цвет, но и яркость.
Я хорошо помню, что когда медленно меняется яркость на нижних уровнях при 64-х её градациях - ступеньки видны глазу.
поэтому только 8 бит (256 уровней) по каждому цвету. и минимум 60 Гц.
цель имеется - вполне конкретная, я её изложил в ветке, и не раз.
Если для Вас она не является целью, а таковой Вы считаете только прокручивание рекламных роликов - это Ваше восприятие мира.
Господа - товарищи, мы уже сползли ХЗ куда. WS не предназначены для вывода тех изображений, о которых писал @Эдуард Анисимов, , и точка. Это так, развлекательное панно. А по сему не нужно требовать от этого типа светодиодов больше, чем они могут. Я вообще не понимаю, в чём вопрос. Если нужно больше золота, т.е. больше светодиодов управляемых, так что мешает юзать Due. С соизмеримой скоростью. А для видео просто нужно пользовать другие светодиоды. Чего Вы так @avan, уцепились за такой тип...
Изменено:
@avan, Вы не научилсиь аргументировать. Архивация это частный случай сжатия данных. И да, при архивации не происходит потери данных, иначе теряется весь смысл такой архивации.
И Вы никак не можете понять (а скорее всего нарочно не хотите), что JPG никак не есть исходным файлом данных. JPG уже сжат. Все. А Ваше нежелание слушать превращает всю тему в спор глухого со слепым.
И Вы никак не можете понять (а скорее всего нарочно не хотите), что JPG никак не есть исходным файлом данных. JPG уже сжат. Все. А Ваше нежелание слушать превращает всю тему в спор глухого со слепым.
никто и не называл его исходным файлом данных.
Речь была о файлах вообще.
с этим также никто не спорит.
Но это и не снимает с JPG права называться файлом.
Поэтому некоторые утверждения типа "все файлы" неверны, т.к. из него есть такое исключение,
и далеко не единственное.
А чьё-то нежелание внимательно читать тему, прежде чем высказываться, и порождает такие эксцессы.
С переложением вины за них на других
Изменено:
Попытаюсь выступить арбитром.
Из во-первых вытекает то, что все архиваторы без сжатия пытаются привести кодирование информации к виду, когда собственно объём информации сохраняется. При этом никто не гарантирует, что после сжатия размер сократится (например по причине того, что избыточность уже была удалена ранее). Кстати, наличие предварительных данных о составе информации может "упаковать" её в более компактный вид. Этим пользуются, в частности, аудио "хранители", применяя flac, ape и иже с ними. Отсюда:
Из во-вторых вытекает так называемое перцептуальное сжатие. Например, большинство людей плохо слышит и распознаёт частоты до примерно 40Гц и выше 8-9кГц. То есть, если дать "какую-то" информацию в районе 40Гц и добавить некий шум примерно соответствующий спектру выше 8кГц, то о качестве могут судить только совсем упёртые аудиофилы (это я - про MP3). Та же "штука" в JPG, MPEG, всяких H. ... Фактически, за исключением плёнки (и там есть зерно и динамический диапазон), Вы никогда не получаете "чистое" изображение, не сжатое по каким-то перцептуальным принципам. Так что хранить изображение в разжатом виде - себе дороже, а обрабатывать - тем более.
Неверно по двум причинам. Во-первых, потому, что понятия "информации" и "размера" - разные вещи. Во-вторых, качество - понятие субъективное.
Из во-первых вытекает то, что все архиваторы без сжатия пытаются привести кодирование информации к виду, когда собственно объём информации сохраняется. При этом никто не гарантирует, что после сжатия размер сократится (например по причине того, что избыточность уже была удалена ранее). Кстати, наличие предварительных данных о составе информации может "упаковать" её в более компактный вид. Этим пользуются, в частности, аудио "хранители", применяя flac, ape и иже с ними. Отсюда:
Не означает, что изменяется размер (сжимается). Думаю, именно это было неправильно понято.
Из во-вторых вытекает так называемое перцептуальное сжатие. Например, большинство людей плохо слышит и распознаёт частоты до примерно 40Гц и выше 8-9кГц. То есть, если дать "какую-то" информацию в районе 40Гц и добавить некий шум примерно соответствующий спектру выше 8кГц, то о качестве могут судить только совсем упёртые аудиофилы (это я - про MP3). Та же "штука" в JPG, MPEG, всяких H. ... Фактически, за исключением плёнки (и там есть зерно и динамический диапазон), Вы никогда не получаете "чистое" изображение, не сжатое по каким-то перцептуальным принципам. Так что хранить изображение в разжатом виде - себе дороже, а обрабатывать - тем более.
О чем о другом? Вы переговорили про кучу всего. А вопрос то толком так и не раскрыли для себя. Так вот, я занимаюсь эффектами для прошивки лампы с такими диодами, в основном адаптирую найденные в инете, но иногда пишу и сам. И могу ответственно заявить, что если просто в двух циклах for выводит на матрицу из такой ленты просто один цвет. То уже на 32х32 (1024 диода) 100ФПС вы не получите никогда (esp8266). По ряду причин. Если же эффекты требуют хотя бы мало мальских рассчетов + обслуживание связи - 40-50 гора. а эффекты более менее, да на субпикселе - 18-30 ФПС.
Вот и вся ваша арифметика. ESP32, думаю, сможет обслужить нормально где-то 64х128, с ФПС 50-60 в пике, но на тяжелых эффетах будут те же 25-30 ФСП.
@kostyamat, почему все забывают про скорость интерфейса самой ленты WSxxxx? Она вполне жёстко задана и довольно низкая по сравнению с SPI лентами, дело вообще не в микроконтроллере
То понятно, но вы же говорили еще, что можно несколько лент к одной плате включать
@AlexGyver, потому что недостаток скорости ленты можно компенсировать увеличением количества отрезков при сохранении количества излучающих элементов, а вот чтобы клонировать нормально эффект на несколько МК для исключения нехватки памяти и скорости переключения - задача нетривиальная.
@poty, да, поэтому лучше взять spi ленту. А клонировать эффект - тоже не очень сложно, если учесть что между МК можно общаться по 8 МГц SPI и просто передавать чисто данные для вывода, а они уж там выводят со скоростью ленты. А главный МК можно помощнее взять, он одновременно на несколько МК сможет выплёвывать данные
Ну Вы ж понимаете, что если данные будут передаваться в сторону МК на 8МГц при максимальной скорости самого МК 20МГц (и это не всегда удаётся), то обрабатывать это он будет уже не в состоянии. Под обработкой я понимаю промежуточную буферизацию и сопряжение с выходным интерфейсом на ленту.
В качестве базового нужно брать что-то мультитредовое, иначе это всё равно будет что-то неподходящее.
В качестве базового нужно брать что-то мультитредовое, иначе это всё равно будет что-то неподходящее.