madVR нет на Linux и macOS, у него закрытый исходный код
возможностей настроек больше, в т.ч. 3dlut и прочих калибровок
mpv может подгружать профиль монитора или 3DLUT для применения к видео
На счёт остального, тут суть не добиться уровня HDR OLED дисплея, а улучшить картинку по сравнению с обычной, что, на мой взгляд, получается (как минимум, если дисплей не тусклее 400 нит)
Сжатие динамического диапазона. Вся картинка станет блеклой, потеря контраста. И так почти всегда и везде.
Можно сжать только света до необходимого верхнего уровня, а остальное (в диапазоне воспроизводимой монитором яркости) показать "как есть". В этом посте как раз указан способ увеличения того самого верхнего уровня
Насколько я знаю, поддержка пока только у 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 с минимальной обработкой, как выше в посте, например. Также, "вышеуказанный метод" - метод Билла Клэффа? Просто в предложенном нужно обязательно строить график для оценки результатов (или как минимум найти несколько значений)
И как вы это делали? Чтобы быть уверенным в "без влияние обработки и алгоритмов от производителей смартфонов."
Я имел в виду, что тут максимально сырой кадр, который можно получить стандартными средствами - только ремозаик и возможный шумодав от ISP, нет дополнительной обработки, как при сохранении в JPEG
Т.е. сильно смахивает на элементарную программную эмуляцию.
Я не уверен, что это программная эмуляция - хотя бы потому, что в таком случае репутационные риски для компании слишком большие. Ну и тут можно пофоткать мишеньку на разрешение - я не стал этого делать, так как хотел показать средний случай, но, думаю, в следующий раз надо сделать
А ещё удивляет тот факт, что 48мпикс. снимки с адовой пикселизацией, а 12мпикс как будто замыленные "сглаживанием"... Что-то каким-то совсем уж откровенным... обманом попахивает))
Просто не добавлена резкость и низкий микроконтраст, так выглядит любой сырой снимок без обработки Добавлено: пикселизация - артефакты от ремозаика
Ну и почему нигде не упомянута дифракция? Я так понимаю, Сони совершила какой-то прорыв в фундаментальной физике, что может обходить дифракционные пределы аж на 48мпикс. на 0.31'? ))
Согласно калькулятору диффракции, при размере пикселя 0.8 мкм диффракцию можно обойти уже на <f/1.6, что вполне реалистично для некоторых смартфонов (но да, не в этом примере). Но это и не важно, ведь главное получить преимущество по сравнению с детализацией 12 мп снимков
Про дизеринг действительно так, но не соглашусь про ненужную разрядность - для получения аналога 12-битной точности потребуется в лучшем случае 4 кадра, и если для этих 4 кадров использовать исходно 12-битные изображения вместо 10-битных, мы, в теории, можем получить чуть более чистые тени (далее отредактировано), так как теперь у нас на 2 стопа выше динамический диапазон и мы можем упереться в порог точности
Я думаю, тут имеется в виду 3CCD система, где призма разбивает поток света на 3 части для 3 сенсоров - https://en.wikipedia.org/wiki/Three-CCD_camera. Такие системы достаточно громоздкие, для использования в телефоне придётся использовать 3 очень маленьких сенсора, а тогда с большой вероятностью нивелируется выигрыш в светочувствительности
Всё полностью линейное - RAW формат сам по себе (в большинстве случаев) представляет линейные данные прямиком с сенсора, а далее обработка и подсчёт SNR проводились с 16-битными линейными TIFF файлами в качестве контейнера, как и в прошлом посте
Вы правы, я добавил "со сбором мусора", спасибо
madVR нет на Linux и macOS, у него закрытый исходный код
mpv может подгружать профиль монитора или 3DLUT для применения к видео
На счёт остального, тут суть не добиться уровня HDR OLED дисплея, а улучшить картинку по сравнению с обычной, что, на мой взгляд, получается (как минимум, если дисплей не тусклее 400 нит)
Конвертация через
inverse-tone-mapping
работает и для онлайн видео. Кроме того, можно запускать HDR стримы с YouTubeМожно сжать только света до необходимого верхнего уровня, а остальное (в диапазоне воспроизводимой монитором яркости) показать "как есть". В этом посте как раз указан способ увеличения того самого верхнего уровня
Насколько я знаю, поддержка пока только у Nightly сборок, но у Dolby Vision есть разные профили, как минимум один основан на HLG, и с ним проблем не будет даже в стабильной версии
Не обязательно - можно просто один раз указать максимальную яркость и поднимать её до такого значения каждый раз перед просмотром фильма (а после опускать до нормальной)
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
Я не уверен, что это программная эмуляция - хотя бы потому, что в таком случае репутационные риски для компании слишком большие. Ну и тут можно пофоткать мишеньку на разрешение - я не стал этого делать, так как хотел показать средний случай, но, думаю, в следующий раз надо сделать
Просто не добавлена резкость и низкий микроконтраст, так выглядит любой сырой снимок без обработки Добавлено: пикселизация - артефакты от ремозаика
Согласно калькулятору диффракции, при размере пикселя 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 файлами в качестве контейнера, как и в прошлом посте