Жанр народного негодования имеет право на жизнь, но ведь не всегда уместен.
Выше так же зря "на публику" спросили, почему формат картинок с поддержкой float128 остался нишевым. Я однажды задумался - должны же быть вещи, которые в TIFF не влезут, которые он не способен вместить.
Иди его растянут на тот диапазон, в котором он будет выглядеть непонятно как?
HDR в экранах должен работать как в старом добром 2017 году, тут нет новостей.
Но в хранении HDR-изображений появился новый подход:
Видимо, слишком скучно* и провоцирует много неудобных мыслей: Millenniata обанкротилась, очередное поколение оптических дисков (DVD->BD->AD) не вышло из профессионального сегмента (и там тоже загнулось), а технология из статьи в лучшем случае сравнится по доступности с LTO (привод нынешнего поколения от $11000).
Уже много лет как осталась одна стратегия - нацеливать "холодные" накопители на крупный бизнес, предлагая ему дешёвые носители, дорогие приводы и окупаемость на петабайтах.
А продвинутые домашние юзеры подбирают объедки в виде легаси BD, б/у LTO, б/у и новых HDD.
* 100-гиговый диск запишется за часы, а на 256 кбит/с потребовалось бы больше месяца.
Вторая картинка гуляет по интернету в чистом png (не jpg) и с копирайтом Photutorial.com, который её создал без эксплуатации органических нейросетей, как заявлено в их статье:
Format comparison
JPG vs. JPEG
The main difference between JPG and JPEG is that JPEG is a file format, while JPG is a 3-letter file extension for JPEG ... JPEG is better suited for lossless compression of photos ... WebP produces smaller file sizes than AVIF
> Mozilla выступает за JPEG XL
Они выступают за всё хорошее и против всего плохого. Они поддерживают вообще всё что могут по закону)
Они высказывались против. Ну, формально, "нейтрально", но с подтекстом, что будут делать как Google.
Как я понимаю, получилась бы ошибка в невозможную сторону:
синий уходит в зелёный, если HD-видео ошибочно перевести в RGB как SD-видео
и в невозможном месте:
нет преобразования в RGB - нет места для ошибки, а оно происходит лишь на этапе воспроизведения видео (не в карте захвата).
То есть цвета сильнее плывут по другим причинам и соблюдение правила "601-коэффициенты для SD-видео и 709-коэффициенты для HD-видео" в данном случае это педантичность. Нам оставили в наследство два неудобства:
поменяли без нужды коэффициенты в стандарте на HD-видео
не сделали YUV в видео чисто внутренней деталью реализации (вот JPEG использует коэффициенты из BT.601, но это и не важно)
Но это небольшие проблемы, при цветокоррекции видео меняют сильнее.
в конце концов, хранить/стримить в loseless или вообще в RAW. PNG/EXR сиквенсы + WAV рулят :)
Если оставить в YCbCr, то цветность проредить можно будет (хотя бы по горизонтали для чересстрочного). 4:2:2 уменьшит битрейт в полтора раза, 4:1:1 - в два раза, передовым lossless-сжатием для видео вроде остаётся FFV1 в 2 прохода (уменьшит битрейт ещё чуть больше двух раз).
Ну моя идея не в том, что это однозначно улучшит качество, а в том, что при этом мы с меньшей вероятностью потеряем информацию, и даже если она не видна для глаза, она может стать важна для каких‑нибудь алгоритмов обработки, которые мы применим дальше в конвейере.
На кашу из топора похоже - выбрали аппарат по наличию компонентного выхода (польза для VHS туманна), получили в целом качественный аппарат с TBC (польза очевидна), использовали компонентный выход (раз уж есть, то тупо не использовать*), а проверять гипотезы насчёт композита в конце этого длинного пути уже никому не захочется.
В радиоэфире других нет, так что телевизор обречён синхронизироваться по ним. По импульсам внутри импульсов, точнее. По синхронизирующим (vertical sync pulses) внутри гасящих (vertical blanking period).
Я про саму теоретическую возможность с её теоретическими последствиями.
И приправляю коммент тем, что не знаю, сколько там в норме шума в момент переключения и что там ещё теряется кроме фазы этого антисоветского FM-звука (допустим, сколько частей строки, если бы на ней хранилось что-то полезное).
Ну, суть в том, что он не один такой. Для телевизора есть синхронизация в самом видеосигнале на наклонных дорожках - как строчный HBLANK остаётся на месте, так и кадровый VBLANK.
Оффтоп: сейчас странновато смотреть, как в аналоге хранили невидимые части кадра, но тогда это была хорошая идея и в них потом дополнительную информацию пихали. Субтитры, телетекст, мини-настроечная таблица (ITU-T J.63), метаданные на LD...
Такая экономия места (8-9%) ещё бы Hi-Fi Stereo сломала, если подумать.
Но какие-то из невидимых строк должны быть сильно зашумлены в момент смены головок (head switching noise). Вот в книжке пишут, что пришлось постараться, чтобы дорожка Hi-Fi Stereo не щёлкала 50-60 раз в секунду.
Ну, я про другой, психологический, эффект говорил. Когда высокочастотное мельтешение не даёт чётко всмотреться и закричать при виде настоящего адского мыло-пластилина. Возможность совершенно ясно увидеть отсутствие деталей бывает неприятной и проявит остальные артефакты.
Another linear control track at the tape's lower edge holds pulses that mark the beginning of every frame of video; these are used to fine-tune the tape speed during playback...
На наклонных дорожках остаётся информация для этого (VBLANK, кадровый гасящий импульс). Теоретически её могли бы выкинуть для экономии места, но субтитры, защита Macrovision и стоп-кадр сообщают, что (все?) невидимые строки на месте.
Компонентный выход у магнитофона. Гораздо качественнее композита, где всё по одному проводу
Если принимать это безусловно, можно оцифровку лазердиска испортить. Для него композит - родной формат и наилучший демодулятор вряд ли окажется в старом проигрывателе (а не на стороне приёмника сигнала - т.е. в карте захвата или софте ld-decode).
В случае VHS родной формат на кассете похож на S-Video (цветность отделена от яркости и впихнута в полосу частот под яркостью - т.н. color-under) и компонентный выход (S-Video или YPbPr) позволит избежать лишнего объединения-разделения цветности и яркости, но ЕМНИП, люди не видели однозначного улучшения - полосы частот так порезаны при записи, что заметные артефакты от разделения не возникают.
В S-VHS расширили полосу яркости, в композите она стала явно пересекаться с цветностью (=> артефакты разделения) и поэтому в видаки с поддержкой S-VHS добавили S-Video.
YPbPr в этот видак поставили ради цифрового D-VHS*, HD-сигналу которого есть что терять и который не имел преступных связей с композитом. Ну и ради цифровой обработки (TBC, DNR), то есть ему бы вообще цифровой выход иметь, раз он всё через цифру прогоняет.
Аналоговый шум надо убирать
Сохранять плёночное зерно в 4K сейчас считается нормальным, а тут разрешение в 30 раз меньше и хранить шум слишком дорого? Нет, если шум маскирует нехватку деталей (улучшает субъективное качество), то пусть остаётся. Для видеохостингов SD-видео апскейлят, чтобы заставить их поднять битрейт (потому что это единственный переключатель качества со стороны пользователя, кнопки "576p/480p High Bitrate" у него нет).
Упоротый вариант — подцепить АЦП к головке магнитофона. Но это, кхм, сопряжено некоторыми небольшими сложностями :)
Вся статья про это - в видеомагнитофон залезли настолько глубоко, насколько есть смысл (предусилителю и штуке, которая сигналы с чередующихся головок объединяет, можно и довериться). Залезли в эту точку, получается:
Figure 8.4.5 Block diagram of a color-under system из этой книжки
* Это видак 3-в-1 (VHS, S-VHS, D-VHS) и он до сих пор тыщу долларов стоит.
Этот счётчик должен испытать экзистенциальный кризис. Если решение принимается по такому числу отсчётов, которое в сумме дольше возможного дребезга, то что полезного он считает? Если мы только фильтруем дребезг, то ничего полезного - антидребезг с мгновенной реакцией + dead time будет лучше.
Если мгновенная реакция не нужна, то решение сводится к редкому опросу с периодом, совпадающим с выбранным dead time (как в комментах ниже про 0,5 секунды и 200 мс).
Для пользователя это будет задержкой, потому что обычно нужна реакция по нажатию, а не отпусканию.
Если ещё допустить, что в нажатом состоянии контакт всегда уверенный (хм...), то вроде бы можно и спад не фильтровать - потеряется только точность времени отпускания. То есть после регистрации отпускания также прекращаем частый опрос (или отключаем прерывания) на время больше дребезга либо всегда опрашиваем с периодом больше этого времени.
Он про алиасинг говорит. Контакты дребезжат с частотой до f, а выборку делаем с частотой явно ниже 2*f и Котельников нам напоминает, что мы рискуем увидеть ошибочную картину.
Ух какой шустрый мух
Но этот риск можно счесть приемлемым.
А можно иначе рассудить - если кнопка будет до ~100 мс дребезжать, то зачем вообще её повторно опрашивать в это время? Чтобы собирать статистику по длительности дребезга и реализовывать антидребезг, адаптирующийся к старению кнопок? Ну-ну. В одной статье упоминают возможный "short glitch" в нажатом состоянии - это, видимо, про полунажатое состояние в случае с мягкими мембранами как в пультах или компьютерных клавиатурах.
В статье и комментах в сумме много раз повторяется неприятный момент - лишняя задержка в программном способе. Не надо задерживать обработку нажатия до окончания переходного процесса, зачем? Если контакт замкнулся один раз, то нам уже известно, что кнопку нажали, можно реагировать без лишних тормозов.
Причину придумать можно - борьба с какими-то злостными помехами, но тогда бы недоверие к первому отсчёту (это не контакт замкнулся, это молния рядом ударила) проговаривалось явно и перечислялось вместе с другими необходимыми мерами защиты от электромагнитных помех, а так это просто ошибка.
Казалось, все принципиальные вопросы должны быть уже решены, а решения — повсюду внедрены. Разве не так?
Чтобы "повсюду", они должны быть бесплатными и универсальными (не только распределённые, не только для дорогих однотипных СХД), а кто их оплатит? Linux - это люди с горящими красными глазами или миллиарды долларов от IBM?
Теодор Тс'о (он же мейнтейнер ext4) недавно рассуждал про файловые системы только в ключе окупаемости. Sun сделала ZFS - и где теперь Sun? Оценил готовую к применению btrfs в 100 человеко-лет и услышал, что руководство никогда не одобрит разработку, если увидит это число. Новые фичи в ext4 можно, если проспонсируете; вырастут ли продажи вашего продукта из-за доработки ext4?
В Ext4 продолжают включать новые возможности, но это та функциональность, которую компании готовы финансировать, потому что окупаемость инвестиций в разработку новых возможностей имеет смысл с точки зрения затрат и выгод.
reflinks - более интересен, но я не смог найти заказчика, готового оплатить расходы на разработку, или компанию, которая считает, что продажи их продукта возрастут, если добавить reflinks в ext4.
я должен хорошо понимать, как я приношу работодателю пользу, по крайней мере, в 10 раз превышающую мою зарплату.
многие компании, приславшие своих представителей на встречу, отказались предоставить инженеров для работы над btrfs, и это, конечно, не помогло. Но, вероятно, это было связано с тем, что компании - рациональные организации, принимающие собственные решения об окупаемости инвестиций
В btrfs вкладывается фейсбук. Но фейсбуку не нужна функциональность массивов в btrfs, поэтому неготовность RAID 5/6 вроде уже достигла совершеннолетия.
Снапшоты ради-традиционных-ФС-но-без-LVM-и-лучше-чем-в-LVM в мейнлайн два раза безуспешно пытались протолкнуть. Со смазкой шансов было бы больше.
В обсуждении этой новости на Phoronix иронизируют над тем, что у Intel и AMD смазка есть ("Intel ... Linux 6.16-rc3 ... bit of feature code was pulled"[1] и ещё какие-то случаи).
Жанр народного негодования имеет право на жизнь, но ведь не всегда уместен.
Выше так же зря "на публику" спросили, почему формат картинок с поддержкой float128 остался нишевым. Я однажды задумался - должны же быть вещи, которые в TIFF не влезут, которые он не способен вместить.
HDR в экранах должен работать как в старом добром 2017 году, тут нет новостей.
Но в хранении HDR-изображений появился новый подход:
SDR + Gain Map
https://en.wikipedia.org/wiki/High_dynamic_range#Storage
...который лучше решает проблему отображения в SDR и не требует новых файловых форматов - годится всё тот же JPEG.
Новые форматы создают ради сжатия.
Видимо, слишком скучно* и провоцирует много неудобных мыслей: Millenniata обанкротилась, очередное поколение оптических дисков (DVD->BD->AD) не вышло из профессионального сегмента (и там тоже загнулось), а технология из статьи в лучшем случае сравнится по доступности с LTO (привод нынешнего поколения от $11000).
Уже много лет как осталась одна стратегия - нацеливать "холодные" накопители на крупный бизнес, предлагая ему дешёвые носители, дорогие приводы и окупаемость на петабайтах.
А продвинутые домашние юзеры подбирают объедки в виде легаси BD, б/у LTO, б/у и новых HDD.
* 100-гиговый диск запишется за часы, а на 256 кбит/с потребовалось бы больше месяца.
Вторая картинка гуляет по интернету в чистом png (не jpg) и с копирайтом Photutorial.com, который её создал без эксплуатации органических нейросетей, как заявлено в их статье:
Format comparison
JPG vs. JPEG
The main difference between JPG and JPEG is that JPEG is a file format, while JPG is a 3-letter file extension for JPEG
...
JPEG is better suited for lossless compression of photos
...
WebP produces smaller file sizes than AVIF
Они высказывались против. Ну, формально, "нейтрально", но с подтекстом, что будут делать как Google.
Как я понимаю, получилась бы ошибка в невозможную сторону:
синий уходит в зелёный, если HD-видео ошибочно перевести в RGB как SD-видео
и в невозможном месте:
нет преобразования в RGB - нет места для ошибки, а оно происходит лишь на этапе воспроизведения видео (не в карте захвата).
То есть цвета сильнее плывут по другим причинам и соблюдение правила "601-коэффициенты для SD-видео и 709-коэффициенты для HD-видео" в данном случае это педантичность. Нам оставили в наследство два неудобства:
поменяли без нужды коэффициенты в стандарте на HD-видео
не сделали YUV в видео чисто внутренней деталью реализации (вот JPEG использует коэффициенты из BT.601, но это и не важно)
Но это небольшие проблемы, при цветокоррекции видео меняют сильнее.
Дополню:
Анимация ошибки при выборе матричных коэффициентах для YUV=>RGB (601 или 709)
ffmpeg -i wrong_matrix.avs -plays 0 -y out.apngЕсли оставить в YCbCr, то цветность проредить можно будет (хотя бы по горизонтали для чересстрочного). 4:2:2 уменьшит битрейт в полтора раза, 4:1:1 - в два раза, передовым lossless-сжатием для видео вроде остаётся FFV1 в 2 прохода (уменьшит битрейт ещё чуть больше двух раз).
На кашу из топора похоже - выбрали аппарат по наличию компонентного выхода (польза для VHS туманна), получили в целом качественный аппарат с TBC (польза очевидна), использовали компонентный выход (раз уж есть, то тупо не использовать*), а проверять гипотезы насчёт композита в конце этого длинного пути уже никому не захочется.
* принцип не работает с лазердисками
В радиоэфире других нет, так что телевизор обречён синхронизироваться по ним. По импульсам внутри импульсов, точнее. По синхронизирующим (vertical sync pulses) внутри гасящих (vertical blanking period).
Я про саму теоретическую возможность с её теоретическими последствиями.
И приправляю коммент тем, что не знаю, сколько там в норме шума в момент переключения и что там ещё теряется кроме фазы этого антисоветского FM-звука (допустим, сколько частей строки, если бы на ней хранилось что-то полезное).
Ну, суть в том, что он не один такой. Для телевизора есть синхронизация в самом видеосигнале на наклонных дорожках - как строчный HBLANK остаётся на месте, так и кадровый VBLANK.
Оффтоп: сейчас странновато смотреть, как в аналоге хранили невидимые части кадра, но тогда это была хорошая идея и в них потом дополнительную информацию пихали. Субтитры, телетекст, мини-настроечная таблица (ITU-T J.63), метаданные на LD...
Такая экономия места (8-9%) ещё бы Hi-Fi Stereo сломала, если подумать.
Но какие-то из невидимых строк должны быть сильно зашумлены в момент смены головок (head switching noise). Вот в книжке пишут, что пришлось постараться, чтобы дорожка Hi-Fi Stereo не щёлкала 50-60 раз в секунду.
Ну, я про другой, психологический, эффект говорил. Когда высокочастотное мельтешение не даёт чётко всмотреться и закричать при виде настоящего адского мыло-пластилина. Возможность совершенно ясно увидеть отсутствие деталей бывает неприятной и проявит остальные артефакты.
enwiki говорит про это поточнее:
На наклонных дорожках остаётся информация для этого (VBLANK, кадровый гасящий импульс). Теоретически её могли бы выкинуть для экономии места, но субтитры, защита Macrovision и стоп-кадр сообщают, что (все?) невидимые строки на месте.
Если принимать это безусловно, можно оцифровку лазердиска испортить. Для него композит - родной формат и наилучший демодулятор вряд ли окажется в старом проигрывателе (а не на стороне приёмника сигнала - т.е. в карте захвата или софте ld-decode).
В случае VHS родной формат на кассете похож на S-Video (цветность отделена от яркости и впихнута в полосу частот под яркостью - т.н. color-under) и компонентный выход (S-Video или YPbPr) позволит избежать лишнего объединения-разделения цветности и яркости, но ЕМНИП, люди не видели однозначного улучшения - полосы частот так порезаны при записи, что заметные артефакты от разделения не возникают.
В S-VHS расширили полосу яркости, в композите она стала явно пересекаться с цветностью (=> артефакты разделения) и поэтому в видаки с поддержкой S-VHS добавили S-Video.
YPbPr в этот видак поставили ради цифрового D-VHS*, HD-сигналу которого есть что терять и который не имел преступных связей с композитом. Ну и ради цифровой обработки (TBC, DNR), то есть ему бы вообще цифровой выход иметь, раз он всё через цифру прогоняет.
Сохранять плёночное зерно в 4K сейчас считается нормальным, а тут разрешение в 30 раз меньше и хранить шум слишком дорого? Нет, если шум маскирует нехватку деталей (улучшает субъективное качество), то пусть остаётся. Для видеохостингов SD-видео апскейлят, чтобы заставить их поднять битрейт (потому что это единственный переключатель качества со стороны пользователя, кнопки "576p/480p High Bitrate" у него нет).
Вся статья про это - в видеомагнитофон залезли настолько глубоко, насколько есть смысл (предусилителю и штуке, которая сигналы с чередующихся головок объединяет, можно и довериться). Залезли в эту точку, получается:
* Это видак 3-в-1 (VHS, S-VHS, D-VHS) и он до сих пор тыщу долларов стоит.
Этот счётчик должен испытать экзистенциальный кризис. Если решение принимается по такому числу отсчётов, которое в сумме дольше возможного дребезга, то что полезного он считает? Если мы только фильтруем дребезг, то ничего полезного - антидребезг с мгновенной реакцией + dead time будет лучше.
Чья-то реализация: https://www.eevblog.com/forum/beginners/keyboard-switch-matrix-hw-debounce-multiplexer/msg3926876/#msg3926876
Если мгновенная реакция не нужна, то решение сводится к редкому опросу с периодом, совпадающим с выбранным dead time (как в комментах ниже про 0,5 секунды и 200 мс).
Для пользователя это будет задержкой, потому что обычно нужна реакция по нажатию, а не отпусканию.
Если ещё допустить, что в нажатом состоянии контакт всегда уверенный (хм...), то вроде бы можно и спад не фильтровать - потеряется только точность времени отпускания. То есть после регистрации отпускания также прекращаем частый опрос (или отключаем прерывания) на время больше дребезга либо всегда опрашиваем с периодом больше этого времени.
Он про алиасинг говорит. Контакты дребезжат с частотой до f, а выборку делаем с частотой явно ниже 2*f и Котельников нам напоминает, что мы рискуем увидеть ошибочную картину.
Ух какой шустрый мухНо этот риск можно счесть приемлемым.
А можно иначе рассудить - если кнопка будет до ~100 мс дребезжать, то зачем вообще её повторно опрашивать в это время? Чтобы собирать статистику по длительности дребезга и реализовывать антидребезг, адаптирующийся к старению кнопок? Ну-ну. В одной статье упоминают возможный "short glitch" в нажатом состоянии - это, видимо, про полунажатое состояние в случае с мягкими мембранами как в пультах или компьютерных клавиатурах.
В статье и комментах в сумме много раз повторяется неприятный момент - лишняя задержка в программном способе. Не надо задерживать обработку нажатия до окончания переходного процесса, зачем? Если контакт замкнулся один раз, то нам уже известно, что кнопку нажали, можно реагировать без лишних тормозов.
Причину придумать можно - борьба с какими-то злостными помехами, но тогда бы недоверие к первому отсчёту (это не контакт замкнулся, это молния рядом ударила) проговаривалось явно и перечислялось вместе с другими необходимыми мерами защиты от электромагнитных помех, а так это просто ошибка.
"Кремний на сапфире", если в совсем-совсем крайнем.
Чтобы "повсюду", они должны быть бесплатными и универсальными (не только распределённые, не только для дорогих однотипных СХД), а кто их оплатит?
Linux - это люди с горящими красными глазами или миллиарды долларов от IBM?Теодор Тс'о (он же мейнтейнер ext4) недавно рассуждал про файловые системы только в ключе окупаемости. Sun сделала ZFS - и где теперь Sun? Оценил готовую к применению btrfs в 100 человеко-лет и услышал, что руководство никогда не одобрит разработку, если увидит это число. Новые фичи в ext4 можно, если проспонсируете; вырастут ли продажи вашего продукта из-за доработки ext4?
В btrfs вкладывается фейсбук. Но фейсбуку не нужна функциональность массивов в btrfs, поэтому неготовность RAID 5/6 вроде уже достигла совершеннолетия.
Снапшоты ради-традиционных-ФС-но-без-LVM-и-лучше-чем-в-LVM в мейнлайн два раза безуспешно пытались протолкнуть. Со смазкой шансов было бы больше.
В обсуждении этой новости на Phoronix иронизируют над тем, что у Intel и AMD смазка есть ("Intel ... Linux 6.16-rc3 ... bit of feature code was pulled"[1] и ещё какие-то случаи).