Лучше удвоенный размер файлов за донаты. А ещё лучше сколько оплатил — столько загрузил. Ишь чо удумали, использовать Иичан как файлопомойку.

Предложение >>247990 в реализации окажется технически многократно сложнее (придётся дополнительно прикручивать индивидуальный учёт пожертвований, индивидуальное наложение ограничений), поэтому фигня.

Всего-то один столбик в базе и проверка значения.

>>247980
Емнип, у Ычана выделенный. То есть, нужно собрать столько донатов, чтобы хватило на много лет оплаты сервера.

А можно ипфс и принимать донаты постоянно активными нодами ичянек. Я не Мицгол.

Упрощение >>247993 чрезмерно.

Какое ещё «всего-то»?

В том столбике данные с неба возьмутся, что ли?

>>247994
Да десятилетий, чего уж там.

«Донаты» >>247995 можно принимать только от тебя и от Мицгола.

Ычан никогда не согласится на это.

Вообще никогда.

Ычан вообще на донаты, увеличение лимита файлов и другую лабуду согласится в лучшем случае через пару лет, но скорее никогда.

>>247999
Тогда почему от его лица предлагалось задонатить?

>>248000
Я что-то пропустил?

Думаю, что формулировка вопроса >>248000 имеет какое-то отношение к тому, что по адресу http://ii.yakuji.moe/d/res/244600.html встречаются выражения «за сервера не вам платить», «а спонсором Ычана стать не хочешь?» и подобные.

Сомневаюсь насчёт предположения в >>248002, поскольку автором первой реплики являлся я, однако с другой стороны, de facto я не являюсь ни Ычаном, ни даже его лицом, лишь опирался при формулировке той фразы на полученный долгими годами эмпирический опыт.

>>247995
Да не сделает она. Был, впрочем, написан некий скрипт... https://github.com/Kalaver/ii2ipfs

>>247998
Не только!

Предлагаю: совершите удвоение предельного размера файлов хотя бы на время эры Рэйва.

Через пару лет >>247999 будет неактуально.

Давайте чуть более основательно рассмотрим вопрос о том, какой предельный объём файла в a/ наиболее удобен на практике.

Мои слова подкреплены СТАТИСТИЧЕСКИМИ ДАННЫМИ!

Я исхожу из высокой вероятности того, что хайрезные подборки https://iichan.hk/hr/res/5671.html да и https://iichan.hk/hr/res/5699.html наполняются такими картинками, которые по объёму не могли поместиться в a/. Хорошо видно, что по своему объёму только картинка №5720 одна может считаться исключением из этого правила: только её публикатор мог свободно выбрать между разделами a/ и hr/ и предпочёл этот последний. Но размер этого исключения достаточно мал для того, чтобы вполне пренебречь им. Предлагаю так и поступить, зато повнимательнее рассмотреть все остальные картинки: сколько их, каковы они по объёму?

от 4096 до 5120 килобайтов — 34 шт.: №5671, №5672, №5676, №5678, №5679, №5685, №5686, №5689, №5696, №5697, №5698, №5703, №5704, №5705, №5711, №5712, №5714, №5716, №5717, №5718, №5722, №5723, №5725, №5726, №5728, №5729, №5732, №5734, №5735, №5736, №5737, №5740, №5748, №5749

от 5120 до 6144 килобайтов — 17 шт.: №5677, №5690, №5694, №5700, №5701, №5702, №5710, №5713, №5715, №5719, №5727, №5730, №5733, №5738, №5739, №5743, №5750

от 6144 до 7168 килобайтов — 6 шт.: №5675, №5684, №5687, №5709, №5731, №5742

от 7168 до 8192 килобайтов — 5 шт.: №5699, №5721, №5724, №5744, №5747

от 8192 до 9216 килобайтов — 1 шт.: №5752

от 9216 до 10240 килобайтов c 25 мая ни одной картинки, хотя ограничения hr/ такой размер также допускают.

Согласитесь, что всё это уж не догадки или домыслы, а строгий реализм более чем полусотни картинок почти за три месяца. Тут небезосновательность.

Более того: размеры подавляющего большинства этих файлов (большинства, по сути состоящего из сшивок кадров) — не отсебятина публикаторов, а прямое последствие содержания и динамизма самих же кадров того конкретного аниме, из которого сшивка происходит. Общее же их распределение — объективная характеристика современного аниме, «другого аниме у меня для вас нет».

И теперь об этом распределении нам можно ясно видеть два основных, важнейших факта:

во-первых, почти все эти картинки (все-все, кроме одной) могли бы поместиться в a/ при таком ограничении объёма, которое вдвое превосходило бы нынешнее;

во-вторых, больше половины этих картинок (34 из 63) могли бы поместиться в a/ при таком ограничении объёма, которое всего на 1 мегабайт превосходило бы нынешнее.

Тем самым тезис о достаточности удвоения ограничения статистически наглядно подкреплён.

Тем самым и тезис о статистически значимой благотворности 410чановского пятимегабайтового ограничения (по сравнению с Ычановским четырёхмегабайтовым) наглядно подкреплён.

>>248523

>Мои слова подкреплены СТАТИСТИЧЕСКИМИ ДАННЫМИ!

Воссмеялся.
А теперь посмотрим на настоящие статистические данные, которые следует учитывать при расчёте лимитов.
Типичный размер файла, используемый большинством пользователей в /a/ не достигает даже одного мегабайта (причём даже выходящих за 500 КБ файлов маловато). Оставшееся меньшинство крупных файлов чаще всего не превышает даже двух мегабайт. Отсюда простой вывод: лимит файлов в /a/ выставлен даже с запасом. Кто-то там (не вы, о вас ниже) всё-таки изредка упирается в лимит? Ну, на то он и лимит. Пусть использует /hr/.
А теперь о вас с вашими искусственно раздутыми файлами. Про ПНГ вам уже высказали там, а я также напомню, что большинство аниме на данный момент не производится с высотой кадра 1080, так что использование этого разрешения в качестве базы для ваших склеек ничем не оправдано. Настоящее разрешение конкретных аниме можно посмотреть в бложике http://anibin.blogspot.com/, например.

>>248529

> Воссмеялся.

> А теперь посмотрим на настоящие статистические данные, которые следует учитывать при расчёте лимитов.

> Типичный размер файла, используемый большинством пользователей в /a/

Как воссмеялись, так и продолжаете смеяться, понимаю.

Сейчас, например, рассказываете (на новый лад) анекдот про «интернетовский опрос показал, что 100% опрошенных пользуются Интернетом».

Да, 100% пользователей /a/ укладываются в лимит. Это и есть настоящие, неподдельные статистические данные, которые непременно следует учитывать. Не то что фальшивые.

Хороший, смешной анекдот.

> Типичный размер файла, используемый большинством пользователей в /a/ не достигает даже одного мегабайта (причём даже выходящих за 500 КБ файлов маловато). Оставшееся меньшинство крупных файлов чаще всего не превышает даже двух мегабайт.

Ну да, таковы свойства распределения файлов. Среди рассмотренных выше файлов из /hr/ также большинство (34 из 63) попадает в «первый мегабайт» (от 4 до 5 мегабайтов), из оставшегося меньшинства больше половины (17 из 29) попадает во «второй мегабайт» (от 5 до 6 мегабайтов).

> Отсюда простой вывод: лимит файлов в /a/ выставлен даже с запасом. Кто-то там (не вы, о вас ниже) всё-таки изредка упирается в лимит? Ну, на то он и лимит. Пусть использует /hr/.

Не, ну если задаться целью поддерживать простое большинство файлов, то тогда да, лимит с четырёхкратным запасом.

А какая доля файлов /a/ по объёму располагается между тремя и четырьмя мегабайтами? И что из этого следует?

> большинство аниме на данный момент не производится с высотой кадра 1080, так что использование этого разрешения в качестве базы для ваших склеек ничем не оправдано.

А почему важно то, каким оно производится? Разве аниме в формате «от производителя» (900p, 848p и проч.) сделалось для нас доступным широчайше?

Кажется, не сделалось. Массы зрителей принуждены выбирать только между апскейлом 1080p и даунскейлом 720p.

Просто среди зрителей иногда появляются такие, у которых личный вкус абсолютизируется до некоторой крайности: дескать, употребление апскейла ничем не оправдано (и оправдано никогда и никем быть не может, а уж мною особенно), зато употребление даунскейла давно и навечно оправдано всем добрым, всем хорошим, всем благим и всем пресвятым во всём свете, «I hereby swear that I shall be all the good in the world».

(Главное — не слишком удивляться, когда в ответ кое у кого начнёт созревать подобное https://bash.im/quote/400883 решение, а кое у кого и созреет.)

Терпеливо напоминаю дежурный контраргумент из всех подобных дискуссий: апскейл (если он предшествует видеокодированию) создаёт информационную избыточность, способную частично компенсировать последующий процесс цветовой субдискретизации — даунскейл же означает, что https://ru.wikipedia.org/wiki/Цветовая_субдискретизация#4:2:0 убивает 50% данных об исходных пикселах невозвратно.

(Впрочем, нетрудно догадываться, что этот контраргумент — ничто, потому что использование апскейла не оправдывается ничем и никогда.)

> Настоящее разрешение конкретных аниме можно посмотреть в бложике http://anibin.blogspot.com/, например.

Это в том самом, который в тексте https://anibin.blogspot.com/2019/07/1_33.html утверждает (хотя и с вопросительным знаком), что разработка ведётся в вертикальном размере, равном «937 с половиною» пикселов?

Понимаю, прекрасно понимаю.

>>248531
Вам там выше дипломатически объяснили, что никому, кроме вас, это нахѣр не сдалось, поэтому делать это для того, чтобы конкретно вы могли спамить огромными файлами в разделе никто не будет.
Используйте /hr/ по назначению.

>>248534

>никому, кроме вас

Не требуется больше чем 256кб.

Предлагаю многоуважаемому Мицголу перейдя по ссылке убедиться что конвертация в JPG со значением параметра quality 99 не теряет никаких важных деталей, а размер уменьшает значительно:
https://slowpics.org/comparison/1191b065-8750-40c1-b2cf-7e0f026647e1

И после такого не оставляющего сомнений и возражений визуального и технического (а с точными цифрами размера файла не поспоришь) убеждения, оставить навсегда странную любовь к непожатым PNG и взять таки на постоянное вооружение команду ImageMagick convert image.png -quality 99 image.jpg.

>>248535
Возможно, Вы имели ввиду 265кб.

> любовь к непожатым PNG

> таки на

Не нужно жить в том странном внутреннем мире, где «сжатие без потерь» — это как бы и не сжатие вовсе, а вот зато «сжатие с потерями» — вот это, таки на, сжатие.

Пример: от JPEGов https://slowpics.org/comparison/1191b065-8750-40c1-b2cf-7e0f026647e1 командою «jpegoptim --preserve --preserve-perms --all-progressive» можно (без потерь) отобрать ещё ≈4% объёма.

И далее: можно ли вообще пропагандировать морально устаревший JPEG в наши дни, когда едва ли не один только консерватизм фирмы Apple в её подходе к браузеростроению в Safari ещё способен удерживать всех нас на том пороге, за которым ждёт пара-тройка-другая лет недолгого торжества WebP и затем резкий сход его со сцены в пользу AVIF или даже в пользу того новейшего формата JPEG XL, процесс международной стандартизации которого назначен был окончиться как раз в нынешнем октябре, как о том говорит документ https://jpeg.org/downloads/jpegxl/jpegxl-cfp.pdf на четвёртой странице?

>>248883
Ты сути происходящего не понимаешь. Тут просто очередная навязчивая идея: человек уже который год носится с лимитами, форматами и прочей мало кому интересной фигнёй, настаивая на том, что все теперь должны подорваться обслуживать эти его причуды. Был бы лимит десять мегов, он бы десятимеговыми флудил (прецедент есть). Это всё — натужные попытки изобразить «востребованность» навязчивых идей, поэтому размер файлов будет раздут максимально, а аргументы проигнорированы.

К >>248885 прибавлю: если на смену одному стандарту хранения изображений со сжатием без потерь (например, PNG) придёт другой (чуть получше) стандарт хранения изображений со сжатием без потерь (например, FLIF), то можно просто перегнать в него изображение без потерь и тем сэкономить драгоценные сотни килобайтов (а не то и гигабайты), но если на смену одному стандарту сжатия с потерями (например, JPEG) придёт другой чуть получше (например, WebP, BGP, HEIF, AVIF), то это его «чуть получше» не будет стоить и ломаного гроша по сравнению с теми ужасами, которые https://en.wikipedia.org/wiki/Generation_loss притащит в картинку, так что придётся обойтись без экономии драгоценных мегабайтов или сидеть убеждать себя, что потери стóят того.

Исключением является опять же JPEG XL, в котором обещан режим обратной совместимости с JPEG, не привносящий потерь (бережно сохраняются коэффициенты DCT и тихо переужимаются в brotli или ANS, после чего сверху можно назначить деблокер, потому что это считается не внесением новых потерь, а сглаживанием впечатления от старых, причём отключаемым в заголовке), а также обещана возможность применения аналогичного сжатия без потерь не только к коэффициентам DCT, но и к пикселам (так что получится безпотерьный аналог PNG, обещающий уменьшение объёма файла за счёт одного только ухода от zlib к brotli и от кодов Хаффмана к кодам ANS, которые Ярек Дуда придумал).

Обещаны-то они обещаны, а как оно выйдет — это мы ещё посмотрим.

>>248886

> аргументы проигнорированы

Аргументы тут игнорирует только тот, кто зовёт их «мало кому интересной фигнёй», «причудами», «навязчивыми идеями» (два раза, чтобы понавязчивее прозвучало) и проч.

>>248888

> гигабайты

Опечатка. Следует читать: мегабайты.

> BGP

Опечатка. Следует читать: BPG (от Better Portable Graphics).

Когда ваши форматы будут поддерживать любые кофеварки десятилетней давности — тогда и приходите (т.е. лет через десять).

Вообще, было бы приятно иметь лимит файла увеличенным в /b/ хотя бы до 5 MiB. Случаи, когда это нужно, возникают не то, чтобы очень часто, но тем не менее есть: картинки ещё можно пожать, но видеофайлы со звуком в 3 MiB ужимаются плохо.
мимо

>>248895
Если в /b/ сделают 5 метров, то пусть в /a/ делают десять, у меня .webm особенно со звуком критически порой в 4 не влезают.

>>248895
Поддерживаю. В звукозапись тред можно будет постить напрямую свои записи. Хотя возможно именно этого захламления Мод-тян и не хочет.

Моттян, делай лимит 0 и тыкни палкой погромиздов /дев/, чтоб заливку на помфы прикрутили. Был какой-то помф даже с генератором тумбинашек.

>>248898
И оно всё улетает в трубу через месяц.

>>248899
Не улетит, джва года так вебмки на Нульче постили.

>>248898

Пруфлинк или не был.

Вернее сказать, «…или жди появления широчайшей браузерной поддержки формата JPEG XL, в котором для тумбиняшечек берётся первый проход progressive JPEG, полученный N-кратным уменьшением исходной картинки в два раза, так что браузеру достаточно не дочитать файл с сервера, как это сейчас делается с видеофайлами для заполнения площади видеопроигрывателя первым кадром ещё до нажатия на кнопку просмотра».

>>248905
Точно был, потому что в том же скрипте для кпоп-вебмок использовался. Но, видимо, издох уже. Зато есть вот такое http://bnw-thmb.r.worldssl.net/unsafe/fit-in/100x100/your_link, ну ты понел. Можно грузить на помф и сразу делать ссылку на этот шакализатор вместо превью.

Ну и наступит https://en.wikipedia.org/wiki/Tragedy_of_the_commons в масштабах отдельно взятого чужого шакализатора, чьим хозяевам суждено будет охѣрѣть от наплыва ычанек и отпилить (или огородить) свой шакализатор.

Нет, Мицу, не наступит. А если и наступит, то все только спасибо скажут за изничтожение разносчика малвари. К тому же Иичан ведь не помер от ресайзинга своих кортинок, а у шакализатора кеширование есть.

1) Это точно не попытка свести счёты с «источником малвари» за ычанов счёт?

2) Но ведь это не более вѣроятно, чѣмъ новый десятимегабайтовый /a/ из реплики >>248896?

Я вѣрю в формат WebM: уменьшением битрейта видеопотока и аудиопотока всегда можно устранить ситуацию >>248896 и добиться того, что видеофайл помѣстится в тѣ предѣлы размѣра, которые установлены администрацией.

А если при этом файл начинает выглядеть и звучать как какое-то говнецо, то есть ли основания думать, что администрацию можно убедить словесными аргументами, если её ни в чём не убеждает данная ей не на словах, а в бесспорнейших ощущениях живая действительность изобилия файлов, выглядящих и звучащих как говнецо? — таких оснований нѣтъ и быть никоим образом не может.

Ни для кого не секрет, что размеры заглавий у ранобэ (а оттого и у аниме) год от года растут как на дрожжах.

Нельзя ли увеличить (вдвое, втрое, вчетверо или ещё более) допустимую длину имён файлов (ту, после которой начинает срабатывать автоматическое обрезание) хотя бы для того, чтоб после очередного «Ore wo Suki nano wa Omae dake ka yo» или «Watashi, Nouryoku wa Heikinchi de tte Itta yo ne!» в имя файла можно было б и ещё чего-нибудь засунуть?

>>248967
Или оставить обрезалку в покое, а оригинальное имя файла целиком ставить в подсказку при наведении.

Идея >>248969 не сгодится по двум причинам:

1) так не удобно копировать имя,

2) так слишком похоже на слишком оранжевый имиджборд.

>>248979

> 1

А если отображать целиком - неудобно читать треды. Читать приходится гораздо чаще, чем копировать имена файлов.

> 2

Hе больше, чем на форчан.

>>247980
Видеофайлы не нужны на картинкоборде.

>>248998
Ычую. Видео - максимально неудобный формат контента.

>>248999
Ещё и нагружает сильно. Токсичный формат.

Можно запостить на ычане ссылку на картинку в /hr/ доброчана?

>>249224
Вроде бы формально не запрещено. Зависит, конечно, еще и от того, какая картинка.