Хозяйка канала @orientwitch сообщила, что въ нынѣшнемъ году сэцубун наступил на день раньше привычного дня — и что теперь таким будет каждый четвёртый год.
Telegram
Востоковедунья
Небольшое уточнение про даты: обычно Сэцубун отмечают 3 февраля, но в 2021 году, впервые за 124 года, его праздновали 2 февраля. Всё потому, что звезды так сложились астрономические расчёты показали более раннее наступление весны.
Теперь какое-то время в…
Теперь какое-то время в…
Forwarded from Рой Непроханов 🎭
Please open Telegram to view this post
VIEW IN TELEGRAM
what technology could you even teach the ancient greeks.png
742.9 KB
Вижу два готовых постскриптума к моему сообщению 12 ноября про близость античных людей к изобретению возможности записи звуков и изображений.
Первый постскриптум вот каков: на имиджборде 4chan появилося обсуждение вопроса о том, кто и чему смог бы научить античных греков, кабы чудом попал к ним. Гиперссылку на архивную копию (на сайте desuarchive) прилагаю, скриншот также прилагаю. Любопытно то, что идея записи звуков или изображений, насколько я мог замѣтить, не упоминалася в этом обсуждении.
Второй постскриптум вот каков: на канале @hellenistics обнаружился пересказанным анекдот о том, что в Древнем Риме никоим образом не могли бы изобрести фонограф — но потому только, что вмѣсто него могли бы изобрести соноскриптор.
Первый постскриптум вот каков: на имиджборде 4chan появилося обсуждение вопроса о том, кто и чему смог бы научить античных греков, кабы чудом попал к ним. Гиперссылку на архивную копию (на сайте desuarchive) прилагаю, скриншот также прилагаю. Любопытно то, что идея записи звуков или изображений, насколько я мог замѣтить, не упоминалася в этом обсуждении.
Второй постскриптум вот каков: на канале @hellenistics обнаружился пересказанным анекдот о том, что в Древнем Риме никоим образом не могли бы изобрести фонограф — но потому только, что вмѣсто него могли бы изобрести соноскриптор.
new libavif.png
469.1 KB
Самым значимым событием из числа впрямую касающихся хранения изображений сдѣлалося нынѣшнею зимою появление новой версии пакета приложений libavif, служащего для работы с файлами в формате AVIF.
В этой новой версии (вышедшей 25 февраля под номером 1.2.0; здѣсь можно прибавить, что 17 марта появилась болѣе новая версия 1.2.1, незначительно дополняющая предшественницу) можно было сразу замѣтить (и я замѣтилъ анонимно на 410чане 26 февраля, а на канале в Телеграме прилагаю скриншот чуть выше) четыре новинки:
① Кодировщик теперь может создавать изображения въ цвѣтовомъ пространствѣ YCgCo-R, обеспечивая небольшой рост экономии при таком сжатии файлов, которое совершается без внесения потерь в изображение. Технически это достигается параметром «--cicp 1/13/16» в командной строке (или другим аналогичным, но также непремѣнно с шестнадцатыми матричными коэффициентами). Но здѣсь есть сразу два малоприятных нюанса.
Первый малоприятный нюанс вот каков: я пишу «небольшой рост экономии» оттого, что получающийся файл AVIF может всё ещё получаться больше файла PNG с точно тѣми же пикселами (то есть экономия всё ещё не достаточно значительна для того, чтобы превратить малоэффективное сжатие в высокоэффективное во всѣхъ случаях).
Второй малоприятный нюанс вот каков: новинка YCgCo-R, именно в силу своей новизны, не способна корректно восприниматься декодировщиками из предшествующих версий пакета libavif — поэтому, напримѣръ, во всѣхъ существующих web-браузерах цвѣта таких AVIF показаны будут некорректно.
Можно, конечно, полагаться на то, что со временем декодировщики для YCgCo-R появятся и в программах просмотра изображений, и в web-браузерах.
С другой стороны, ужé сейчас очень понятно, что въ нѣкоторыхъ частных случаях такое никогда не сдѣлается возможным. Примѣромъ может служить система Windows 7, поддержка которой прекращается, так что для неё и новые версии браузеров не выпускают. Для этого примѣра нѣкоторымъ исключением можно назвать разве что браузер Mozilla Firefox, но и его производители ограничилися под Windows 7 одним только латанием дыр безопасности, обнаруживаемых в достаточно старой версии этого браузера (в Firefox 115) — да и это всего только до сентября 2025 г.:
В этой новой версии (вышедшей 25 февраля под номером 1.2.0; здѣсь можно прибавить, что 17 марта появилась болѣе новая версия 1.2.1, незначительно дополняющая предшественницу) можно было сразу замѣтить (и я замѣтилъ анонимно на 410чане 26 февраля, а на канале в Телеграме прилагаю скриншот чуть выше) четыре новинки:
① Кодировщик теперь может создавать изображения въ цвѣтовомъ пространствѣ YCgCo-R, обеспечивая небольшой рост экономии при таком сжатии файлов, которое совершается без внесения потерь в изображение. Технически это достигается параметром «--cicp 1/13/16» в командной строке (или другим аналогичным, но также непремѣнно с шестнадцатыми матричными коэффициентами). Но здѣсь есть сразу два малоприятных нюанса.
Первый малоприятный нюанс вот каков: я пишу «небольшой рост экономии» оттого, что получающийся файл AVIF может всё ещё получаться больше файла PNG с точно тѣми же пикселами (то есть экономия всё ещё не достаточно значительна для того, чтобы превратить малоэффективное сжатие в высокоэффективное во всѣхъ случаях).
Второй малоприятный нюанс вот каков: новинка YCgCo-R, именно в силу своей новизны, не способна корректно восприниматься декодировщиками из предшествующих версий пакета libavif — поэтому, напримѣръ, во всѣхъ существующих web-браузерах цвѣта таких AVIF показаны будут некорректно.
Можно, конечно, полагаться на то, что со временем декодировщики для YCgCo-R появятся и в программах просмотра изображений, и в web-браузерах.
С другой стороны, ужé сейчас очень понятно, что въ нѣкоторыхъ частных случаях такое никогда не сдѣлается возможным. Примѣромъ может служить система Windows 7, поддержка которой прекращается, так что для неё и новые версии браузеров не выпускают. Для этого примѣра нѣкоторымъ исключением можно назвать разве что браузер Mozilla Firefox, но и его производители ограничилися под Windows 7 одним только латанием дыр безопасности, обнаруживаемых в достаточно старой версии этого браузера (в Firefox 115) — да и это всего только до сентября 2025 г.:
Firefox_ESR_schedule_with_its_EOL_on_Windows_7_in_September_2025.png
95.3 KB
② В командной строке у кодировщика AVIF вмѣсто прежних параметров «--minalpha 0 --maxalpha 0» можно и нужно теперь использовать единственный параметр «--qalpha 100» для принуждения кодировщика к использованию наивысшаго качества при сохранении свѣдѣній о прозрачности.
③ Появилась аналогичная возможность указывать баллы качества (от нуля до сотни; чѣмъ больше баллов, тѣмъ качество выше), а не значение квантизатора (от нуля до 63; чѣмъ больше это значение, тѣмъ качество меньше) и для свѣдѣніяхъ о самих пикселах (а не об их прозрачности), для чего служит в командной строке параметр «-qcolor»; но я предпочитаю не пользоваться этой новой возможностью, а по-прежнему задавать квантизатор («--advanced cq-level=…»), так как «под капотом» («за кулисами») баллы качества всё равно переводятся в величину квантизатора — и так как сто баллов больше 63, так что въ нѣкоторыхъ частных случаях (которых больше тридцати штук) измѣненіе качества на единицу не перемѣняетъ результат кодирования (и тогда на практике получается, что зря кодировал на пробу сосѣднее число баллов качества), что неудобно и досадно.
④ Появился новый вариант настройки кодировщика («--advanced tune=iq»), который способствует наращиванию качества картинки при небольшом сжатии, способствуя большему вниманию кодировщика к сохранению и незамутнению тонких деталей изображения, причём «под капотом» («за кулисами») включение этой настройки переключает дефолтное (установленное по умолчанию) состояние ещё восьми других настроек:
Я принялся экспериментировать с настройками libavif и в итоге необычно увлёкся: въ послѣдніе полтора мѣсяца много меньше удѣлялъ внимание своему каналу в Телеграме (и даже нѣсколько отвык), а больше внимания — тому внѣтелеграмному сообществу, на сайте которого выкладывал AVIF.
В итоге я пришёл к двум выводам.
Первый вывод состоит в том, что если в формате AVIF сохраняется изображение, уменьшенное по отношению къ нѣкоторому исходному JPEG, то выгодно (для лучшаго соѿношенія объёма и качества итогового файла) сперва подавить шум JPEG (используя JPEG Quant Smooth Ильи Курдюкова), затѣмъ декодировать JPEG с высокою (шестнадцатибитною) точностью (используя декодировщик jpegli с параметром «--bitdepth=16»), и вот тогда уж совершать и уменьшение изображения, и послѣдующее создание AVIF.
Второй вывод состоит в том, что зависимость объёма файла AVIF от матрицы квантизации в режиме «tune=iq» представляет собою двойную S-образную кривую. Если начинать от максимума (qm-min=15 и qm-max=15) и постепенно понижать qm-min до нуля, то сперва объём файла не сокращается и даже слегка возрастает, затѣмъ начинает быстро сокращаться, затѣмъ сокращается всё хуже (и часто значения qm-min, близкие к нулю, дают ровно такой же объём файла AVIF, какой был бы и при «qm-min=0», или даже чуть меньший). Если затѣмъ от этой точки (qm-min=0 и qm-max=15) уменьшать значение qm-max, то сперва объём файла сокращается слабо (или вовсе остаётся неизмѣннымъ), затѣмъ сильно, затѣмъ снова слабо.
Вторая S-образная кривая (достигаемая уменьшением qm-max при ужé обнулённом qm-min) появляется только в режиме «tune=iq», без которого эта кривая не возникает и уменьшать qm-max бесполезно. Но и в режиме «tune=iq» уменьшать qm-max бесполезно, потому что наблюдаемое качество изображения ухудшается так сильно, что тот же объём файла выгодно достигать другими средствами, а именно наращиванием квантизатора.
Поэтому в итоге я счёл значения матриц квантизации по умолчанию, в режиме «tune=iq» задаваемые (qm-min=2 и qm-max=10), практически не очень полезными. Если подгонять файл AVIF подъ нѣкоторое ограничение объёма, то лучше сперва найти минимальное значение квантизатора такое, при котором объём файла AVIF меньше ограничения при qm-min=0 и qm-max=15, а затѣмъ (для болѣе точнаго приближения к ограничению) повысить qm-min до 12 (что увеличит объём файла) и затѣмъ раз за разом уменьшать qm-min на единицу до тѣхъ поръ, пока объём файла AVIF не начнёт вдругорядь соѿвѣтствовать ограничению.
③ Появилась аналогичная возможность указывать баллы качества (от нуля до сотни; чѣмъ больше баллов, тѣмъ качество выше), а не значение квантизатора (от нуля до 63; чѣмъ больше это значение, тѣмъ качество меньше) и для свѣдѣніяхъ о самих пикселах (а не об их прозрачности), для чего служит в командной строке параметр «-qcolor»; но я предпочитаю не пользоваться этой новой возможностью, а по-прежнему задавать квантизатор («--advanced cq-level=…»), так как «под капотом» («за кулисами») баллы качества всё равно переводятся в величину квантизатора — и так как сто баллов больше 63, так что въ нѣкоторыхъ частных случаях (которых больше тридцати штук) измѣненіе качества на единицу не перемѣняетъ результат кодирования (и тогда на практике получается, что зря кодировал на пробу сосѣднее число баллов качества), что неудобно и досадно.
④ Появился новый вариант настройки кодировщика («--advanced tune=iq»), который способствует наращиванию качества картинки при небольшом сжатии, способствуя большему вниманию кодировщика к сохранению и незамутнению тонких деталей изображения, причём «под капотом» («за кулисами») включение этой настройки переключает дефолтное (установленное по умолчанию) состояние ещё восьми других настроек:
enable-qm=1
qm-min=2
qm-max=10
sharpness=7
dist-metric=qm-psnr
enable-cdef=3
enable-chroma-deltaq=1
deltaq-mode=6
Я принялся экспериментировать с настройками libavif и в итоге необычно увлёкся: въ послѣдніе полтора мѣсяца много меньше удѣлялъ внимание своему каналу в Телеграме (и даже нѣсколько отвык), а больше внимания — тому внѣтелеграмному сообществу, на сайте которого выкладывал AVIF.
В итоге я пришёл к двум выводам.
Первый вывод состоит в том, что если в формате AVIF сохраняется изображение, уменьшенное по отношению къ нѣкоторому исходному JPEG, то выгодно (для лучшаго соѿношенія объёма и качества итогового файла) сперва подавить шум JPEG (используя JPEG Quant Smooth Ильи Курдюкова), затѣмъ декодировать JPEG с высокою (шестнадцатибитною) точностью (используя декодировщик jpegli с параметром «--bitdepth=16»), и вот тогда уж совершать и уменьшение изображения, и послѣдующее создание AVIF.
Второй вывод состоит в том, что зависимость объёма файла AVIF от матрицы квантизации в режиме «tune=iq» представляет собою двойную S-образную кривую. Если начинать от максимума (qm-min=15 и qm-max=15) и постепенно понижать qm-min до нуля, то сперва объём файла не сокращается и даже слегка возрастает, затѣмъ начинает быстро сокращаться, затѣмъ сокращается всё хуже (и часто значения qm-min, близкие к нулю, дают ровно такой же объём файла AVIF, какой был бы и при «qm-min=0», или даже чуть меньший). Если затѣмъ от этой точки (qm-min=0 и qm-max=15) уменьшать значение qm-max, то сперва объём файла сокращается слабо (или вовсе остаётся неизмѣннымъ), затѣмъ сильно, затѣмъ снова слабо.
Вторая S-образная кривая (достигаемая уменьшением qm-max при ужé обнулённом qm-min) появляется только в режиме «tune=iq», без которого эта кривая не возникает и уменьшать qm-max бесполезно. Но и в режиме «tune=iq» уменьшать qm-max бесполезно, потому что наблюдаемое качество изображения ухудшается так сильно, что тот же объём файла выгодно достигать другими средствами, а именно наращиванием квантизатора.
Поэтому в итоге я счёл значения матриц квантизации по умолчанию, в режиме «tune=iq» задаваемые (qm-min=2 и qm-max=10), практически не очень полезными. Если подгонять файл AVIF подъ нѣкоторое ограничение объёма, то лучше сперва найти минимальное значение квантизатора такое, при котором объём файла AVIF меньше ограничения при qm-min=0 и qm-max=15, а затѣмъ (для болѣе точнаго приближения к ограничению) повысить qm-min до 12 (что увеличит объём файла) и затѣмъ раз за разом уменьшать qm-min на единицу до тѣхъ поръ, пока объём файла AVIF не начнёт вдругорядь соѿвѣтствовать ограничению.
IMG_20250419_210642_853.jpg
3.7 MB
Христосъ воскресе!
Прилагаю монограмму «ХВ», которую обнаружил нанесённою на тротуар улицы Тельмана в Геленджике.
#Геленджик
Прилагаю монограмму «ХВ», которую обнаружил нанесённою на тротуар улицы Тельмана в Геленджике.
#Геленджик
countCharacters.jsee
1016 B
Чаще всего я выкладываю у себя на канале в Телеграме сообщения немалого размѣра, но в этом мнѣ всегда неслабо досаждало и мѣшало одно обстоятельство: Telegram начинает показывать подсчитанное им количество использованных сѵмволовъ только тогда, когда их ужé многовато в сообщении, подвергаемом редактированию. (Если же сообщение не подвергается редактированию, а набирается заново, то тогда Telegram и вовсе не начинает считать количество использованных сѵмволовъ даже тогда, когда их ужé многовато в сообщении, а тупо откусывает от сообщения его хвост и кладёт въ ѿдѣльномъ слѣдующемъ сообщении.) Очень трудно заранѣе «на глаз» угадывать, сколько сѵмволовъ осталось ввести до того момента, когда достигнет будет телеграмный лимит длины сообщения (4096 сѵмволовъ).
Можно, конечно, заблаговременно ввести какую-нибудь строку извѣстной длины — напримѣръ, повторение раз за разом «123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789» содержит по десять сѵмволовъ для каждой группы цифр, если считать группу съ послѣдующимъ пробѣломъ (как считает их и сам Telegram), так что этот примѣръ строки содержит 99 сѵмволовъ. Если начать сообщение с такой строки и затѣмъ набирать текст под нею, то перевод строки станет сотым сѵмволомъ и Telegram начнёт браниться на чрезмѣрность числа сѵмволовъ на сотню ранѣе. Но у искусственной многочисленности сѵмволовъ есть свои недостатки (напримѣръ, она препятствует отправке сообщения в Telegram ничуть не хуже, чѣмъ созданная не искусственно).
Ещё можно набирать сообщение не в Телеграме, а в текстовом редакторе, из которого затѣмъ копировать в Telegram. В большинстве таких редакторов под окном ввода текста есть строка состояния, в которой показывается номер столбца, нарастающий по мѣрѣ ввода текста в строке — можно номером столбца пользоваться как индикатором длины текста. Но у этого подхода три недостатка:
➊ В отличие от редакторов «документов» (таких редакторов, каковы и LibreOffice Writer, и Microsoft Word), редакторы «просто текста» (такие, как EmEditor или Notepad++) не способны сохранять оформление текста. Приходится заранѣе составлять параллельный список таких словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
➋ Нѣкоторые редакторы текста (напримѣръ, EmEditor) норовят при подсчёте номера столбца считать один сѵмволъ за два, если мнят его сѵмволомъ повышенной ширины. Таковы и иероглифы (напримѣръ, «魔»), и числа в кружкáх (напримѣръ, «⑪»), и многие эмоджи (напримѣръ, «🪗»), и проч. А вот Telegram с такими сѵмволами так не поступает (и правильно, а не то нам пришлось бы ещё сильнѣе экономить их в Телеграме) — значит, номер столбца в редакторе текста перестаёт быть годным аналогом телеграмнаго подсчёта сѵмволовъ.
➌ Номер столбца показывает количество текста в одной строке. Чтобы измѣрить количество текста во всём сообщении, нужно либо хорошо владѣть устным счётом четырёхзначных чисел (быстро складывать в уме всѣ номера послѣднихъ столбцовъ, сперва посмотрѣвъ ихъ в каждой из непустых строк), либо составлять всё сообщение как одну большую длинную строку, а планируемыя пустыя строки помѣчать двойным неиспользуемым сѵмволомъ (напримѣръ, «··»), замѣняя его двойным переходом на новую строку перед окончательным копированием сообщения внутрь Телеграма.
В конце концов я подзадолбался и вспомнил, что EmEditor — это скриптуемый текстовый редактор: в нём можно запускать скрипты (правда, в нём они зовутся не скриптами, а макросами, но это не принципиально) и взаимодѣйствовать с объектною моделью документа.
Вспомнив это, я сочинил для EmEditor (и прилагаю здѣсь) макрос подсчёта числа сѵмволовъ внутри выдѣленнаго текста, а если ничего не выдѣлено — то от курсора до начала файла. А почему не от начала до конца файла? — потому, что черновик может содержать наброски нѣсколькихъ сообщений или (как я это ужé упоминал чуть выше) список словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
Можно, конечно, заблаговременно ввести какую-нибудь строку извѣстной длины — напримѣръ, повторение раз за разом «123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789» содержит по десять сѵмволовъ для каждой группы цифр, если считать группу съ послѣдующимъ пробѣломъ (как считает их и сам Telegram), так что этот примѣръ строки содержит 99 сѵмволовъ. Если начать сообщение с такой строки и затѣмъ набирать текст под нею, то перевод строки станет сотым сѵмволомъ и Telegram начнёт браниться на чрезмѣрность числа сѵмволовъ на сотню ранѣе. Но у искусственной многочисленности сѵмволовъ есть свои недостатки (напримѣръ, она препятствует отправке сообщения в Telegram ничуть не хуже, чѣмъ созданная не искусственно).
Ещё можно набирать сообщение не в Телеграме, а в текстовом редакторе, из которого затѣмъ копировать в Telegram. В большинстве таких редакторов под окном ввода текста есть строка состояния, в которой показывается номер столбца, нарастающий по мѣрѣ ввода текста в строке — можно номером столбца пользоваться как индикатором длины текста. Но у этого подхода три недостатка:
➊ В отличие от редакторов «документов» (таких редакторов, каковы и LibreOffice Writer, и Microsoft Word), редакторы «просто текста» (такие, как EmEditor или Notepad++) не способны сохранять оформление текста. Приходится заранѣе составлять параллельный список таких словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
➋ Нѣкоторые редакторы текста (напримѣръ, EmEditor) норовят при подсчёте номера столбца считать один сѵмволъ за два, если мнят его сѵмволомъ повышенной ширины. Таковы и иероглифы (напримѣръ, «魔»), и числа в кружкáх (напримѣръ, «⑪»), и многие эмоджи (напримѣръ, «🪗»), и проч. А вот Telegram с такими сѵмволами так не поступает (и правильно, а не то нам пришлось бы ещё сильнѣе экономить их в Телеграме) — значит, номер столбца в редакторе текста перестаёт быть годным аналогом телеграмнаго подсчёта сѵмволовъ.
➌ Номер столбца показывает количество текста в одной строке. Чтобы измѣрить количество текста во всём сообщении, нужно либо хорошо владѣть устным счётом четырёхзначных чисел (быстро складывать в уме всѣ номера послѣднихъ столбцовъ, сперва посмотрѣвъ ихъ в каждой из непустых строк), либо составлять всё сообщение как одну большую длинную строку, а планируемыя пустыя строки помѣчать двойным неиспользуемым сѵмволомъ (напримѣръ, «··»), замѣняя его двойным переходом на новую строку перед окончательным копированием сообщения внутрь Телеграма.
В конце концов я подзадолбался и вспомнил, что EmEditor — это скриптуемый текстовый редактор: в нём можно запускать скрипты (правда, в нём они зовутся не скриптами, а макросами, но это не принципиально) и взаимодѣйствовать с объектною моделью документа.
Вспомнив это, я сочинил для EmEditor (и прилагаю здѣсь) макрос подсчёта числа сѵмволовъ внутри выдѣленнаго текста, а если ничего не выдѣлено — то от курсора до начала файла. А почему не от начала до конца файла? — потому, что черновик может содержать наброски нѣсколькихъ сообщений или (как я это ужé упоминал чуть выше) список словосочетаний, которые потóм (послѣ копирования текста внутрь Телеграма) захочется сдѣлать жирными, курсивными, подспойлерными, гиперссылками, etc.
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
В программировании словом «флаг» иногда называют двоичную перемѣнную, сигнализирующую только одно из двух состояний какого-нибудь процесса (истинно или ложно? — открыто или закрыто? — включено или выключено? — равно или не равно? — переполнено или не переполнено? — и такъ далѣе).
От программистов эта метафора была позаимствована авторами таких визуальных романов, сюжет которых сочиняется в качестве развѣтвлённаго — и позаимствована потому, что их авторы нерѣдко принуждены совмѣщать роль драматурга (по отношению к сюжету) с ролью программиста, ведущего учёт того, достиг ли центральный персонаж исполнения того или иного условия, запускающего ту или иную вѣтвь дальнѣйшаго развития сюжета. Въ наиболѣе простых случаях такое условие также оказывается двоичным «флагом», то есть персонажу достаточно единожды что-нибудь правильно сдѣлать или сказать для того, чтобы выйти на желаемую ветвь сюжета. Вѣрно и обратное: въ наиболѣе простых случаях центральному персонажу визуального романа достаточно единожды что-нибудь неправильно сдѣлать или сказать для того, чтобы наступил преждевременный финал («BAD END»).
Дальше эта терминология ушла в жаргон анимешников и начала употребляться там по отношению к обстоятельствам так называемого реальнаго міра: в такой ситуации, в которой совѣтскому человѣку чрезмѣрное нагромождение оптимистических утверждений о личном будущем показалось бы опасностью «сглазить», анимешник заговорит про «флаг смерти», подразумевая при этом, что чрезмѣрное нагромождение оптимистических утверждений о личном будущем слишком похоже на художественный троп «знаменитыя послѣднія слова». В качестве хороших примѣровъ такого «поднятия флагов смерти», причём примѣровъ взятых из #аниме же, я могу процитировать диалог на дѣтской горке (на игровой площадке) из «Chuunibyou demo Koi ga Shitai!» или тот риторический приём, при помощи которого Курусу Кимихито в «Monster Musume no Iru Nichijou» демонстрирует, что дѣвушка-дюллахан не является настоящею посланницею смерти. (Двѣ видеоцитаты прилагаю.)
В рамках той же метафоры «флагом любви» называется состояние влюблённости, а водрузившим этот флаг называют то конкретное дѣйствіе, которым порождена была приязнь дѣвушки. Напримѣръ, в сюжете того же «Chuunibyou demo Koi ga Shitai!» таким флагом почти назван случайный поцѣлуй ночью на палубе прогулочного судна. (Видеоцитату прилагаю.)
Развитием этой метафоры стало её овеществление: центральный персонаж аниме «Kanojo ga Flag wo Oraretara» показан способным видѣть флаги над головою других персонажей (прежде всего — персонажиц) и стремится своими дѣйствіями управлять их состоянием (прежде всего — предотвращать смерть). Ѿдѣльно ѿмѣчу, что флаги эти показаны не одинаковыми, а разнообразными, отражая индивидуальность персонажиц, примѣромъ чего могут служить их образы из эндинга этого аниме. (Видеоцитату прилагаю.)
Примѣромъ сходного стремления порушить сюжетные «флаги смерти», однако без сверхспособности видѣть эти флаги своими глазами (так что они остаются всего только удобною метафорою, выражающею предзнание вѣтвей сюжета), может служить то, какъ дѣйствовала Катарина Клаэс — «благородная злодѣйка» （悪役令嬢） из аниме «Хамэфура» и экранизируемого им первоисточника, популярность которого в Японии привела к появлению самой настоящей моды на произведения о «благородныхъ злодѣйкахъ», причём мода эта не ослабла до сих пор. От неудач жизненного сюжета Катарина спасает прежде всего саму себя (оно и понятно: ей грозит в будущем изгнание или смерть, если Катарина, движимая ревностью и сословною неприязнью, начнёт злодѣйствовать по отношению к сопернице недворянского происхождения), но ужé в финале первой серии (видеоцитату прилагаю) Катарина показана готовою перемѣнить к лучшему жизненный путь приёмного младшего брата-чародея, предначертанный сюжетом (этот бѣдняга, сознавая неспособность руководить собственною волшебною силою, всерьёз опасался кого-нибудь ненароком укокошить и сызмальства рѣшился было впредь вести жизнь затворника-хикикомори) — и готовою несмотря на то, что сперва Катарина воспринимала этого братика как часть собственнаго «флага смерти».
От программистов эта метафора была позаимствована авторами таких визуальных романов, сюжет которых сочиняется в качестве развѣтвлённаго — и позаимствована потому, что их авторы нерѣдко принуждены совмѣщать роль драматурга (по отношению к сюжету) с ролью программиста, ведущего учёт того, достиг ли центральный персонаж исполнения того или иного условия, запускающего ту или иную вѣтвь дальнѣйшаго развития сюжета. Въ наиболѣе простых случаях такое условие также оказывается двоичным «флагом», то есть персонажу достаточно единожды что-нибудь правильно сдѣлать или сказать для того, чтобы выйти на желаемую ветвь сюжета. Вѣрно и обратное: въ наиболѣе простых случаях центральному персонажу визуального романа достаточно единожды что-нибудь неправильно сдѣлать или сказать для того, чтобы наступил преждевременный финал («BAD END»).
Дальше эта терминология ушла в жаргон анимешников и начала употребляться там по отношению к обстоятельствам так называемого реальнаго міра: в такой ситуации, в которой совѣтскому человѣку чрезмѣрное нагромождение оптимистических утверждений о личном будущем показалось бы опасностью «сглазить», анимешник заговорит про «флаг смерти», подразумевая при этом, что чрезмѣрное нагромождение оптимистических утверждений о личном будущем слишком похоже на художественный троп «знаменитыя послѣднія слова». В качестве хороших примѣровъ такого «поднятия флагов смерти», причём примѣровъ взятых из #аниме же, я могу процитировать диалог на дѣтской горке (на игровой площадке) из «Chuunibyou demo Koi ga Shitai!» или тот риторический приём, при помощи которого Курусу Кимихито в «Monster Musume no Iru Nichijou» демонстрирует, что дѣвушка-дюллахан не является настоящею посланницею смерти. (Двѣ видеоцитаты прилагаю.)
В рамках той же метафоры «флагом любви» называется состояние влюблённости, а водрузившим этот флаг называют то конкретное дѣйствіе, которым порождена была приязнь дѣвушки. Напримѣръ, в сюжете того же «Chuunibyou demo Koi ga Shitai!» таким флагом почти назван случайный поцѣлуй ночью на палубе прогулочного судна. (Видеоцитату прилагаю.)
Развитием этой метафоры стало её овеществление: центральный персонаж аниме «Kanojo ga Flag wo Oraretara» показан способным видѣть флаги над головою других персонажей (прежде всего — персонажиц) и стремится своими дѣйствіями управлять их состоянием (прежде всего — предотвращать смерть). Ѿдѣльно ѿмѣчу, что флаги эти показаны не одинаковыми, а разнообразными, отражая индивидуальность персонажиц, примѣромъ чего могут служить их образы из эндинга этого аниме. (Видеоцитату прилагаю.)
Примѣромъ сходного стремления порушить сюжетные «флаги смерти», однако без сверхспособности видѣть эти флаги своими глазами (так что они остаются всего только удобною метафорою, выражающею предзнание вѣтвей сюжета), может служить то, какъ дѣйствовала Катарина Клаэс — «благородная злодѣйка» （悪役令嬢） из аниме «Хамэфура» и экранизируемого им первоисточника, популярность которого в Японии привела к появлению самой настоящей моды на произведения о «благородныхъ злодѣйкахъ», причём мода эта не ослабла до сих пор. От неудач жизненного сюжета Катарина спасает прежде всего саму себя (оно и понятно: ей грозит в будущем изгнание или смерть, если Катарина, движимая ревностью и сословною неприязнью, начнёт злодѣйствовать по отношению к сопернице недворянского происхождения), но ужé в финале первой серии (видеоцитату прилагаю) Катарина показана готовою перемѣнить к лучшему жизненный путь приёмного младшего брата-чародея, предначертанный сюжетом (этот бѣдняга, сознавая неспособность руководить собственною волшебною силою, всерьёз опасался кого-нибудь ненароком укокошить и сызмальства рѣшился было впредь вести жизнь затворника-хикикомори) — и готовою несмотря на то, что сперва Катарина воспринимала этого братика как часть собственнаго «флага смерти».
О чём продолжать ↑ предшествующее сообщение в первую очередь?
Anonymous Poll
38%
О «благородныхъ злодѣйкахъ» в других японских произведениях
7%
Про намёк на «флаг» в сюжете «Oreimo»
13%
Про визуальную отсылку к визуальному роману «Fate/stay night», кратко показанную в аниме «Хамэфура»
42%
Если двоичный «флаг» — простѣйшій индикатор влюблённости персонажицы, то как выглядит болѣе сложный?
IMG_20250425_203144_532.jpg
3.1 MB
#Геленджик сегодня (25 апрѣля) продолжает быть прохладным (прямо сейчас +15°), идёт небольшой дождь.
Пользуясь влажностью, повылазили улитки. Фотографию улиток прилагаю.
Пользуясь влажностью, повылазили улитки. Фотографию улиток прилагаю.