Только его можно очень по-разному оверселлить. Всегда удивляли американские истории про 1.2 ТБ на месяц. В худшем случае часа три интернета. А бэкап на пару терабайт только почтой.
Мне здесь компетенций не хватает, но что-то совсем не так. Конкретному решению (поставить параллельно керамику) нужна конкретная проблема, а если опасаться чего-то неопределённого, то это плохо кончится зачем оставлять электролит?
Если опасаться чего-то неопределённого на резонансной частоте конденсатора или за ней, то это вопрос не к электролиту, а к большому номиналу, который выбрали в vhs-decode. Они советуют 10 мкФ керамикой, у которой резонанс будет на 2-4 МГц - в полосе VHS.
который будет недопускать ввода-вывода (не суть важно, как именно, просто представим, что может)
Тогда не стоит его называть [[gnu::pure]] - этот атрибут не про гарантии от компилятора для программиста*, а наоборот - программист обещает компилятору, что функция чистая:
In short, you shouldn't be saying it's pure or const if it's not pure or const ... if the user is marking trivial functions const or pure when they clearly aren't, they deserve what they get :). ... attributes are meant for when you are sure you know more than the compiler can tell - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
Нормальные люди переименовали бы его в [[gnu::assume_pure]]...
в видеомагнитофон залезли настолько глубоко, насколько есть смысл (предусилителю и штуке, которая сигналы с чередующихся головок объединяет, можно и довериться)
Нет, некоторые считают, что кроличья нора должна быть глубже.
"2. tapping RF off of pickup rather than internal RF test point (avoids 90s era amplification circuitry)" - forum.lddb (это про аналогичный проект с лазердисками).
Что? Мы словно с передачи RF-сигнала на импульсные БП перескочили. Там бы керамика была ultra-low-ESR/ESL дополнением к электролиту, а здесь зачем?
Как я понимаю, здесь конденсатор - это развязка по постоянному току на всякий случай. При этом закрываются глаза на согласование импедансов (=> отражения сигнала) и на поведение видеомагнитофона с этой дополнительной нагрузкой. Потому что и так неплохо работает. А если погружаются глубже, то переходят сразу к установке усилителя.
У нас здесь аналог пассивного щупа осциллографа (впрочем, несогласованного). И по тем же причинам, по которым в щупах "крокодил" земли меняют на короткую пружину, лучше максимально уменьшить расстояние (или площадь петли) как на картинке. (заметки по теме: rohde-schwarz, stackexchange[1][2])
Вообще начинание-то прекрасное и прекрасно, как vhs-decode снижает стоимость качественной оцифровки. И здесь нет никакого шок-контента, от которого могли бы кадры с полями в голове перепутаться (это к началу ветки).
Ну, среди свободных / бесплатных знаю родной ffmpeg'овский (-vcodec jpeg2000) и сторонний OpenJPEG (-vcodec libopenjpeg). Сторонний декодер был ещё медленнее и его удалили в 2023 в рамках решения оставлять только собственные декодеры их при наличии. Энкодер оставили.
Документация пропитана презрением - родной энкодер более-менее задокументирован только на сайте, а сторонний, наоборот, там не упоминается и не имеет описания параметров в хелпе или исходниках.
В lossless-режиме по степени сжатия оба не обгоняют png (медленный пресет выставил бы, если бы его можно было настроить). Из одного крупного бенчмарка lossless-кодеков его выкинули, не впечатлившись результатами (какой именно кодек - не знаю, но явно не платный).
______
Про Motion JPEG 2000 - до этого знал только про применение в кино, его там в DCP используют.
Ещё есть jpeg2000/wavelet, не делающий jpeg-артефактов
У него видится фатальный недостаток.
ffmpeg у меня декодирует его в 15 раз медленнее, чем jpeg92. ffmpeg -hide_banner -benchmark -i test.jp2 -f null - 1.5 секунды vs 100 мс на десяти мегапикселях. FastStone Image Viewer задумывается на 3 секунды. А теперь перенесёмся в нулевые...
Ускорять платным декодером - спасибо. Ускорять с потерей качества - тоже (впрочем, ускоренное подмножество выделили в 2019 - HTJ2K).
Потом ещё был гугловский jpegli, который выше оценивали. Там и декодер доработанный, и опциональное улучшение в энкодере, завязанное на встраивание ICC-профиля.
Посмотрел свою последнюю ссылку - в небольшом тесте на 4 картинках с этой опциональной возможностью он бьёт вообще всех, кроме JXL. Наверное, потому что лишь 4 картинки и 1 метрика без субъективных сравнений и детального перебора настроек, но всё равно впечатляет.
Жанр народного негодования имеет право на жизнь, но ведь не всегда уместен.
Выше так же зря "на публику" спросили, почему формат картинок с поддержкой 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 (польза очевидна), использовали компонентный выход (раз уж есть, то тупо не использовать*), а проверять гипотезы насчёт композита в конце этого длинного пути уже никому не захочется.
Только его можно очень по-разному оверселлить. Всегда удивляли американские истории про 1.2 ТБ на месяц. В худшем случае часа три интернета. А бэкап на пару терабайт только почтой.
Это 43 мегабита в среднем.
Хотя они же этого и добивались - 10 мкФ ради минимального импеданса на этой частоте, а не ради расширения полосы пропускания вниз?
The impedance of DC Block must be very low ... DC Blocks are usually capacitors with its self-resonant frequency near operating frequency - книжка.
Мне здесь компетенций не хватает, но что-то совсем не так. Конкретному решению (поставить параллельно керамику) нужна конкретная проблема, а если опасаться чего-то неопределённого, то
это плохо кончитсязачем оставлять электролит?Если опасаться чего-то неопределённого на резонансной частоте конденсатора или за ней, то это вопрос не к электролиту, а к большому номиналу, который выбрали в vhs-decode. Они советуют 10 мкФ керамикой, у которой резонанс будет на 2-4 МГц - в полосе VHS.
+ Про фортран (поведение похоже на D) и дотнет (похоже на GCC, но лучше документировано): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0078r0.pdf#page=5
Тогда не стоит его называть
[[gnu::pure]]- этот атрибут не про гарантии от компилятора для программиста*, а наоборот - программист обещает компилятору, что функция чистая:In short, you shouldn't be saying it's pure or const if it's not pure or const
...
if the user is marking trivial functions const or pure when they clearly aren't, they deserve what they get :).
...
attributes are meant for when you are sure you know more than the compiler can tell - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
Нормальные люди переименовали бы его в
[[gnu::assume_pure]]...____
* что-то такое было в D: https://dlang.org/spec/function.html#pure-functions
Нет, некоторые считают, что кроличья нора должна быть глубже.
"2. tapping RF off of pickup rather than internal RF test point (avoids 90s era amplification circuitry)" - forum.lddb (это про аналогичный проект с лазердисками).
Что? Мы словно с передачи RF-сигнала на импульсные БП перескочили. Там бы керамика была ultra-low-ESR/ESL дополнением к электролиту, а здесь зачем?
Как я понимаю, здесь конденсатор - это развязка по постоянному току на всякий случай. При этом закрываются глаза на согласование импедансов (=> отражения сигнала) и на поведение видеомагнитофона с этой дополнительной нагрузкой. Потому что и так неплохо работает. А если погружаются глубже, то переходят сразу к установке усилителя.
upd: Ещё BD пророчили более светлое будущее - в ~2014 стандартизировали* двусторонний BD-R на 200 ГБ с 3 слоями на сторону.
* White Paper - Blu-ray Disc Format - General - 4th Edition
Если это в виде совета переписать, будет так?
У нас здесь аналог пассивного щупа осциллографа (впрочем, несогласованного). И по тем же причинам, по которым в щупах "крокодил" земли меняют на короткую пружину, лучше максимально уменьшить расстояние (или площадь петли) как на картинке.
(заметки по теме: rohde-schwarz, stackexchange[1][2])
Картинки
Вообще начинание-то прекрасное и прекрасно, как vhs-decode снижает стоимость качественной оцифровки. И здесь нет никакого шок-контента, от которого могли бы кадры с полями в голове перепутаться (это к началу ветки).
Фракталы для сжатия - не знаю, в мейнстрим такое не попало (и даже вейвлеты после JPEG2000 - где они?).
Но зато сжатие для фракталов... то есть в JPEG XL есть мощный режим (в основном для lossless), с помощью которого можно фрактал нарисовать.
картинка
Ну, среди свободных / бесплатных знаю родной ffmpeg'овский (
-vcodec jpeg2000) и сторонний OpenJPEG (-vcodec libopenjpeg). Сторонний декодер был ещё медленнее и его удалили в 2023 в рамках решения оставлять только собственные декодеры их при наличии. Энкодер оставили.Документация пропитана презрением - родной энкодер более-менее задокументирован только на сайте, а сторонний, наоборот, там не упоминается и не имеет описания параметров в хелпе или исходниках.
В lossless-режиме по степени сжатия оба не обгоняют png (медленный пресет выставил бы, если бы его можно было настроить). Из одного крупного бенчмарка lossless-кодеков его выкинули, не впечатлившись результатами (какой именно кодек - не знаю, но явно не платный).
______
Про Motion JPEG 2000 - до этого знал только про применение в кино, его там в DCP используют.
У него видится фатальный недостаток.
ffmpeg у меня декодирует его в 15 раз медленнее, чем jpeg92.
ffmpeg -hide_banner -benchmark -i test.jp2 -f null -1.5 секунды vs 100 мс на десяти мегапикселях. FastStone Image Viewer задумывается на 3 секунды. А теперь перенесёмся в нулевые...
Ускорять платным декодером - спасибо. Ускорять с потерей качества - тоже (впрочем, ускоренное подмножество выделили в 2019 - HTJ2K).
Потом ещё был гугловский jpegli, который выше оценивали. Там и декодер доработанный, и опциональное улучшение в энкодере, завязанное на встраивание ICC-профиля.
Посмотрел свою последнюю ссылку - в небольшом тесте на 4 картинках с этой опциональной возможностью он бьёт вообще всех, кроме JXL. Наверное, потому что лишь 4 картинки и 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 (польза очевидна), использовали компонентный выход (раз уж есть, то тупо не использовать*), а проверять гипотезы насчёт композита в конце этого длинного пути уже никому не захочется.
* принцип не работает с лазердисками