Ычан: [d | b / bro / hr / l / m / med / mi / mu / o / ph / r / s / sci / tran / tu / tv / x | es / vg | au / tr | a / aa / abe / c / fi / jp / rm / tan / to / vn / vo]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 20450)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, XCF, ZIP размером до 5000 кБ.
  • Ныне 3297 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
153385789892.png-(34.48KB, 500×500, 410.png)
20450
No. 20450    
После публикации исходников мы можем обсуждать доработку не только ранее общедоступных частей интерфейса, но и движка в целом.

Репозиторий: https://bitbucket.org/Therapont/fbe-410
1. Для ваших предложений предназначена ветка public.
2. Только администрация 410чана решает, что в этом движке надо, а что не надо. Соответственно, не стоит излишне пропихивать всякие там революционные идеи. Одобренные потенциальные изменения перечислены на багтрекере (записи, созданные владельцами репозитория).
3. Тестирование предложенных изменений и развёртывание принятых ведётся при наличии у администрации свободного времени на это. Обычно это делается по выходным.
4. Код выложен как есть. Никаких неопубликованных скрытых функций и частей не существует.

Предыдущая нить: >>17371
216 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 22904    
Надпись "Ныне 3156 unique user posts" зело razdrazhaet.
В config.php заменить бы сочетание "unique user posts" на "уникальных столбов". А вообще это число считает количество ip-адресов, с которых отправлялись столбы.
No. 22914    
>>22904
Уникального пользователя столбов.
No. 22930    
157020476586.png-(175.62KB, 700×1000, 2018-06-28-966372.png)
22930
>>22560
>Фоновая проверка заполнения форм
Кто-нибудь кроме меня думал, как можно такое сделать? Получится два одинаковых кода на разных языках, которые надо как-то синхронизировать. К тому же количество полей для валидации варьируется в зависимости от доски. Плюс, сами правила валидации для каждой доски могут меняться через админку ну по крайней мере в Кусабе так. Т.е. IMO, нужно будет родить небольшой фреймворк с собственным DSL для описания алгоритма валидации.
No. 22932    
>>22930
Сделать это возможно это только лишь так, как сделано в кукле: аяксом отправлять форму и при ошибке показывать попап.
Все остальное может только добавить проблем и багов. Тикет действительно написан так, что остается только чесать голову.
Только нафига оно нужно, если кукла эту проблему решает давно и хорошо.
No. 22956    
>>22930
Зачем, если есть required, maxlength и прочие accept?
No. 22959    
157021290080.png-(174.62KB, 350×651, 2015-02-25-714031.png)
22959
>>22932
В кукле и у меня тупо AJAX-постинг. Его сделать довольно просто, только это не «Фоновая проверка заполнения форм», а «Фоновая отправка форм» с последующей обработкой ответа сервера.

З.Ы.: Кстати, на превышение сообщением положеной длины здесь имеются целых две криво рендерящихся ошибки: почему-то само сообщение об ошибке засунуто куда-то в начало HTML-документа, а не туда, где ему положено быть.

>>22956
Где есть? На бэке нету; в бэк придётся впиливать некий DSL и на его базе генерировать формы в шаблонизаторе.
No. 22963    
>>22959
Пхп сам шаблонизатор.
No. 22990    
157034090628.jpg-(207.39KB, 700×700, 957c0cfee1543472d3c10bcaf5f1886e0402f4cb.jpg)
22990
>>22959
>только это не «Фоновая проверка заполнения форм», а «Фоновая отправка форм» с последующей обработкой ответа сервера.
Вы сами это придумали, там нигде не сказано, что надо проверять до отправки.
No. 22991    
157037435445.png-(228.92KB, 500×500, philosorapthor.png)
22991
>>22990
Мы придумали только то, что написано здесь и в ведре. Т.е. ви таки хотите фоновую проверку, которая выглядит как AJAX-постинг, данные отсылает прямо как AJAX-постинг, результаты обрабатывает как AJAX-постинг, но не AJAX-постинг? А механизм, который по мере заполнения пользователем формы проверяет корректность введённых данных и высвечивает ошибки если не, ви таки не хотите?
No. 23128    
157078030586.jpg-(183.44KB, 1280×738, 1430546684640.jpg)
23128
Есть мысль по поводу «мегатикета», призванного решить все проблемы с архивом.
А что если не заморачиваться с починкой движка, а просто написать внешнюю никак от него не зависящую скриптоту на любом языке, которая тупо парист html-файлы в архиве, а взамен выдает свои html, где нет ничего лишнего, стили свои встроенные, так что ничего потом не поломается и вообще. Есстественно, проблема в том, что парсер должен быть достаточно всеядный, чтобы корректно работать со всеми изменениями за последние 10 лет.
Скрипототу можно вручную временами запускать, или же создать в cron'е задачу чтоб периодически сканировала директории с архивом на наличие новых файлов.
И потом никакая доработка движка, которой никто не будет заниматься, не исправит архив за эти 10 лет, файлы так и останутся кривыми.
No. 23210    
157090205242.jpg-(340.76KB, 1080×1018, spoiler_under_focus.jpg)
23210
Пока preview’шка находится в фокусе, её картинка не меняется обратно на preview для spoiler’а. Так и должно быть?
No. 23213    
>>23210
УМВР.
No. 23253    
157105045330.jpg-(135.64KB, 1280×720, Uiharu_Kazari_full_502998.jpg)
23253
>>22991
Я хочу, чтобы вы вместо кривляния тут внимательно читали тикеты, и если вам что-то непонятно, задавали вопросы по тексту, а не гадали по заголовку.
Там сказано, что костыли такое умеют, но вам надо подумать над оптимизацией этого. Потому что костыли, например, работают с HTML-кодом и поэтому дёргают в разы больше ненужного, чтобы показать пользователю простое уведомление из двух слов.

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

>>23210
Под мобилками нет концепции курсора и его наведения, так что, видимо, так и должно быть.
No. 23259    
157106027482.jpg-(169.75KB, 1280×738, 1487216768447.jpg)
23259
А я-то дурак думал, что вам нормальные файлы в архиве нужны. А оказывается на это вообще плевать, просто дело принципа. Тыжпрограммисты ведь как известно обладают бесконечным запасом свободного времени, и нырнуть с головой и распутать совершенно любой код им гораздо проще, чем аж написать одну команду в консоли. Поэтому вместо простого и быстрого решения задачи нужно обязательно решать ее самым сложным и долгим способом, а кто не могёт - пусть проваливает, не задерживайте очередь.
Ладно-ладно, прохожу мимо, не смею больше беспокоить.
No. 23268    
Короч, шоб всё было в жсонах, аяксах и конечно же на базе Кусабы.
No. 23269    
15710656135.png-(599.08KB, 3840×2160, 1564818556261.png)
23269
>>23259
>Тыжпрограммисты ведь как известно обладают бесконечным запасом свободного времени
Зато теоретизировать, не глядя в код, у этих мегапогромистов время есть. И обидки кидать, если их идею отклонили, будто бы им кто-то что-то должен, тоже время есть. На всё время есть, кроме написания кода, ага. А, ну и на аргументы, конечно, ведь вместо них сразу идут обидки.
Ещё раз:
>доработка движка, которой никто не будет заниматься
Потому что вы ск0зали?
Никто вчера прикрутил спойлеры? Никто прикрутил видосы? Никто исправил кучу багов?
Нет, это не никто, это всё вполне конкретные люди. Да, у нас с ними бывают разногласия, но мы им благодарны за их вклад. Вы не хотите ковырять этот движок? Это ваша проблема и ваши обидки на злого меня никак этого не изменят.
No. 23271    
157107123939.png-(202.67KB, 947×616, 15cc3d5456c4026f3.png)
23271
>>23253
Вам уже два человека говорят, что не понимают, чего вы хотите.

Чтобы получить ошибку валидации от сервера postback-ом (т.е. как сейчас), надо сначала на сервер отправить уже заполненную форму (целиком, вместе с прикреплёнными файлами). Если форма проходит проверку, то на бэке происходят определённые бизнес-действия, создаются записи в базе там, отправляются письма, ставятся задачи в очередь, что-то ещё. Отменить эти действия уже нельзя, равно как и нельзя узнать, валидна форма или нет, не отправляя её на сервер.

Костыли на JS имитируют браузер без JS — отправляют форму, как это делает браузер без JS, и принимают ответ, как это делает браузер без JS; из ответа вытаскивают строки ошибки и показывают их во всплывающем окошечке. Это называется AJAX-постинг.

Вы вот именно это хотите, или что-то другое?

>>23269
>Зато теоретизировать, не глядя в код, у этих мегапогромистов время есть...
Если вы такие все из себя чёткие, конкретные и самодостаточные, и лучше других знаете, что, как и когда делать, то смысла выходить из привата в паблик нет. Потому что будут крокодилить, будут спрашивать об одном и том же, будут не понимать и требовать разжевывания тех вещей, которые вам ясны аки день Бажий, будут фантазировать, как бы они это сделали на своём стэке, и как это вообще можно сделать, будут шутить про отсталость и прочее «говно мамонта», предлагать переписать на Node.js или другой стэк, интересный крокодилам, будут обижаться на отказы. Вот зачем, чтобы впоследствии публично же возмущаться, что вот мол ходють тут всякие, тереотизируют всякое, спорють о чем-то своем, а к станку хозяйскому вставать не хотять; кармодрочерство на основе количества коммитов устраивать?
No. 23274    
157107268786.jpg-(276.46KB, 500×752, 7200283.jpg)
23274
>>23271
Ну, я в третий раз могу вас спросить: а нельзя ли оптимизировать ответ сервера после отправки и проверки этих данных, чтобы эти заглушки-уведомления генерировались и выдавались пользователю как-то более изящно, чем просто ныне существующие HTML-страницы со всем лишним мусором, обёрнутые в костыль, чтобы этот мусор спрятать?
Как мне ещё спрашивать, чтобы вы, наконец, попытались это прочитать и внятно ответить?
No. 23275    
>>23269
Конечно, кроме платинового ответа я ничего другого не ожидал.
> Потому что вы ск0зали?
Потому что вы ск0зали. Не далее чем в >>22324 посту. И я склонен с этим согласиться, та задача, в представленном виде, не выглядит выполнимой.
> Зато теоретизировать, не глядя в код
Откуда такие выводы? Тот, кто не видел код Кусабы наоборот считал бы, что все это легко допиливается. Тот же, кто его хоть раз видел, при первом упоминании о нем хватается за голову.
> На всё время есть, кроме написания кода
На написание кода время есть. Но на проделывание в десятки раз большей работы, чтобы добиться того же результата, времени и желания не будет ни у кого.
Вот AJAX-постинг. Здравый казалось бы реквест, полезная фича. Но вам нужен не просто AJAX-постинг, вам нужно чтоб ответом был не простой HTML, который можно распарсить, а JSON с кодом ошибки или еще что, чтоб не было "как в костылях", и таким образом одним росчерком пера задача на пару часов, затрагивающая только фронтенд превращается в задачу на пару недель, в которой надо перелопатить половину бекэнда. По сути, нужно поверх существующего постинга пилить API, да еще сохраняя совместимость с легаси.
Спорить о целесообразности такого решения учитывая дополнительные трудозатраты (значительные) и эффект ими достигаемый (никакой) бесполезно: "Ваши аргументы - не аргументы", "Кроме ваших аргументов у вас нет аргументов".
No. 23276    
157107501720.jpg-(3.81MB, 2893×4089, 8757161.jpg)
23276
>>23275
>Конечно, кроме платинового ответа я ничего другого не ожидал.
А вы большего не заслуживаете, увы. Вы не хотите разбираться в существующем коде, вы не хотите задачи на две недели, а хотите на два часа, вам не нравятся используемые технологии, вам не нравлюсь лично я и т.д. и т.п. Так хорошо же. Это ваш выбор, ваши интересы, ваше свободное время. Но нахѣръ тогда тут писать простыни о том, как вам не подходит этот проект, лол?
Нытьё о том, что эта сложна, аргументом не является.
No. 23374    
157126239013.png-(583.46KB, 1154×585, 12345685.png)
23374
А вообще, для всех мегакодеров, которые не хотят писать код, у меня тоже найдётся задание на чистом ӁС+ХТМЛ. Правда, для другого супермаркетовского сайта.
No. 23472    
Вообще, мне кажется, до отправки можно было бы проверять сам факт заполнения, чтобы нельзя было послать пустое сообщение или ОП-пост без картинки.
No. 23507    
157219682996.gif-(421.78KB, 200×300, 1362318236734.gif)
23507
Новые тикеты:
  • https://bitbucket.org/Therapont/fbe-410/issues/34/ Пагинация новостей на главной: низкоприоритетная задача для ныне не используемой нами функции. Чтоб новости на главной разбивались на страницы по мере накопления записей.
  • https://bitbucket.org/Therapont/fbe-410/issues/35/ Переделать текстовую кнопку «Развернуть все изображения» в значок: самоочевидное. Задача минимум вообще тривиальна, но там надо глянуть на поведение скриптов, потому сейчас они подпись подменяют, если картинки развёрнуты.
  • https://bitbucket.org/Therapont/fbe-410/issues/36/ Упростить строку с именем и размером файла. Сделать как на «Ычане» недавно сделать. Да, надо ковырять шаблон.
Для https://bitbucket.org/Therapont/fbe-410/issues/21/ (Быстрый ответ) уточнил параметры задачи в комментариях. Возможно, совать кнопки к сообщениям прямо в шаблон, а не скриптом, как на «Ычане» — не лучшая идея, ибо в перспективе можно будет приделать настройки (отключить быстрый [убрать значок], совместить традиционный и быстрый ответы [со значком], оставить только БО [без значка/со значком]).
No. 23508    
>>23507
>Сделать, как на «Ычане» недавно сделали
Опечатка.
No. 23602    
157309355260.png-(673.57KB, 1542×2038, Anime-italian-wolf-(kemono-friends)-omnisucker-Jag.png)
23602
Ой, а я что-то забыла...

>>23274
Зависит от того, что может сделать штатный запильщик и что позволяет инфраструктура.

Если ничего, то проще привести в порядок поломанные сейчас сообщения и обернуть ошибки MySQL в ошибки бизнес-логики, сделать им статус отличный от HTTP 200 и смириться с тем, что для пары строк несётся очень много мусора.

Иначе есть два подхода:

1. Для “server side rendering” с сервера отдают отрендеренные куски HTML-а (partial rendering), например, <f:ajax render="element_id" /> в JSF отдаст заново отрендеренный кусок начиная с element_id. Надо чтобы шаблонизатор поддерживал такой вид рендеринга, иначе впиливание его самостоятельно выльется в разработку мега-фреймворка, аналогичного JSF.

2. Для “client side rendering” рендеринг выносят на клиент, а на сервере колхозят JSON-RPC, которое переносит только команды, их параметры и результаты их выполнения, соответственно надо или делать отдельный эндпоинт (и контроллер), который понимает только JSON и только это RPC, или заморачиваться с механизмом content negotiation для существующего контроллера, который будет по заголовкам пытаться угадать, в каком виде пришли, кто их должен обрабатывать и в каком надо отдавать данные. Пока что это наилучший вариант по соотношению мусор/полезные_данные. Однако всё может упереться в архитектуру приложения, поскольку это — вторая пара View-Controller для одной бизнес-логики, и если никто о таком кейсе на этапе проектирования не думал, придётся переделывать очень многое.
No. 23632    
>>23374

реквестуем
No. 23633    
157353930722.jpg-(70.26KB, 603×720, 1338572811228.jpg)
23633
>>23602
В общем, реалистично было бы брать в разработку именно вариант со скриптами, которые дёргают ХТМЛ как есть, видимо.
No. 23641    
157364534792.png-(858.70KB, 899×1271, animal_ears blonde_hair bow bowtie elbow_gloves.png)
23641
>>23633
Насколько я помню PHP, выходит что так.

З.Ы.: Ты обсуждения здесь вообще читаешь? Например, отсюда >>23614 и выше.
No. 23753    
157665113960.png-(93.45KB, 980×370, numeration.png)
23753
Всё хотел сообщить. На страницах с частичным отображением содержимого нити нумерация не соответствует порядку постов в нити: она не учитывает неотображаемые посты. То есть, нумерация не соответствует порядку постов в нити, а вместо этого соответствует лишь их расположению на странице.
No. 23782    
157729599929.png-(385.72KB, 1066×592, 12345684.png)
23782
>>23753
При текущей реализации это не починить.

>>23602
>штатный запильщик
Отличная шутка.
No. 23784    
157746401376.jpg-(145.58KB, 1234×693, counter_fix_prototype.jpg)
23784
>>23753
>>23782
Технически это возможно, если первому элементу
>.reply span.reflink
Добавить класс reflnik-first, и затем задать для него такое правило:

span.reflink-first::after {
    counter-increment: num+197 !important;
}

Вместо 197, конечно же, надо подставить количество пропущенных постов + 1 (оп-пост). Результат можно увидеть на пикрелейтед. Вопрос только в том, где и как этот кусок стиля создать и поцепить на элемент. И второй вопрос, почему это всё вообще важно?
No. 23813    
С изначальным автором кто-нибудь смог выйти на связь за эти два с половиной года? Или он реально... умер?
No. 23818    
>>23813
>С изначальным автором
Автором чего?
No. 23842    
>>23818
Промах тредом.
No. 23873    
После отправки поста меня редиректит из треда на уровень вверх - на доску. Судя по тому, что никто об этом не пишет нигде, то я подозреваю, что так задумано.
Но неудобно же.
No. 23878    
>>23873
Используй noko
No. 23927    
157975963391.jpg-(361.31KB, 1920×1080, [HorribleSubs] Toaru Kagaku no Railgun T - 01 [108.jpg)
23927
Ну щта, никто так и не выучил «Ӂаваскрипт», чтобы запилить «быстрый ответ»?
No. 23928    
>>23927
>>23927
Если отказаться от пункта
> Существующая версия «Быстрого ответа» упраздняется
А так же
> пользователь может потянуть за заголовок, чтобы открепить её и двигать по экрану
И просто сохраняя текущую реализацию вместо скролла наверх перекидывать форму под пост, то задача будет казаться более выполнимой.
Если такой вариант не устраивает, то возможно придется ждать еще три года.
No. 23929    
157976291422.jpg-(275.67KB, 1920×1080, [HorribleSubs] Toaru Kagaku no Railgun T - 02 [108.jpg)
23929
>>23928
Ок, подождём. Нам нужен нормальный «быстрый ответ» как у всех, а не фигня какая-то.
No. 24001    
158264639240.jpg-(223.89KB, 1920×1080, [HorribleSubs] Toaru Kagaku no Railgun T - 04 [108.jpg)
24001
>В Firefox 75 будет добавлена возможность отложенной загрузки изображений
(https://www.linux.org.ru/news/mozilla/15529229)
В хромоте уже есть, как я понимаю.
Как вы думаете, оно нам надо?
No. 24003    
>>24001
При медленном и нестабильном интернете просматривать нити будет не очень удобно. Нельзя будет подождать пару минут, пока страница сайта загрузится полностью и тогда уже её читать. Да и при несколько более быстром интернете всё равно, подозреваю, будет виден процесс подзагрузки изображений thumbnail’ов, что по-моему не очень красиво. Я предпочитаю читать цельный статичный документ без прыгающих туда-сюда текстов, стилей и ленивых дозагрузок. Как посетитель, я против.
No. 24004    
PS К тому же, в метро, если делать ленивую загрузку, треды не почитаешь: в тот краткий промежуток, когда поезд будет проезжать мимо станции и можно будет поймать связь, страница треда просто не загрузится полностью с миниатюрами приложенных к постам картинок. А в туннелях нет связи. Соответственно, любое предварительное открытие нитей, чтобы потом в офлайне их читать будет также невозможным. Таким образом, использование сайта в условиях нестабильной связи будет затруднительно.
No. 24018    
158323867157.png-(103.02KB, 1005×707, schnelle Antwort.png)
24018
>>23929
Это выглядит вот так?
No. 24019    
>>24018
Как это должно выглядеть, можно посмотреть на «Ычане».
No. 24020    
>>24019
Но на Ычане версия из >>23928
No. 24021    
158327332450.jpg-(168.67KB, 1920×1080, [HorribleSubs] Toaru Kagaku no Railgun T - 04 [108.jpg)
24021
>>24020
На «Ычане» не было предыдущей версии «быстрого ответа», которую надо отломать. У нас есть. Её надо заменить на новую.
На «Ычане» верхняя форма никуда не перекидывается, её можно использовать. Но под сообщением появляется форма «быстрого ответа».
Да, на «Ычане» нельзя откреплять и двигать форму по экрану. Но у нас, в отличие от, эта функция уже есть в скриптах для формы «избранных нитей». Какая проблема её присобачить к форме «быстрого ответа»?
На >>24018 какой-то кривой вырвиглаз просто. Так оно выглядеть не должно в любом случае. На «Ычане» оно выглядит именно так, как должно выглядеть здесь.
No. 24022    
>>24021
>Но у нас, в отличие от, эта функция уже есть в скриптах для формы «избранных нитей».
Потерять окошко ответа - малоприятная перспектива.
No. 24031    
>>23928
>И просто сохраняя текущую реализацию вместо скролла наверх перекидывать форму под пост, то задача будет казаться более выполнимой.
Можно выложить эту версию?
No. 24245    
Хочется, присоединяя свой голос к просьбе >>20915, ещё раз высказаться в пользу того, чтобы на имиджборде поддерживался формат WebP, и выскажусь. Прежде этого репликою >>21953 я указывал на несостоятельность одного из аргументов, ранее высказанных против WebP (аргумента о не всеобщей технической поддержке этого формата), привёл адрес полифилла, то есть такого костыля, которым отсутствие поддержки WebP можно подпереть во браузерах, не содержащих такой поддержки. Но этого мало, надо высказаться ещё раз и о нѣсколько другом предмете — о тѣхъ достоинствах формата WebP, знание о которых одно должно служить достаточным побуждением для того, чтобы внедрить и поддерживать формат WebP.

Для начала никак нельзя обойти упоминанием то обстоятельство, что формат WebP представляет собою гугловскую попытку соединить под одним названием и под одним расширением файла, в сущности, три различных формата. Первый из них (lossy WebP) предназначается для сжатия изображений, совершаемого с потерями — идейным основанием для этого формата послужил формат ключевых кадров видеопотока VP8. Второй из них (lossless WebP) предназначается для сжатия изображений, совершаемого без потерь — этот формат не имѣетъ ни малѣйшаго отношения к VP8, а вмѣсто того сочинён на основе различных передовых методов сжатия информации (их по адресу https://developers.googleblog.com/2012/08/lossless-and-transparency-modes-in-webp.html перечислил тот инженер Jyrki Alakuijala, который-то и был проектировщиком). И есть ещё третий формат (animated WebP), который используется для хранения анимированных изображений, каждый кадр в которых хранится в одном из двух ранее упомянутых форматов — с потерями или без потерь.

Из этих трёх форматов только один (lossless WebP для сжатия изображений без потерь) я считаю действительно заслуживающим поддержки. Что же до двух других, то анимированный WebP не очень нужен на имиджборде, так как на страницах не используются никакие анимированные элементы или украшения, если не считать время от времени публикуемых пользователями цитат из кинофильмов, из аниме и всего такого — а всѣ эти послѣднія гораздо лучше смотрятся в современных видеоформатах (VP9 и тѣмъ болѣе AV1) и в таких контейнерах (WebM или MP4), в которые заодно можно всунуть и звуковую дорожку. Не очень-то нужен и lossy WebP для сжатия без потерь: репликою >>20925 я сообщал ужé о существовании исследования, проведённого Фондом Мозиллы и свидетельствующего о том, что достаточно сжатый файл JPEG не слишком превосходит собою по размѣру lossy WebP подобного ему качества. Притом по адресу https://nowere.net/b/res/167102.html#171866 я упоминал и про нѣкоторые досадные недостатки lossy WebP: обязательная цвѣтовая субдискретизация 4:2:0 (то есть всегда только один пиксел цвѣтности на 2×2 пиксела яркости), размѣръ не больше 16383×16383 пиксела, нѣтъ режима постепенной (чересстрочной) развёртки файла (то есть файл показывается по мѣрѣ загрузки всегда только сверху вниз), etc. Короче говоря, если хочется использовать такой формат сжатия с потерями, который был бы очень хорош въ своёмъ дѣлѣ, то уж лучше дождаться того, когда Joint Photographic Experts Group опубликует новую версию своего формата — JPEG XL; сознаюсь, что мнѣ хочется вѣрить, что это случится в нынешнем (2020) году, несмотря на всѣ короновирусныя трудности.

⬇️ ⬇️ ⬇️ ⬇️
No. 24246    
А вот lossless WebP — это другое дѣло, как я чуть выше только что начинал уж говорить. К счастью, про такой формат, который предназначен для сжатия изображений, совершаемого без каких-либо потерь, нам не нужны никакие исследования, сравнивающие внѣшній видъ результатов съ тѣмъ видомъ, который обеспечивается конкурирующими форматами, и также не нужна сама постановка подобных https://nowere.net/b/res/167102.html#171819 вопросов о том, насколько та или иная метрика вида изображения соѿвѣтствуетъ или не соѿвѣтствуетъ человѣческому впечатленію. Наоборот, мы можем раз навсегда успокоиться насчёт качества сохранения изображений в этом формате: оно всегда стопроцентное — и обращать наше внимание единственно на выигрыш въ размѣрѣ файла. И что же? — оказывается, инженер Jyrki Alakuijala превосходно сдѣлалъ свою работу, так что в качестве конкурента для PNG (то есть для единственного формата сжатия полноцвѣтныхъ изображений без потерь, сейчас на имиджборде поддерживаемого, не считая архиваторных форматов в /dev) формат lossless WebP годится очень хорошо, упомянутую по адресу https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study#results способность сжимать содержимое большинства PNG-файлов (даже после переужатия их лучшими средствами переужатия PNG, совершаемого без потерь) ещё на 20% или даже на 40% (а в среднем — где-то на четверть) можно только попривѣтствовать, особенно когда в крупных файлах экономятся цѣлые мегабайты (то есть, для мобильных зрителей — полновѣсныя секунды их времени). Болѣе того: даже тот режим сжатия, совершаемого без потерь, которым будет оснащён грядущий формат JPEG XL, в представленном по адресу https://twitter.com/FidonetRunes/status/1236833595144040448 частном случае сжимает изображение не так сильно, как PNG (потому что проектировщики решили пожертвовать экономиею объёма в пользу большего распараллеливания декодирования и в пользу большей простоты извлечения ѿдѣльныхъ фрагментов изображения) — а вот lossless WebP даже в этом же частном случае сжимает болѣе чѣмъ на четверть сильнѣе, чѣмъ PNG.

Поэтому призываю администрацию запустить поддержку WebP на имиджборде.

(На первое время это можно сдѣлать даже без упомянутого репликою >>21953 джаваскриптового костыля, полагаясь на то одно, что желающие воспользоваться им сумѣютъ подключить его себѣ сами въ качествѣ юзерскриптового.)
Удалить сообщение []
Пароль  
[Mod]