[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Animapcha image [@] [?]
Тема   ( ответ в 185114)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM, WEBP размером до 5000 кБ.
  • Ныне 3445 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 375
quote1.webp - (757.85KB, 2458×9088)
185114
No. 185114  
На 410чанѣ съ начала апрѣля 2021 года и по вторую половину января 2022 года совершалося цѣнное обсужденіе многихъ вопросовъ о томъ, какъ умѣстно сохранять изображенія въ графическихъ файлахъ. Его архивъ https://410chan.org/b/arch/res/158687.html донынѣ хранитъ и наглядные примѣры сильнаго сжатія изображеній, и подробные списки достоинствъ нѣкоторыхъ форматовъ графическихъ файловъ, и образцы иллюстрацій, способныхъ помѣщаться на 410чанъ только послѣ переужатія, а не механическаго копированія ихъ изъ первоисточника.

Не мало тамъ было сказано и словъ о томъ, слѣдуетъ ли для сохраненія кадровъ видео прибѣгнуть къ формату, предусматривающему сжатіе съ потерями (какъ JPEG или lossy WebP), или же умѣстно потратить большій объёмъ файла (въ форматѣ PNG или въ lossless WebP), но той цѣною достигнуть неизмѣнности пикселовъ.

Желая возобновить тутъ обсужденіе графическихъ файловъ, я радъ видѣть для того вѣскій поводъ: въ FFmpeg въ нынѣшнемъ мѣсяцѣ появилась возможность сохранять какой угодно ключевой кадръ из видео AV1 въ файлѣ AVIF, но при этомъ зря не тратится объёмъ файла (какъ было бы при перекодированіи въ форматъ безъ потерь), зря не тратится качество кадровъ (какъ было бы при перекодированіи съ потерями), зря не тратится и то время, которое уходило бы на перекодированіе, а вмѣсто того всѣ свѣдѣнія о пикселахъ ключевого кадра сохраняются «какъ есть» безъ перекодированія, то есть точно въ томъ же прежде сжатомъ видѣ, какой онѣ ужé имѣли въ видеопотокѣ AV1, и снабжаются только новымъ заголовкомъ, приличествующимъ файлу AVIF.

Сохранить ключевой кадръ этимъ способомъ можно одною командою:

ffmpeg -hide_banner -i имяФайлаAV1 -ss времяКадра -frames:v 1 -c:v copy кадръ.avif

Въ сообщеніи по адресу https://t.me/ReadMithgol/491 (растровую копію котораго я прилагаю и тутъ для наглядности) и затѣмъ ещё по адресу https://t.me/ReadMithgol/492 я поподробнѣе разсмотрѣлъ то мѣсто и значеніе, которое эта новинка FFmpeg получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
120 сообщений пропущено. Показаны 50 последних сообщений
No. 202456  
Это ты сдох, >>202455-кун.
No. 202457  
kafuka-fgsfds.jpg - (70.45KB, 1280×720)
202457
По возможности избегайте гибнуть.
No. 202458  
OMG, сжатие picture убивает?!
No. 202459  
>>202458
Ловушка Мицгола о которой никто не подозревал! Тысячи пассажиров убились об жипегксель! Читайте дальше...

>таблетки
А по сути ответил только пассажир, давший ссылку на чафу. Все остальное - преобразование сжатого графического файла в текстовый формат. А я спрашивал именно сжатие изображения в виде текста. Иначе заголовок даннага тхреда самнителен!
No. 202460  
faptcha_php.png - (8.17KB, 90×50)
202460
>>202459
> Иначе заголовок даннага тхреда самнителен!
Не могу не поинтересоваться любите ли вы Катю Самбуку?
No. 202461  
75232234_p0.jpg - (0.98MB, 996×1400)
202461
>>202459
Фармат заказал, фармат получил.
No. 202462  
В 2123-ем году все мы мертвы.
Я гарантирую это.
No. 202464  
Вы не 未来人、 чтобы гарантировать это.
No. 202466  
faptcha_php.png - (8.83KB, 90×50)
202466
>>202460
https://ru.wikipedia.org/wiki/Самбука,_Катя
???
No. 202469  
Что если во всёмъ мірѣ одинъ >>202459-кунъ только любитъ Катю Самбуку, а остальные люди его эпохи — всѣ, какимъ-нибудь наплывнымъ вѣтромъ, на время почему-то отъ него оторвались…

И понятно почему.
No. 202476  
faptcha_php.png - (8.98KB, 90×50)
202476
>>202466
Катя Самбука зовется так потому что любит и саму самбуку, а ведь если ее правильно употреблять, с огоньком, то соответственно, какое-то время придется разговаривать в основном с помощью заднеязычных согласных!
No. 202478  
Чистейшая шизофрения. Ради такого я плачу за интернет.
No. 202480  
>>202469
> Что если во всёмъ мірѣ одинъ >>202459-кунъ только любитъ Катю Самбуку

Она на ПМЭФ приезжала в этом году. Знают и любят!
No. 202482  
58602286eba717149b1f4ffb99a7ec8e.jpg - (213.99KB, 1500×1250)
202482
И откуда во мне столько злобы. Периодически.
No. 202484  
>>202480
Лол, правда?
А на следующем будет Альбина Сексова?
No. 202487  
>>202484
Там каждый год кокаиновые оргии с приглашенными знаменитостями.
No. 202741  
photo_2023-07-24_15-21-56.jpg - (77.24KB, 800×600)
202741
Чивоч, что за формат такой heic, старый он новый? Что мы знаем об инновациях в форматах картинок? Что самое лучшее для долгосрочного хранения?
No. 202743  
hytryi plan.jpg - (59.13KB, 435×300)
202743
キタ━━━(゚∀゚)━━━!!
No. 202744  
>>202743
Конечно, дружочек! Чтобы увеличить шансы на то, чтобы ваши работы стали фильмом в будущем, я дам тебе несколько советов:

1. Храни кадры цифрово: Используй высокое разрешение и храни файлы на внешних дисках или облачных сервисах.

2. Добавь метаданные: Опиши и дай контекст своей работе, чтобы люди поняли, что она значит.

3. Используй онлайн-платформы: Размещай свои кадры на сайтах, где люди могут увидеть их, например Behance или ArtStation.

4. Знакомься и сотрудничай: Посещай выставки и фестивали, чтобы завести контакты со схожими творческими людьми.

Вспомни, что успех не гарантирован, но активное продвижение и хранение работ могут открыть двери для будущих возможностей. Продолжай творить и делись своим искусством!
магическое сияние
No. 202745  
>>202744
Но вообще надо освоить софт по сортировке кадров для этой профессии, вроде бы Kyno есть такое. Есть ещё некий аналог, я спросил у профессионала, может ответит.
No. 202746  
SVT-AV1 BD-rate.webp - (128.17KB, 1288×747)
202746
>>202741

HEIC — это хранимое в контейнере HEIF (High Efficiency Image File Format) изображение, кодированное по правилам видеоформата HEVC (High Efficiency Video Coding — то же сáмое, что и формат ITU-T H.265).

На скриншоте >>202359 видно, что с недавних пор изображения в формате HEIC невозбранно открываются во браузере Safari 17, пока ещё находящемся на стадии бета-версии (официальный же выпуск семнадцатой версии его, вѣроятно, произойдёт осенью).

Так как AVIF — это хранимое в таком же контейнере HEIF изображение, кодированное по правилам видеоформата AV1, то AVIF лучше.

(Насколько лучше? — настолько же, насколько AV1 лучше HEVC, то есть примѣрно в √2 раз в зависимости от настроек кодировщика.)
No. 202781  
>>202746
> во браузере
Ну ёптель-моптель. В браузере же!
No. 202783  
manifesto.png - (470.07KB, 793×731)
202783
キタ━━━(゚∀゚)━━━!!
No. 202787  
>>202781

От ёптель-моптеля слышу. Если можно записывать «во браке», то можно записывать и «во браузере», потому что падеж точно тот же (предложный), ударный слог точно тот же (первый), количество первых согласных точно то же (два), первый гласный звук точно тот же («а»), предшествующие согласные звуки точно тѣ же («бр»), выбор самих предлогов точно тот же («в» или «во» в пользу «во»).
No. 202879  
screenshot.webp - (271.60KB, 888×1455)
202879
По адресу https://t.me/ReadMithgol/707 я опроверг нѣкоторые примѣры неэффективности формата анимированных WebP по сравнению с форматом анимированных GIF, популяризированные создателем утилиты gifski.

Скриншот прилагаю.
No. 203032  
JPEG XL in Safari 17.webp - (88.24KB, 1280×1144)
203032
По адресу https://webkit.org/blog/14445/webkit-features-in-safari-17-0/ видно, что фича >>202359 (поддержка графических форматов HEIC и JPEG XL) успѣшно прошла стадию бета-версии и близится к официальному выпуску во браузере Safari 17 черезъ недѣлю (26 сентября) на Маках, тогда как на iOS и на iPadOS эта версия Safari ужé вышла и поддержка этих форматов ужé работает со вчерашнего дня (18 сентября).

Скриншот прилагаю.
No. 203033  
formattalks.png - (1.19MB, 1903×4478)
203033
Интриги, скандалы, грязные подробности форматной войны.
No. 203175  
>>203166
https://www.opennet.ru/opennews/art.shtml?num=59746
Да, забавно.
К тому же шебп и в Tor Browser пришел из лисицы, и вот это вот совсем эпично.
No. 203183  
Просто обновите libwebp до версии 1.3.2, обновите Firefox до версии, по адресу https://www.mozilla.org/en-US/security/advisories/mfsa2023-40/ указанной (или новѣе, потому что ужé есть новѣе), обновите Telegram Desktop до версии 4.9.7 (или новѣе, потому что ужé есть новѣе), etc.

Пользователям версий Windows, предшествующих десятой, неплохо бы заодно обновить и браузер Edge, как это по адресу https://www.neowin.net/news/microsoft-releases-update-for-edge-on-windows-7-and-8/ сообщают.

Послѣдняя версія Tor Browser (версия 12.5.6) на своей странице «about:tbupdate» сообщает нам, что содержит бэкпорт фич безопасности из Firefox 115.3.1. И так как по адресу https://www.mozilla.org/en-US/security/advisories/mfsa2023-40/ было сказано, что версия Firefox ESR 115.2.1 ужé содержала исправление ошибки в libwebp, то пользователям Tor Browser можно насчёт неё не напрягаться (а также и насчёт ошибки https://www.mozilla.org/en-US/security/advisories/mfsa2023-44/ в libvpx). Если же нѣкто использует Tor Browser, но не обновляет, то соболезную.

Вдвойне соболезную тѣмъ, кого задѣло зеродэем до его исправления. Но опосля обнаружения и исправления теперь всё хорошо.
No. 203187  
>>203183
Тут больше интересно
>Does anyone know if CVE-2023-4863 has been used to exploit people in the wild or is it just a feasible possibility?

Вопрос: Сколько времени TB оставался уязвим?

По источникам
[1] https://www.cve.org/CVERecord?id=CVE-2023-4863
[2] https://security-tracker.debian.org/tracker/CVE-2023-4863
[3] https://www.mozilla.org/en-US/security/advisories/mfsa2023-40
[4] https://www.mozilla.org/en-US/firefox/102.15.0/releasenotes/
[5] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/maint-12.5/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt
[6] https://chromium.googlesource.com/webm/libwebp.git/ /902bc9190331343b2017211debcec8d2ab87e17a^!/
[7] https://tracker.debian.org/news/1463551/accepted-libwebp-132-01exp1-source-amd64-into-experimental/
[8] https://www.mozilla.org/en-US/firefox/102.15.1/releasenotes/
[9] https://chromium.googlesource.com/webm/libwebp.git/ log/refs/tags/v1.3.2/
[10] https://chromium.googlesource.com/webm/libwebp.git/ log/refs/tags/v1.3.1/

2023-06-23: выпуск libwebp1.3.1 [10] (уязвима)
2023-07-04: выпуск FF 102.13.0esr (уязвима [2])
2023-08-29:&выпуск FF 102.15.0esr [4] (уязвима)
2023-08-28:&TB 12.5.3 переходит на FF 102.15.0esr [5] (уязвима)
2023-09-07: коммитом исправляется libwebp [6]
2023-09-09: резервируется CVE номер CVE-2023-4863 [1]
2023-09-12: анонсируется уязвимость CVE-2023-4863 [1] и публикуются новости в интернетах [3]
2023-09-12: выпуск FF 102.15.1esr [8] (исправлен [2][3])
2023-09-12: TB 12.5.4 переходит на FF 102.15.1esr [5] (исправлен [2][3][5])
2023-09-13:#выпуск libwebp-1.3.2 [9] (исправлена [9])
2023-09-15: пакет libwebp1.3.2 приходит в debian [7]
& time paradox, да
# 2023-09-12 из-за разницы в измерении времени этими сайтами/системами?

Ответ:
Если допустить, что весь месяц (с потолка) до того, как она была пофикшена в libwebp (2023-09-07), она уже эксплуатировалась хацкирами разного рода, нашедшим её самим, то выйдет, что с 2023-08-07 по 2023-09-12 (1 месяц) пользователи TB не были защищены никак.
Обновившись 2023-08-28, все равно 15 дней они не были защищены никак.
Если допустить, что хацкеры узнали о ней из коммита в libwebp (2023-09-07), то выйдет что c 2023-09-07 по 2023-09-12 (5 дней) пользователи TB не были защищены никак.
No. 203188  
Напоминаю, что при виде сокращения «TB» типичный читатель сперва пробует прочесть его как «телевизор», затѣмъ как «terabyte» и наконец как «Thunderbird».

Вам хочется использовать это сокращение для слов «TOR Browser»? — поздравляю, это прочтение будет минимум четвёртым из приходящих на ум, да и то может быть отодвинуто словами и словосочетаниями «tomboy», «Taco Bell», torrentbytes.net, «turd bucket», «total bullshit», «tuberculosis», «true bro» и им подобными ещё подалѣе.

Сколько и каких будет таких? — это зависит только от величины активного словаря читателя.
No. 203189  
>>203188
Нельзя же так игнорировать контекст!
No. 203207  
Screenshot_2023-10-03_05-20-48.png - (592.14KB, 1920×1054)
203207
Вот как важно перейти на graphicsmagick, ежели кто-то ещё не сделал этого (хоть и некоторые дистрибутивы директивным решением могли перевести насильно).
No. 203210  
Скриншот >>203207 ничего особенного не говорит умý, так как ужé от момента «если в системе до сих пор сохраняется libwebp 0.4.4, не обновлявшийся с октября 2015 года…» большинство читателей сознаёт, что это не про них.
No. 203213  
>>203210
Новый cwebp сжимает лучше?
No. 203214  
>>203213

Ну да, если судить по тому, как нерѣдко в подписях к коммитам (по адресу https://chromium.googlesource.com/webm/libwebp/ /ca332209cb5567c9b249c86788cb2dbf8847e760/ChangeLog лежит нынѣшній сборник их) встрѣчается слово «improve» (и его производныя) по отношению к силе сжатия.

Послѣдній абзац скриншота, к сообщению >>202879 прилагаемого, также относил часть успѣха на счёт болѣе новой версии кодировщика.
No. 203227  
screenshot.webp - (75.07KB, 1280×1046)
203227
Автор рассуждения >>203187 болѣе или менѣе явно (хотя и оговаривается: «с потолка», то есть беспочвенно) ведёт отсчёт уязвимых версий libwebp, начиная от версии libwebp 1.3.1, которую называет вышедшею 23 июня (датируя по репе), хотя вообще-то доступные для скачивания по адресу https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html сборки этого выпуска датируются 29 июня.

Необходимость этакого гадания выглядит изрядно странно на фоне того, что первою же из гиперссылок, в сообщении >>203187 приведённых, оказывается гиперссылка, по адресу https://www.cve.org/CVERecord?id=CVE-2023-4863 ведущая. Если по ней перейти, то тогда немедленно становится видно на первом же экране (скриншот прилагаю), что уязвима не одна только предпослѣдняя версия libwebp, но и каждая из очень многих предшествующих версий, начиная от версии 0.5.0 (которая по адресу https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html датируется 23 декабря 2015 года).

Мы смотрим не на недѣлю, не на мѣсяцъ, даже не на десяток мѣсяцевъ, а на без мáлого восемь лѣтъ непрестанной уязвимости, которая (согласно истории, по адресу https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ изложенной) обнаружена была на недѣлѣ, прошлой по отношению к 7 сентября, и обнаружена была ужé используемою как вектор доставки программного средства шпионажа (израильского происхождения), извѣстнаго под названием Pegasus.

По адресу https://www.nytimes.com/2022/01/28/magazine/nso-group-israel-spyware.html можно прочесть в «The New York Times», что Pegasus употребляется с 2011 года. Может быть, дыра в libwebp оперативно передана была евреям (или даже запроектирована и создана в еврейских расовых интересах с сáмого начала, так как Google — это также еврейская компания) ещё в 2015 году и эксплуатировалася всѣ эти ≈восемь лѣтъ наряду со многими другими уязвимостями, нам ещё не извѣстными, но им очень хорошо извѣстными.
No. 203228  
>>203227
Спасибо за анализ и исправления!
Однакоже это крайне забавно, что тот, у кого "в системе до сих пор сохраняется libwebp 0.4.4, не обновлявшийся с октября 2015 года" оказался в безопасности.
(хотя не совсем конечно, торобраузер же свою несет)
No. 203253  
https://www.youtube.com/watch?v=JehEh7i1PIE
No. 205381  
Какая интересная программа, а есть ли такое же, но чтобы бесплатно?

https://youtu.be/P8t_Fx5dcC4
No. 205509  
smush.webp - (746.80KB, 888×4245)
205509
По адресу https://t.me/ReadMithgol/823 и затѣмъ ещё по адресу https://t.me/ReadMithgol/827 я сообщил про близящійся успѣхъ формата AVIF (на будущей недѣлѣ он будет поддерживаться ужé каждым из популярных браузеров), перечислил достоинства и недостатки.

Сшивку скриншотов своих сообщений прилагаю.
No. 205522  
screenshot.webp - (342.18KB, 888×2690)
205522
По адресу https://t.me/ReadMithgol/828 я прибавил к >>205509 болѣе подробный разсказъ об анимированных AVIF.

Скриншот прилагаю.
No. 205757  
screenshot.webp - (316.41KB, 888×2682)
205757
То событие, которое я прежде в сообщении >>205509 мог без труда предвидѣть, и впрямь произошло 25 января.

По адресу https://t.me/ReadMithgol/840 я изложил основные подробности и свои мысли на этот счёт.

Скриншот прилагаю.

Также процитирую основную мысль:

> …если прежде для сжатия иллюстраций, совершаемого с внесением потерь, формат WebP оказывался очевидным выбором, если выбирать в логике «это сáмое мощное средство из числа поддерживаемых послѣдними версиями каждого из сколько-нибудь популярных браузеров», то в 2024 году таким средством сдѣлается AVIF.

> Впредь формат WebP будет восприниматься в качестве прошлого такого средства, а формат JPEG — позапрошлого.
No. 205762  
screenshot.webp - (455.44KB, 888×4268)
205762
Под конец позавчерашнего вторника (30 января 2024 г.) на Ычане появилася поддержка WebP, как о том по адресу https://iichan.hk/n/ сказано.

В обсуждении этого события, по адресу https://iichan.hk/b/res/5326636.html случившемся (скриншот прилагаю), раздаются как здравые голоса (напримѣръ, то наблюдение, согласно которому поддержка WebP на чане появилась только тогда, когда впору уж призадуматься о поддержке AVIF), так и не очень здравые (напримѣръ, один странный любитель ImageMagick устроил демонстрацию того, до какой крайности может постепенно дойти человѣкъ, не желая использовать команду «cwebp -m 6 -q числоБалловКачества -pre 5 имяИсходногоФайла -mt -v -metadata icc -progress -o имяФайлаРезультата.webp» по нелѣпой причине «это ниже моего достоинства»).
No. 205779  
screenshot.webp - (52.40KB, 843×1143)
205779
По наводке https://iichan.hk/b/res/5326636.html#5326804 обратил внимание на параметр «-pass 10» при кодировании WebP.

В справке (скриншот прилагаю) говорится, что значением этого параметра является число шагов анализа, а по адресу https://developers.google.com/speed/webp/docs/cwebp прибавляют: «при дихотомии в режимах -size или -psnr».

Однако и не в этих режимах я вижу параметр «-pass 10» оказывающим влияние на объём файла, сжимаемого с внесением потерь, а также на расположение и характер артефактов в нём.

Не могу однозначно рассудить, к лучшему эти измѣненія или нѣтъ.

Ещё одна недокументированная функция на мою голову, да что ж такое.
No. 205793  
103993299_p0_m6_pass10_q99.webp - (4.83MB, 3840×2160)
205793
>>205779
https://litter.catbox.moe/6uqbhz.png
Возможно, что -q внутри превращается в -psnr, или между ними какая-то другая связь, и таким образом -pass работает и с -q тоже. cwebp мне часто показывает значения PSNR не выше где-то 55 с -m 6 -pass 10 -q 100. Если для 103993299_p0.png попытаться поставить -m 6 -pass 10 -psnr 100, ничего не выходит, получаются Y-U-V-All-PSNR 51.52 51.17 51.22. Если же вместо -psnr 100 поставить -q 100, то для исходника этой картинки PSNR в графе Output будет почти идентичный, даже незначительно хуже: одинаково квантизаторы по сегментам 0, задействован только 1-ый сегмент, но количества блоков разные и у файлов разный размер. Output -psnr 100 идентичен output-у -psnr 52. А вот с -psnr 51, который меньше PSNR-а из предыдущих output-ов, уже появляется разница в количестве блоков.

Кстати, короткий -longhelp просто говорит "analysis pass number". А man упоминает, что если не пользоваться ни -size, ни -psnr, то default'ное значение 1.
No. 205795  
>>205779

> Однако и не в этих режимах я вижу параметр «-pass 10» оказывающим влияние на объём файла, сжимаемого с внесением потерь, а также на расположение и характер артефактов в нём.

Однако не всегда, то есть не каждого файла.

Скажем, результаты эксперимента >>201775 не перемѣняются от употребления параметра «-pass 10».

Ѽ, етить.
No. 205796  
>>205793

> https://litter.catbox.moe/6uqbhz.png

404 Not Found
No. 205797  
>>205796
>https://litterbox.catbox.moe/
>Temporary uploads (max 3 days)
Удалить сообщение []
Пароль  
[Mod]