Спасибо) В целом, я думаю, Вы правы — конструкция нужна будет сильно другая, а спрос на такое пока невелик. Но возможно в будущем он появится, по крайней мере, со стороны геймеров.
Тут нет единого угла, под которым было бы удобно пользоваться всегда. Руками двигать неудобно. Использую почти для всего: программирование, графика/видео/3д, нейросети, игры (в основном шутеры) и др.
Было бы интересно скомбинировать вашу штуку с моей — сделать раскладывающееся кресло и изменение угла всей композиции в целом. То есть чтобы экраны висели не на стене, как у меня, а на едином шасси как у E-station, которое вместе с креслом могло бы менять угол относительно земли.
Управляются пультом и с компа, можно независимо, можно вручную и автоматом
3Д
Но есть сильное подозрение, что простым увеличением габаритов тут не отделаешься, так как массы тут несколько отличаются от обычных экранов.
Раньше под этим подразумевалось что‑то типа WinAPI/C++/MFC. Что сейчас подразумевается непонятно, но есть шанс что нужно будет две RTX 5090 чтобы панель задач меньше тормозила.
А есть ли заметная разница между 6 и 4 битами? Coder Next 80b пробовал только в 4 и 6 битах, 8 не пробовал. И 6 бит по уровню показались такими же, как 4 бита, даже на сложных задачах, а вот производительность там падала на дно. Видимо, рантайм был староват ещё.
Спасибо, это лучшее объяснение работы JPEG, которое я читал.
В одно время приделал у себя в софте режим просмотра YCbCr 2×2 специально чтобы ловить, что камера стала передавать пережатый видеопоток — на цветоразностных каналах артефакты вылезают даже на высоком качестве. Ну и субдискретизация сразу видна по прямоугольным пикселям. У JPEG всё это ещё слабо выраженно, видеокодеки в этом плане заметно агрессивнее.
Оригинальная картинка, яркостная компонента, синяя и красная цветоразностные. Внизу пиксели прямоугольные - камера при переключении на 1080p включила сжатие и появилась субдискретизация
Теоретически кодеки могут дойти до уровня «текст промпта генерации + номер сида + хеш весов модели», там то точно биометрии некуда будет уместиться (и то не факт:|). Но практически до этого ещё далеко, хотя, вроде бы, в H266 уже потихонечку внедряют ИИ для сжатия.
Я гонял у себя qwen 3.5 27b claude opus 4.6 distill в квантизации q4_k_m и q8. Первая даёт 60+ т/с, вторая около 14 т/с.
Фокус в том, что в задачах написания кода, поиска в нём ошибок, а так же в анализе изображений q8 показала себя заметно глупее, чем q4_k_m. Буквально. Я пока не выяснил, с чем это связано. Так что помимо самой разрядности важно чтобы сам процесс квантизации был проведён грамотно. И с этой q8 что-то пошло не так.
И будет тёмно‑серый вместо чёрного, с посаженой яркостью :)
Тогда уж лазерные ТВ стоит рассмотреть (которые на деле ультракороткофокусные лазерные проекторы), где экран из призм, и снизу выглядит белым, а снизу — чёрным. Не панацея, но лучше, чем ничего.
Такое делается не для «рационально», а для «круто». Лучи сами по себе не дают удовольствие, но могут значительно его улучшить, если разработчики грамотно применили эти технические возможности, а не впихнули для галочки.
А количество поедаемой памяти ещё зависит от разрешения. BF6 у меня жрёт около 12–15 гб vram (а там нет лучей) и без апскейла от силы выдаёт 40–50 fps, Deadloop с лучами вообще сожрал 28, хотя есть подозрение что кое‑кто просто плохо оптимизировал его. И плюс система сама по себе 3–4 Гб VRAM отъедает.
В теории если/когда в игры начнут впихивать локальные LLM (чтобы сделать NPC менее тупыми болванчиками, например) — там да, неплохо иметь запас дополнительных 15–30 гб. Но это не про сегодня.
Сам сталкивался с подобной проблемой когда в C# делал универсальную структуру для хранения векторов и скаляров. Структура имела размер 64 байта и должна была хранить длину вектора, тип элементов и сами значения. Проблема возникла с типом decmial, который весит 16 байт и в количестве 4 штуки занимает всё место.
Выкрутился так
Поля с размером и типом впихнул в 1 байт и разместил его там, где у decimal всегда нули. Да, у этого типа реально некоторые биты ВСЕГДА равны нулю. После этого извратил хранение длины и типа так, чтобы при длине 4 и типе decimal этот байт был всегда равен нулям. Профит: при хранении других типов (которые 8 байт и меньше) данные до туда не доходят из‑за ограничений по длине, а при четырёх decimal хранение данных, длины и типа в одном месте не противоречат друг другу.
Если у этого мусора включится способность размножаться и мутировать от модели к модели и/или от контекста к контексту, то есть запустится естественный отбор и эволюционный процесс в отношении информационного объекта внутри информационного объекта (своя местная ии‑меметика по аналогии с человеческой), то наш контроль над этим всем будет лишь ограниченным влиянием, про полный контроль можно забыть.
Насколько я понял, это не то. Это просто полупрозрачный монитор с чёрным фоном, и непрозрачность чёрных пикселей не регулируется. То есть тут, грубо говоря, альфа‑канал равен (R+G+B)/2+0.5, и не является отдельным независимым каналом. Бабочку с картинки оно не покажет. По факту тут это реализовано полупрозрачным зеркалом, в котором отражается лежащий на столе обычный непрозрачный монитор.
Я говорю о дисплее, где у каждого пикселя своя независимая непрозрачность и свой независимый цвет. И непрозрачность не зависит от цвета.
Ну, когда‑нибудь они поймут, что прозрачные дисплеи должны уметь показывать чёрный цвет (то есть быть полноценным RGBA, а не A = R+G+B), тогда эта штука не будет снижать практичность. Но пока что никто не спешит это делать.
вертикальный лазер изготовлен с использованием литографического процесса и может быть протестирован на пластине независимо от головки
Хм, в теории это можно использовать для создания голографических дисплеев. Отклонять луч можно либо MEMS зеркалами, которые можно тут же разместить, либо фазой, но это уже более отдалённые перспективы.
Жаль, была надежда что хотя бы в AndroidTV это вменяемо сделано :) На WebOS официально это не работает, насколько я знаю, и народ ставит ломанные прошивки с эксплоитами, с которыми очень не хотелось связываться.
Я думаю, что так сделано для минимизации лага при отображении картинки с ПК. Штош, продолжаем сидеть на DirectX, видимо альтернатив пока не предвидится.
Касательно лага — у себя практически не наблюдал, напротив у меня при восроизведении видео с Jellyfin клиента — подсветка обгоняет картинку) Поэтому и добавил параметры задержки.
Ага, то есть анализируется, по‑видимому, не то, что непосредственно на экране, а картинка из буфера плеера. Скажите пожалуйста, Вы случайно не тестировали софт, когда происходит трансляция картинки с внешнего HDMI источника (например, ПК)?
А HDR должен автоматически конвертироваться в SDR через MediaProjection API (8-битный RGBA_8888).
Ясно, спасибо за информацию. Загуглил — вроде бы да, MediaProjection кроме RGBA_8888 в другие форматы пока не умеет :(
Спасибо) В целом, я думаю, Вы правы — конструкция нужна будет сильно другая, а спрос на такое пока невелик. Но возможно в будущем он появится, по крайней мере, со стороны геймеров.
Тут нет единого угла, под которым было бы удобно пользоваться всегда. Руками двигать неудобно. Использую почти для всего: программирование, графика/видео/3д, нейросети, игры (в основном шутеры) и др.
Было бы интересно скомбинировать вашу штуку с моей — сделать раскладывающееся кресло и изменение угла всей композиции в целом. То есть чтобы экраны висели не на стене, как у меня, а на едином шасси как у E-station, которое вместе с креслом могло бы менять угол относительно земли.
3Д
Но есть сильное подозрение, что простым увеличением габаритов тут не отделаешься, так как массы тут несколько отличаются от обычных экранов.
Раньше под этим подразумевалось что‑то типа WinAPI/C++/MFC. Что сейчас подразумевается непонятно, но есть шанс что нужно будет две RTX 5090 чтобы панель задач меньше тормозила.
Попробуйте пообщаться с теми кто делает реализации кодеков H265/H266 на SIMD/CUDA, или кто пишет ядра инференса современных LLM :)
А есть ли заметная разница между 6 и 4 битами? Coder Next 80b пробовал только в 4 и 6 битах, 8 не пробовал. И 6 бит по уровню показались такими же, как 4 бита, даже на сложных задачах, а вот производительность там падала на дно. Видимо, рантайм был староват ещё.
Может быть в этом?
Спасибо, это лучшее объяснение работы JPEG, которое я читал.
В одно время приделал у себя в софте режим просмотра YCbCr 2×2 специально чтобы ловить, что камера стала передавать пережатый видеопоток — на цветоразностных каналах артефакты вылезают даже на высоком качестве. Ну и субдискретизация сразу видна по прямоугольным пикселям. У JPEG всё это ещё слабо выраженно, видеокодеки в этом плане заметно агрессивнее.
Теоретически кодеки могут дойти до уровня «текст промпта генерации + номер сида + хеш весов модели», там то точно биометрии некуда будет уместиться (и то не факт:|). Но практически до этого ещё далеко, хотя, вроде бы, в H266 уже потихонечку внедряют ИИ для сжатия.
Я гонял у себя qwen 3.5 27b claude opus 4.6 distill в квантизации q4_k_m и q8. Первая даёт 60+ т/с, вторая около 14 т/с.
Фокус в том, что в задачах написания кода, поиска в нём ошибок, а так же в анализе изображений q8 показала себя заметно глупее, чем q4_k_m. Буквально. Я пока не выяснил, с чем это связано. Так что помимо самой разрядности важно чтобы сам процесс квантизации был проведён грамотно. И с этой q8 что-то пошло не так.
И будет тёмно‑серый вместо чёрного, с посаженой яркостью :)
Тогда уж лазерные ТВ стоит рассмотреть (которые на деле ультракороткофокусные лазерные проекторы), где экран из призм, и снизу выглядит белым, а снизу — чёрным. Не панацея, но лучше, чем ничего.
Такое делается не для «рационально», а для «круто». Лучи сами по себе не дают удовольствие, но могут значительно его улучшить, если разработчики грамотно применили эти технические возможности, а не впихнули для галочки.
А количество поедаемой памяти ещё зависит от разрешения. BF6 у меня жрёт около 12–15 гб vram (а там нет лучей) и без апскейла от силы выдаёт 40–50 fps, Deadloop с лучами вообще сожрал 28, хотя есть подозрение что кое‑кто просто плохо оптимизировал его. И плюс система сама по себе 3–4 Гб VRAM отъедает.
В теории если/когда в игры начнут впихивать локальные LLM (чтобы сделать NPC менее тупыми болванчиками, например) — там да, неплохо иметь запас дополнительных 15–30 гб. Но это не про сегодня.
А как же мозг?
Получил огромное удовольствие, спасибо!
Сам сталкивался с подобной проблемой когда в C# делал универсальную структуру для хранения векторов и скаляров. Структура имела размер 64 байта и должна была хранить длину вектора, тип элементов и сами значения. Проблема возникла с типом decmial, который весит 16 байт и в количестве 4 штуки занимает всё место.
Выкрутился так
Поля с размером и типом впихнул в 1 байт и разместил его там, где у decimal всегда нули. Да, у этого типа реально некоторые биты ВСЕГДА равны нулю. После этого извратил хранение длины и типа так, чтобы при длине 4 и типе decimal этот байт был всегда равен нулям. Профит: при хранении других типов (которые 8 байт и меньше) данные до туда не доходят из‑за ограничений по длине, а при четырёх decimal хранение данных, длины и типа в одном месте не противоречат друг другу.
Если у этого мусора включится способность размножаться и мутировать от модели к модели и/или от контекста к контексту, то есть запустится естественный отбор и эволюционный процесс в отношении информационного объекта внутри информационного объекта (своя местная ии‑меметика по аналогии с человеческой), то наш контроль над этим всем будет лишь ограниченным влиянием, про полный контроль можно забыть.
Там регулируется прозрачность всего монитора целиком, а не каждого пикселя в отдельности.
Вот грубо говоря под слоем светодиодов должен быть слой вот такой вот плёнки, и под каждым пикселем свой независимый сектор. Я это имею в виду.
Насколько я понял, это не то. Это просто полупрозрачный монитор с чёрным фоном, и непрозрачность чёрных пикселей не регулируется. То есть тут, грубо говоря, альфа‑канал равен (R+G+B)/2+0.5, и не является отдельным независимым каналом. Бабочку с картинки оно не покажет. По факту тут это реализовано полупрозрачным зеркалом, в котором отражается лежащий на столе обычный непрозрачный монитор.
Я говорю о дисплее, где у каждого пикселя своя независимая непрозрачность и свой независимый цвет. И непрозрачность не зависит от цвета.
Ну, когда‑нибудь они поймут, что прозрачные дисплеи должны уметь показывать чёрный цвет (то есть быть полноценным RGBA, а не A = R+G+B), тогда эта штука не будет снижать практичность. Но пока что никто не спешит это делать.
Хм, в теории это можно использовать для создания голографических дисплеев. Отклонять луч можно либо MEMS зеркалами, которые можно тут же разместить, либо фазой, но это уже более отдалённые перспективы.
Спасибо за информацию!
Жаль, была надежда что хотя бы в AndroidTV это вменяемо сделано :) На WebOS официально это не работает, насколько я знаю, и народ ставит ломанные прошивки с эксплоитами, с которыми очень не хотелось связываться.
Я думаю, что так сделано для минимизации лага при отображении картинки с ПК. Штош, продолжаем сидеть на DirectX, видимо альтернатив пока не предвидится.
Ага, то есть анализируется, по‑видимому, не то, что непосредственно на экране, а картинка из буфера плеера. Скажите пожалуйста, Вы случайно не тестировали софт, когда происходит трансляция картинки с внешнего HDMI источника (например, ПК)?
Ясно, спасибо за информацию. Загуглил — вроде бы да, MediaProjection кроме RGBA_8888 в другие форматы пока не умеет :(