Вы правы, я добавил "со сбором мусора", спасибо

А зачем подобное вообще нужно если есть madVR?

madVR нет на Linux и macOS, у него закрытый исходный код

возможностей настроек больше, в т.ч. 3dlut и прочих калибровок

mpv может подгружать профиль монитора или 3DLUT для применения к видео

На счёт остального, тут суть не добиться уровня HDR OLED дисплея, а улучшить картинку по сравнению с обычной, что, на мой взгляд, получается (как минимум, если дисплей не тусклее 400 нит)

я это знаю, просто как это коррелирует с необходимостью конвертации контента?

Конвертация через inverse-tone-mapping работает и для онлайн видео. Кроме того, можно запускать HDR стримы с YouTube

Сжатие динамического диапазона. Вся картинка станет блеклой, потеря контраста. И так почти всегда и везде.

Можно сжать только света до необходимого верхнего уровня, а остальное (в диапазоне воспроизводимой монитором яркости) показать "как есть". В этом посте как раз указан способ увеличения того самого верхнего уровня

Насколько я знаю, поддержка пока только у Nightly сборок, но у Dolby Vision есть разные профили, как минимум один основан на HLG, и с ним проблем не будет даже в стабильной версии

то есть для просмотра этого контента мне нужно будет купить отдельный SDR монитор/ТВ и настроить его под этот контент?

Не обязательно - можно просто один раз указать максимальную яркость и поднимать её до такого значения каждый раз перед просмотром фильма (а после опускать до нормальной)

то есть онлайн просмотр отпадает?

mpv может проигрывать онлайн-стримы и даже YouTube через yt-dlp - для второго укажите script-opts=ytdl_hook-ytdl_path=/path/to/yt-dlp

Вам нужно сравнить картинку слева на полной (и указанной) яркости монитора с картинкой справа на яркости 100-200 нит - слева, например, света будут действительно светиться Дополнено: кроме того, сработает только если видео HDR, или конвертируется в HDR с помощью inverse-tone-mapping

У Вас интересные данные. К сожалению, использование JPEG вывода может вызвать ряд неточностей, так как мы анализируем уже обработанную информацию, с учётом шумодава, резкости, применённой тоновой кривой и конвертации в гамму и 8 бит. Интересно было бы узнать, как меняется результат в RAW с минимальной обработкой, как выше в посте, например. Также, "вышеуказанный метод" - метод Билла Клэффа? Просто в предложенном нужно обязательно строить график для оценки результатов (или как минимум найти несколько значений)

Всё так, просто в этом случае я отключал свой Magisk модуль

И как вы это делали? Чтобы быть уверенным в "без влияние обработки и алгоритмов от производителей смартфонов."

Я имел в виду, что тут максимально сырой кадр, который можно получить стандартными средствами - только ремозаик и возможный шумодав от ISP, нет дополнительной обработки, как при сохранении в JPEG

Т.е. сильно смахивает на элементарную программную эмуляцию.

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

А ещё удивляет тот факт, что 48мпикс. снимки с адовой пикселизацией, а 12мпикс как будто замыленные "сглаживанием"... Что-то каким-то совсем уж откровенным... обманом попахивает))

Просто не добавлена резкость и низкий микроконтраст, так выглядит любой сырой снимок без обработки Добавлено: пикселизация - артефакты от ремозаика

Ну и почему нигде не упомянута дифракция? Я так понимаю, Сони совершила какой-то прорыв в фундаментальной физике, что может обходить дифракционные пределы аж на 48мпикс. на 0.31'? ))

Согласно калькулятору диффракции, при размере пикселя 0.8 мкм диффракцию можно обойти уже на <f/1.6, что вполне реалистично для некоторых смартфонов (но да, не в этом примере). Но это и не важно, ведь главное получить преимущество по сравнению с детализацией 12 мп снимков

Про дизеринг действительно так, но не соглашусь про ненужную разрядность - для получения аналога 12-битной точности потребуется в лучшем случае 4 кадра, и если для этих 4 кадров использовать исходно 12-битные изображения вместо 10-битных, мы, в теории, можем получить чуть более чистые тени (далее отредактировано), так как теперь у нас на 2 стопа выше динамический диапазон и мы можем упереться в порог точности

У Quest Pro две монохромных и одна цветная, у Nokia 9 две цветных и три монохромных

Спасибо, исправил

А, тогда это система как в Nokia 9 и Quest Pro

Я думаю, тут имеется в виду 3CCD система, где призма разбивает поток света на 3 части для 3 сенсоров - https://en.wikipedia.org/wiki/Three-CCD_camera. Такие системы достаточно громоздкие, для использования в телефоне придётся использовать 3 очень маленьких сенсора, а тогда с большой вероятностью нивелируется выигрыш в светочувствительности

Всё полностью линейное - RAW формат сам по себе (в большинстве случаев) представляет линейные данные прямиком с сенсора, а далее обработка и подсчёт SNR проводились с 16-битными линейными TIFF файлами в качестве контейнера, как и в прошлом посте