Но менее точный, потому что определение Lightness заметно отличается от определения Y, яркость в итоге будет расти неравномерно или вообще местами убывать.
Но это ещё можно поправить без сложных спиралей под спойлером, если изобрести пространство HSY, как предлагает википедия: "more perceptually relevant alternative [to Lightness in HSL] is to use luma". Ну, не изобрести, а скопировать откуда-нибудь код преобразования HSY->RGB.
В готовых палитрах читаемость в оттенках серого обычно предусмотрена.
в которой при переводе в серый ... получается плавное нарастание серого от 0 до 255
Если именно с 0 и именно до 255, то ей придётся быть не цветной по краям - начинаться с чёрного и заканчиваться белым.
Если изобретать новую такую палитру, то - простой вариант - можно создавать её в HSL. Saturation = const*, Lightness пусть увеличивается с постоянным шагом, Hue = какая-нибудь функция от Lightness. Покрутить перед глазами на https://colorizer.org/, чтобы представить.
* или изменять так, чтобы минимальное значение было при Lightness = 0.5
Сложный вариант, о котором написал изначально
Я бы делал через не-целочисленный-YUV (который ещё YPbPr называют, не YCbCr). Y (яркость) - то же, что и картинка в оттенках серого (mono в твоём комменте). Y пусть идёт с постоянным шагом, а CbCr по кругу, получится спираль, затем перевести в RGB* и целые числа.
* на этом этапе можно случайно вылезти за пределы куба RGB (т.е. какой-то из каналов RGB вылезет за пределы 0..1). clip(R,0,1) исказит яркость, исправлять надо ещё на этапе YUV.
Мысленно добавить спираль, идущую снизу вверх Сечения RGB-"куба" при Y=const можно посмотреть здесь. Картинка отсюда.
Лампы можно оптимизировать из разных соображений, которые при взгляде со стороны не особо понятны. Мелкие неонки могут быть недостойны оптимизаций.
Если смотреть в литературу по неоновым вывескам, в люминофорных там аргон+ртуть или аргон+неон+ртуть и газ в первую очередь создаёт условия для ртути (грубо говоря, подогревает для поддержания нужного давления паров).
Что интересно - в цифровых индикаторах (nixie) те же неон+аргон+ртуть, но по другой причине. Небольшая добавка аргона даёт смесь Пеннинга. Ртуть почему-то уменьшает распыление катодов (об этом писала Burroughs - лидер в сфере газоразрядных индикаторов - в своих патентах и где-то ещё). И там не нужно гадать о наличии ртути, если её подают через ампулу, остающуюся в баллоне (кажется, в ИН-14 сверху, а в ИН-18 снизу и раскрывается пропусканием тока по двум дополнительным выводам).
Последние новости в 2023-2024 были о том, что под неё сделали библиотеку типа ленточной (стойки, роботы). И что Microsoft рассматривает её как облачную технологию - если доведёт до конца, то продавать будет не железо, а услугу.
Буду ворчать, потому что тут надуманы голограммы и их связь с хранением в стекле. IBM PDSS - не голограмма. Фотоплёнка с цифровыми данными, засвечиваемая электронным лучом. Project Silica - не голограмма. Стеклянная пластинка с гравировкой вокселей внутри. Остальная часть статьи - не связана с данными в толще стекла. Габор использовал фотопластинку (информация хранится в эмульсии, а стекло - это твёрдая подложка для неё), а экспериментальные диски из нулевых - полимерные.
О том и речь. Надо или объяснять, что обычная мера чистоты здесь не годится (как и метод для её определения - погнуть, послушать), или, может, вообще не спрашивать - ну что там за олово из сарая.
Если нужна чистота выше 99%, то за бортом ещё марки олова О3 и О4.
На безрыбье и ПОС-90 — О1 пч. Чистое олово, пищевое олово в народе - это в том числе ПОС-90. Он и хрустеть должен, пишут. Чип и Дип его продаёт как "Олово пищевое ПОС-90".
Деды на радиофорумах говорили что "низкочастотный сигнал детектируется на нелинейностях радиосхем".
Ну, это интуитивно можно понять. Пропускаем синусоиду через элемент с несимметричной ВАХ (в идеале нужен диод, но и хоть какая-нибудь асимметрия сойдёт), теперь полуволны у синусоиды не одинаковые и поэтому в её спектре появляется постоянная составляющая.
Если на входе не просто синусоида, а синусоида, умноженная на НЧ-синусоиду АМ-сигнал, то появляется не просто постоянная составляющая, а кое-как демодулированный (aka детектированный) сигнал (aka baseband-сигнал).
Синусоида может быть наводкой. Элемент теоретически может быть хоть плохим контактом*. Асимметрия в ВАХ может быть относительно не нулевого напряжения, а другой рабочей точки, надо только к синусоиде постоянное напряжение добавить.
---
Дуга от травинки звучит как в ионофоне, периодически нагревает воздух => воздух периодически расширяется => звуковые колебания. Если бы ток в обратном направлении охлаждал воздух, то получилось бы, наверное, не очень, но вселенная даёт нам "выпрямление" через P = I^2 * R.
---
* Что-то вспоминается история радио в чересчур поспешном пересказе, где предшественники диодов выглядят древней магией.
Великие люди прошлого обнаружили, что металлические опилки (или ряд из металлических шариков) под воздействием высокочастотных колебаний почему-то понижают своё сопротивление [за счёт сварки микроконтактов] и назвали получившийся прибор когерером, так родилось радио. Затем они добились приёма на слух, выяснив, что на слабых сигналах когерер способен работать без декогерирования (встряхивания) [за счёт нелинейности ВАХ контактов]. А потом человечество перешло к обычным диодам, потому что магией пользоваться неудобно.
Удачность там можно найти только в сравнении с другими способами (через fsutil, forfiles, certutil, robocopy), при которых обычно отваливается больше систем и могут создаваться временные файлы.
В принципе, WinME и старше можно отсеять, убеждаясь, что %COMSPEC% содержит путь именно к cmd.exe.
Wine (взял wine-5.0) совместимостью на уровне хаков не занимается и в скрипте останавливается на pause. Если бы он прошёл дальше, то - хорошая новость - его cmd.exe в нужном формате (Portable Executable) и - плохая новость - вместо традиционной DOS-заглушки в заголовке лежит текст "Wine placeholder DLL" и на 0x46 мы искомого байта не найдём.
Да уж, документация ведёт себя подозрительно ("extended asm or a mixture of basic asm and C code may appear to work..."). Но у меня avr-gcc не хочет ругаться на ISR_NAKED + C-код в ISR (C, C++, локально, на godbolt, на 5.4.0 .. 14.2.0).
naked. Этот атрибут говорит компилятору не создавать пролог и эпилог функции (которые у нас и занимают бо́льшую часть кода!), но взамен требует принести тело функции в жертву — написать ее на ассемблере.
Документация использует ISR_NAKED с сишным кодом. В другом месте она запрещает не только C, но и extended asm (с двоеточиями и операндами), который в статье использован.
Это про спецификацию X11, а точнее, XKB, а точнее, xkblib, которую соблюдают достаточно тщательно, чтобы было нельзя переключать раскладку по Ctrl/Alt+Shift по отпусканию клавиш.
То есть это не тот случай, когда проблема в разброде и шатании. Поведение стандартизировано. Если хотеть большей "единости" от линукса в этом вопросе, то тогда совсем нельзя будет обойти ограничение.
Ответ на мой вопрос в том, что качество может быть хуже, но так говорят про OPUS в файлах на любых битрейтах.
For file encoding, using a frame size larger than 20 ms will usually result in worse quality for the same bitrate because it constrains the encoder in the decisions it can make - https://wiki.xiph.org/OpusFAQ#What_frame_size_should_I_use?
О режимах: OPUS - это 2 кодека в одном, SILK для голоса на битрейтах около 8-16 kbps и CELT для музыки. И их одновременный гибрид (SILK для <8 кГц, CELT для >8 кГц) для качественного голоса (16-64 kbps).
На гитхабе xiph/opus говорят, что framing overhead ощутим в RTP, но не в файлах и "If your application is encoding low bitrate music to file, then the best frame size to use is 20 ms, not 60 ms, not 120 ms. Using larger frame sizes just concatenates 20 ms frames, but it prevents the encoder from making optimal decisions".
Всегда оставлять звук в изначальном lossy-формате, не перекодировать.
Не думая выбирать Opus, доверяя графику с их сайта, где он на всех битрейтах не хуже, чем... чем AAC-LC и HE-AACv1, судя по всему. К тому же ffmpeg к libopus даёт хороший интерфейс, а с доступом к лучшему энкодеру AAC от Apple есть сложности (может быть проще не через ffmpeg).
На битрейтах ниже 100kbps выбирать xHE-AAC, если имеется его поддержка и не волнует его огороженность. На графике в предыдущем пункте профиля xHE-AAC точно нет, а на низких битрейтах он лучше Opus'а (на 128kbps Opus и разные AAC примерно равны).
---
aac_low ... Аудио приемлемо звучит с битовой частотой 128k. aac_he ... Аудио приемлемо звучит с битовой частотой 64k. aac_he_v2 ... Аудио приемлемо звучит с битовой частотой 32k.
128kbps у AAC-LC оценивается как весьма хорошее качество, а остальные профили этот уровень дают на тех же 128kbps, лишь подтягивая качество на низких "явно непрозрачных" битрейтах и позволяя забраться без ушных кровотечений ещё пониже:
В случае с HE-AACv1 это можно так объяснить: HE-AACv1 = AAC-LC + Spectral Band Replication, который восстанавливает высокие частоты, а их выкидыванием энкодер занимается на низких битрейтах.
aac_he (4): High Efficiency AAC (HE-AAC) - Низкая совместимость
Но есть обратная совместимость с AAC-LC - информация об SBR проигнорируется и файл проиграется как обычный AAC-LC, без высоких частот.
А HE-AACv2 = AAC-LC + SBR + Parametric Stereo будет играться как моно AAC-LC. Тестовые файлы (первый HE-AACv1, второй HE-AACv2).
И раз я начал говорить про самый новый профиль: USAC в xHE-AAC не опирается на AAC-LC, обратной совместимости нет.
Размеры больше 20 мс интересны только при достаточно низких битовых частотах.
Но почему? Используем Opus не для реального времени => задержка декодирования не важна => выкручиваем на максимум ради качества, не углубляясь в величину выигрыша (5%?.. 1%?..).
Но менее точный, потому что определение Lightness заметно отличается от определения Y, яркость в итоге будет расти неравномерно или вообще местами убывать.
Но это ещё можно поправить без сложных спиралей под спойлером, если изобрести пространство HSY, как предлагает википедия: "more perceptually relevant alternative [to Lightness in HSL] is to use luma". Ну, не изобрести, а скопировать откуда-нибудь код преобразования HSY->RGB.
В готовых палитрах читаемость в оттенках серого обычно предусмотрена.
Если именно с 0 и именно до 255, то ей придётся быть не цветной по краям - начинаться с чёрного и заканчиваться белым.
Если изобретать новую такую палитру, то - простой вариант - можно создавать её в HSL. Saturation = const*, Lightness пусть увеличивается с постоянным шагом, Hue = какая-нибудь функция от Lightness. Покрутить перед глазами на https://colorizer.org/, чтобы представить.
* или изменять так, чтобы минимальное значение было при Lightness = 0.5
Сложный вариант, о котором написал изначально
Я бы делал через не-целочисленный-YUV (который ещё YPbPr называют, не YCbCr). Y (яркость) - то же, что и картинка в оттенках серого (mono в твоём комменте). Y пусть идёт с постоянным шагом, а CbCr по кругу, получится спираль, затем перевести в RGB* и целые числа.
* на этом этапе можно случайно вылезти за пределы куба RGB (т.е. какой-то из каналов RGB вылезет за пределы 0..1). clip(R,0,1) исказит яркость, исправлять надо ещё на этапе YUV.
Сечения RGB-"куба" при Y=const можно посмотреть здесь.
Картинка отсюда.
Одна компания смотрела на спектр люминофорных неонок: в зелёной у них неон, в синей неопределённые "noble gases and probably mercury".
Другая, продающая люминофорные неонки, говорит о них как о неон-аргоновых без ртути.
Любители на lighting-gallery.net много разного говорят.
Лампы можно оптимизировать из разных соображений, которые при взгляде со стороны не особо понятны. Мелкие неонки могут быть недостойны оптимизаций.
Если смотреть в литературу по неоновым вывескам, в люминофорных там аргон+ртуть или аргон+неон+ртуть и газ в первую очередь создаёт условия для ртути (грубо говоря, подогревает для поддержания нужного давления паров).
Что интересно - в цифровых индикаторах (nixie) те же неон+аргон+ртуть, но по другой причине. Небольшая добавка аргона даёт смесь Пеннинга. Ртуть почему-то уменьшает распыление катодов (об этом писала Burroughs - лидер в сфере газоразрядных индикаторов - в своих патентах и где-то ещё). И там не нужно гадать о наличии ртути, если её подают через ампулу, остающуюся в баллоне (кажется, в ИН-14 сверху, а в ИН-18 снизу и раскрывается пропусканием тока по двум дополнительным выводам).
Последние новости в 2023-2024 были о том, что под неё сделали библиотеку типа ленточной (стойки, роботы). И что Microsoft рассматривает её как облачную технологию - если доведёт до конца, то продавать будет не железо, а услугу.
Буду ворчать, потому что тут надуманы голограммы и их связь с хранением в стекле.
IBM PDSS - не голограмма. Фотоплёнка с цифровыми данными, засвечиваемая электронным лучом.
Project Silica - не голограмма. Стеклянная пластинка с гравировкой вокселей внутри.
Остальная часть статьи - не связана с данными в толще стекла. Габор использовал фотопластинку (информация хранится в эмульсии, а стекло - это твёрдая подложка для неё), а экспериментальные диски из нулевых - полимерные.
О том и речь. Надо или объяснять, что обычная мера чистоты здесь не годится (как и метод для её определения - погнуть, послушать), или, может, вообще не спрашивать - ну что там за олово из сарая.
Если нужна чистота выше 99%, то за бортом ещё марки олова О3 и О4.
На безрыбье и ПОС-90 — О1 пч.Чистое олово, пищевое олово в народе - это в том числе ПОС-90. Он и хрустеть должен, пишут. Чип и Дип его продаёт как "Олово пищевое ПОС-90".Я прошёл проверку на внимательность, что дальше? В этом месте автор незаметно съехал с усов на оловянную чуму. Усы состоят из бета-олова.
Если как-то притягивать другую фазу олова к статье, то в альфа-олово в одном эксперименте усы со временем на холоде превращаться не захотели.
Если отсортировать по возрастанию необъяснимости:
Телевизор
Электрическая дуга
(^~~~ легко объяснимо)
Лопата
Зубная пломба
(^~~~ ???)
Ну, это интуитивно можно понять. Пропускаем синусоиду через элемент с несимметричной ВАХ (в идеале нужен диод, но и хоть какая-нибудь асимметрия сойдёт), теперь полуволны у синусоиды не одинаковые и поэтому в её спектре появляется постоянная составляющая.
Если на входе не просто синусоида, а
синусоида, умноженная на НЧ-синусоидуАМ-сигнал, то появляется не просто постоянная составляющая, а кое-как демодулированный (aka детектированный) сигнал (aka baseband-сигнал).Синусоида может быть наводкой. Элемент теоретически может быть хоть плохим контактом*. Асимметрия в ВАХ может быть относительно не нулевого напряжения, а другой рабочей точки, надо только к синусоиде постоянное напряжение добавить.
---
Дуга от травинки звучит как в ионофоне, периодически нагревает воздух => воздух периодически расширяется => звуковые колебания. Если бы ток в обратном направлении охлаждал воздух, то получилось бы, наверное, не очень, но вселенная даёт нам "выпрямление" через P = I^2 * R.
---
* Что-то вспоминается история радио в чересчур поспешном пересказе, где предшественники диодов выглядят древней магией.
Великие люди прошлого обнаружили, что металлические опилки (или ряд из металлических шариков) под воздействием высокочастотных колебаний почему-то понижают своё сопротивление [за счёт сварки микроконтактов] и назвали получившийся прибор когерером, так родилось радио. Затем они добились приёма на слух, выяснив, что на слабых сигналах когерер способен работать без декогерирования (встряхивания) [за счёт нелинейности ВАХ контактов]. А потом человечество перешло к обычным диодам, потому что магией пользоваться неудобно.
ВАХ когерера и рабочая точка для примера.
Там объясняют нелинейность не только оксидами, но и нагревом микроконтактов. Всё-таки это магия.
Удачность там можно найти только в сравнении с другими способами (через fsutil, forfiles, certutil, robocopy), при которых обычно отваливается больше систем и могут создаваться временные файлы.
В принципе, WinME и старше можно отсеять, убеждаясь, что %COMSPEC% содержит путь именно к cmd.exe.
Wine (взял wine-5.0) совместимостью на уровне хаков не занимается и в скрипте останавливается на pause. Если бы он прошёл дальше, то - хорошая новость - его cmd.exe в нужном формате (Portable Executable) и - плохая новость - вместо традиционной DOS-заглушки в заголовке лежит текст "Wine placeholder DLL" и на 0x46 мы искомого байта не найдём.
На ARM-винде, наверное, тоже сломается.
/Moya-Oborona.
Даташит говорит, 5 тактов на вход в ISR + 5 тактов на выход.
Мирный советский светофор - друг мирного советского трактора.
Да уж, документация ведёт себя подозрительно ("extended asm or a mixture of basic asm and C code may appear to work..."). Но у меня avr-gcc не хочет ругаться на ISR_NAKED + C-код в ISR (C, C++, локально, на godbolt, на 5.4.0 .. 14.2.0).
https://godbolt.org/z/hvv6WPvbn
Ctrl+Shift+1 ещё можно (но в линуксах не пытался настроить).
Документация использует ISR_NAKED с сишным кодом. В другом месте она запрещает не только C, но и extended asm (с двоеточиями и операндами), который в статье использован.
Это про спецификацию X11, а точнее, XKB, а точнее, xkblib, которую соблюдают достаточно тщательно, чтобы было нельзя переключать раскладку по Ctrl/Alt+Shift по отпусканию клавиш.
То есть это не тот случай, когда проблема в разброде и шатании. Поведение стандартизировано. Если хотеть большей "единости" от линукса в этом вопросе, то тогда совсем нельзя будет обойти ограничение.
https://bugs.freedesktop.org/show_bug.cgi?id=865 (2004 год)
+@Hlad
+ предыдущее обсуждение в 2024 на хабре
Оно не дефолтное, но стандартное.
Ответ на мой вопрос в том, что качество может быть хуже, но так говорят про OPUS в файлах на любых битрейтах.
For file encoding, using a frame size larger than 20 ms will usually result in worse quality for the same bitrate because it constrains the encoder in the decisions it can make - https://wiki.xiph.org/OpusFAQ#What_frame_size_should_I_use?
Спецификация: режимы Hybrid и CELT-only не поддерживают размеры выше 20 мс - https://datatracker.ietf.org/doc/html/rfc6716#page-15
О режимах: OPUS - это 2 кодека в одном, SILK для голоса на битрейтах около 8-16 kbps и CELT для музыки. И их одновременный гибрид (SILK для <8 кГц, CELT для >8 кГц) для качественного голоса (16-64 kbps).
На гитхабе xiph/opus говорят, что framing overhead ощутим в RTP, но не в файлах и "If your application is encoding low bitrate music to file, then the best frame size to use is 20 ms, not 60 ms, not 120 ms. Using larger frame sizes just concatenates 20 ms frames, but it prevents the encoder from making optimal decisions".
Вижу 2 хороших варианта:
Всегда оставлять звук в изначальном lossy-формате, не перекодировать.
Не думая выбирать Opus, доверяя графику с их сайта, где он на всех битрейтах не хуже, чем... чем AAC-LC и HE-AACv1, судя по всему. К тому же ffmpeg к libopus даёт хороший интерфейс, а с доступом к лучшему энкодеру AAC от Apple есть сложности (может быть проще не через ffmpeg).
На битрейтах ниже 100kbps выбирать xHE-AAC, если имеется его поддержка и не волнует его огороженность. На графике в предыдущем пункте профиля xHE-AAC точно нет, а на низких битрейтах он лучше Opus'а (на 128kbps Opus и разные AAC примерно равны).
---
128kbps у AAC-LC оценивается как весьма хорошее качество, а остальные профили этот уровень дают на тех же 128kbps, лишь подтягивая качество на низких "явно непрозрачных" битрейтах и позволяя забраться без ушных кровотечений ещё пониже:
В случае с HE-AACv1 это можно так объяснить: HE-AACv1 = AAC-LC + Spectral Band Replication, который восстанавливает высокие частоты, а их выкидыванием энкодер занимается на низких битрейтах.
Но есть обратная совместимость с AAC-LC - информация об SBR проигнорируется и файл проиграется как обычный AAC-LC, без высоких частот.
А HE-AACv2 = AAC-LC + SBR + Parametric Stereo будет играться как моно AAC-LC. Тестовые файлы (первый HE-AACv1, второй HE-AACv2).
И раз я начал говорить про самый новый профиль: USAC в xHE-AAC не опирается на AAC-LC, обратной совместимости нет.
Но почему? Используем Opus не для реального времени => задержка декодирования не важна => выкручиваем на максимум ради качества, не углубляясь в величину выигрыша (5%?.. 1%?..).