Во-первых, это касается не всех контейнеров, а только тех, которые по каким-то причинам нельзя запустить нативно на arm.
Во-вторых в macOS 13 уже не актуально. Элл сделали, что rosetta2 прикидывается прямо в виртуалку докера, там запускает x86 код и qemu уже не нужен. Скорость получается даже выше, чем на Macbook Pro 2019 года.
Объяснение Хоккинга неверное Объяснение которое даёт Хоккинг не верно Таким образом Хоккинг не даёт верного объяснения, хотя его расчеты верны (и ещё примерно три раза то же самое, другими словами)
Это графики восприятия пользователя потерь для разных форматов. Нет никакого смысла сравнивать восприятие без потерь, т.к. без потерь восприятие будет одинаковым.
> вопрос стоял как получить webp, чтобы и по размерам был не велик, и значительного ухудшения не было
У кодека webp есть параметр quality, с помощью него вы можете управлять степенью компрессии и количеством искажений (потерь, артефактов, шумов).
> вопрос что лучше сгенерированные webp после png или jpg
Я могу только повторить то, что выше написал: после jpeg вы будете сжимать не исходное изображение, а изображение с артефактами jpeg. В этом нет никакого смысла. Вот пример из статьи, немного уменьшений чтобы было удобнее было смотреть.
Оригинал:
Сохраненный в webp q=40:
Сохраненный сначала в jpeg q=75, потом в webp q=45:
Как видите, это только добавило артефактов.
Просто подумайте логически: если бы в этом был хоть какой-то смысл, разве авторы webp не встроили бы это прямо в свой кодек?
Это не работает как с архиваторами, когда вы сжимаете text.zip раром чтобы выжать ещё 5%. При любом сжатии с потерями вы получите искаженную картину на выходе. Если после jpeg вы сжимаете в webp, то для кодека webp исходным изображением станут уже искаженные от jpeg данные. Ему нужно будет не просто передать ваше исходное изображение, а как можно точнее передать весь шум, добавленный кодеком jpeg. А учитывая, что принцип действия у форматов совершенно разный, на передачу этих шумов будет потрачено даже больше битрейта, чем могло быть потрачено на исходное изображение. Ну и естественно, после этого к изображению добавятся искажения уже от самого webp. В результате вы скорее всего получите файл больше чем если бы сжимали оригинал и с двойной порцией артифактов.
Ну так а почему этого требует системный x64 ABI? Потому что функция может что-то там внутри сделать.
Какой? Может быть кто-то знает о чем речь?
Это лучше чем третьего на «родине»
Вы сможете продолжить пользоваться старыми устройствами как часам.
Во-первых, это касается не всех контейнеров, а только тех, которые по каким-то причинам нельзя запустить нативно на arm.
Во-вторых в macOS 13 уже не актуально. Элл сделали, что rosetta2 прикидывается прямо в виртуалку докера, там запускает x86 код и qemu уже не нужен. Скорость получается даже выше, чем на Macbook Pro 2019 года.
А на самом деле?
Установить poetry на windows можно либо при помощи pip:
Вот спасибо
Что?
Ну всё, теперь закроет?
Не понятно, в каком смысле вы их считаете их устаревшими. В GNU libc это всё ещё самый распространенный способ выделения памяти.
Пропустил момент, когда Whoosh спросили совета, что им делать.
Что я узнал из статьи:
Объяснение Хоккинга неверное
Объяснение которое даёт Хоккинг не верно
Таким образом Хоккинг не даёт верного объяснения, хотя его расчеты верны
(и ещё примерно три раза то же самое, другими словами)
Чего я не узнал из статьи:
Верного объяснения
Плюсы:
Это сжатие с потерями
Минусы:
Это сжатие с потерями
У кодека webp есть параметр quality, с помощью него вы можете управлять степенью компрессии и количеством искажений (потерь, артефактов, шумов).
> вопрос что лучше сгенерированные webp после png или jpg
Я могу только повторить то, что выше написал: после jpeg вы будете сжимать не исходное изображение, а изображение с артефактами jpeg. В этом нет никакого смысла. Вот пример из статьи, немного уменьшений чтобы было удобнее было смотреть.
Оригинал:
Сохраненный в webp q=40:
Сохраненный сначала в jpeg q=75, потом в webp q=45:
Как видите, это только добавило артефактов.
Просто подумайте логически: если бы в этом был хоть какой-то смысл, разве авторы webp не встроили бы это прямо в свой кодек?
Потому что статья про форматы сжатия без потерь, а HEIC — формат сжатия с потерями.
> Зачем нужен JPEG-XL и чем он так хорош, если есть HEIC
HEIC не то, чтобы «есть», он закрыт патентами.
Это не работает как с архиваторами, когда вы сжимаете text.zip раром чтобы выжать ещё 5%. При любом сжатии с потерями вы получите искаженную картину на выходе. Если после jpeg вы сжимаете в webp, то для кодека webp исходным изображением станут уже искаженные от jpeg данные. Ему нужно будет не просто передать ваше исходное изображение, а как можно точнее передать весь шум, добавленный кодеком jpeg. А учитывая, что принцип действия у форматов совершенно разный, на передачу этих шумов будет потрачено даже больше битрейта, чем могло быть потрачено на исходное изображение. Ну и естественно, после этого к изображению добавятся искажения уже от самого webp. В результате вы скорее всего получите файл больше чем если бы сжимали оригинал и с двойной порцией артифактов.
Это формат сжатия с потерями и графики про восприятия сжатия с потерями.