На 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 получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
Впрочем, слово «скриншот» тут использовано метонимически для простоты, но по сути к сообщениям >>199597 и >>199598 и >>199599 приложены не скриншоты сообщений, по адресу https://t.me/ReadMithgol/556 и https://t.me/ReadMithgol/557 и https://t.me/ReadMithgol/558 расположенных, а растровые копии их.
Чтобы сдѣлать послѣдній абзац сообщения >>199599 ещё болѣе наглядным примѣромъ, я прилагаю тут результат переужатия (утилитою https://github.com/fhanau/Efficient-Compression-Tool совершённого) того файла PNG, который к сообщению https://410chan.org/b/arch/res/158687.html#171743 прилагался. Нетрудно видѣть, что файл получается на 365 байтов короче (состоялась экономия ≈полутора процентов его объёма). Дополнительно сообщаю, что даже послѣдняя версия oxipng создаёт в этом примѣрѣ файл большего объёма (хотя и всего-навсего на 20 байтов большего).
У меня в кои-то веки дошли руки выкачать все свои закладки с Пиксива, в связи с чем хочу вбросить небольшую статистику. Из 5659 выкачанных файлов 347 не пролезают в 5120000 файлолимит Чиочана. То бишь, для каждого 20-ого файла при постинге необходимо перекодирование. Общий объём 8504667148 (8110 MiB), объём после cjxl стал 5723435301 (5458 MiB), став меньше на 32%. Кодировалось с cjxl --num_threads 0 -q 100 --brotli_effort 11 -e 9 -I 100 -E 3 https://410chan.org/b/arch/res/156266.html#164349 Я совсем забыл, зачем я в скрипт тогда запихал -E 3. Информация об этом number of extra MA tree properties to use гуглится плохо и скрыта за несколькими -v. Печатается по -h без указания предельных и дефолтных значений, как впрочем, и для много чего там. В девелоперской документации удалось это дело откопать, рекомендуют ставить от 0 до 3, предельное значение 11. Влияет на скорость декодирования. Потестил, с -E 3 файлы всё-таки меньше, чем без него. Оставил. https://files.catbox.moe/bi920s.jxl Кстати о скорости декодирования. Вот рекордный экземпляр из этой партии. На 8-ядерном AMD Ryzen 7 5800H djxl'ем, который (теперь?) пытается задействовать весь проц, он декодируется за 1 секунду. Но если декодировать в 1 поток, как делает gpicview, например, то где-то за ~8 секунд. А за сколько секунд он декодируется у вас? Для больших PNG картинок, эдакий 7z получается. Жрёт память при кодировании эта штука тоже как 7z с большим словарём. Зафиксированный максимум - где-то до 10 GiB на одну большую (~7000x3000) PNG картинку. Но это максимумы. Так-то с dxl вся эта партия в 5659 декодируется за 315 секунд, то бишь где-то 0.06 секунды на картинку в среднем. Так что с ristretto и с современным процем оно всё-таки удовлетворительно, хотя проблема есть и оригинальный lossless формат по-прежнему не для кофеварок. Хотя, может быть, есть какие-нибудь настройки, которые позволяют за счёт сжатия похуже сильно улучшить скорость декодирования.
>>199642 Я однажды тоже решил схоронить Пиксив, и вот что получилось. du -sL pixiv > 676241856 pixiv du -shL pixiv > 645G pixiv find -L pixiv/ | wc -c > 20420025 Зачем я это сделал и как теперь с этим жить?
>>199657 Двадцать миллионов картинок схоронил пассажир. Пятьдесят миллионов девочек проживает в одной только Японии. Только вдумайся, какой большой мир! Сколько времени ты на Пиксив с бурами убил, сколько картинок с девочками на борды отправиил, как тщательно картинки с ними к постам подбирал. И сколько бы ты картинок с девочками за свою жизнь ни видел, а в Японии их больше, и все разные и настоящие. Среди них и твоя единственная ламповая няша, которую можно потрогать и погладить. Так что ищи и дерзай, анон-сан!
>>199657 Ты можешь стать картинкопостером. Вперёд >>199029!
>>199659 >>199660 Я неправильно подcчитал, wc -c это не то что нужно. > This option displays count of bytes present in a file Сначала показалось, что там 200 тыщ, поэтому не вчитываясь отправил. Но 20 миллионов - это перебор. find -L pixiv/ -type f| wc -l 500521 Вот реальное количество изображений с Пиксива. И то там дубликатов гигов на 10 с него. Когда-нибудь с ними разберусь. И ведь не Пиксв же один сайт с картинками.
>>199659
>>199657 Аплоадь на панду для фарма поинтов, выводи на деньги, являйся владельцем картинок с потёртых аккаунтов и до изменений контентополитики.
>>199717 Какой такой вывод? Максимум голдстар купить. Девочке нашептали, что для голдстаров доступно больше галерей.
>>199718 >баунти за галереи в hath/gold Люди не глупыя, где-то сканлейтеры эти фантики в реальные денежные знаки всё-таки переводят.
Во браузере Mozilla Firefox версии 111 ожидается возможность смотрѣть анимированные AVIF. По адресу https://t.me/ReadMithgol/572 я разсмотрѣлъ это обстоятельство в ряду других улучшений той же версии. (Растровую копию прилагаю.)
По адресу https://twitter.com/FidonetRunes/status/1627660168119869442 я сообщил (скриншот прилагаю) о том, что теперь формат JPEG XL располагает кодировщиком, способным (с параметрами «--allow_expert_options --effort=10») сжать без потерь даже такие файлы PNG, которые прежде не были для него сжимаемыми, но что всё же для этих файлов lossless WebP достигает ещё меньшего объёма.
По адресу https://t.me/ReadMithgol/587 я помѣстилъ краткое пояснение того, каким образом учёт рѣдкости тѣхъ клѣтокъ сѣтчатки, которыя ѿкликаются на синий цвѣтъ, позволил создателям формата JPEG XL (и кодировщика jpegli) сильнѣе сжимать изображения за счёт перехода к использованию цвѣтового пространства XYB. Скриншот сообщения прилагаю совмѣстно с копиями скриншотов, к нему прилагавшихся в Телеграме. Кто пожелает ретвитнуть, тому предлагаю https://twitter.com/FidonetRunes/status/1629019451487035394 ретвитнуть.
Прилагаемый GIF (результат работы gifski) не желает циклически воспроизводиться у меня в Mozilla Firefox версии 110.0.1, хотя в IE11 всё в порядке. Казалось бы, GIF как GIF, просмотрщиками (и XnView, и Honeyview) просматривается циклически, чего же недостаёт Файерфоксу, мать его, а?
>>200485 Эта штука валится на JPEGах.
Похоже, что эту фичу в общем случае смысла использовать нет. Даже такую вот маленькую картинку cjxl, с прочими настройками из >>199642, кодирует 30 минут, в то время как с -e 9 та же картинка кодируется за 8 секунд. C --effort 10 картинка получается в 90991 байт, то бишь на 616 байт меньше, чем с -e 9.
Когда Мицгол пересядет на десятку? Хотя бы LTSC 2021? И да, Precure — дойная корова, не имеющая культурной ценности
>>185114 Чё там с новерью?
>>201039 Аватарки и суицид.
>>201046 Но там же не только Уютный есть, в /b тоже какой-то актив наблюдается.
>>201050 Это из /b как раз.
>>201057 (0_0) Впрочем, Лина там завсегдатай, так что ничего нового.
По адресу https://t.me/ReadMithgol/601 и https://t.me/ReadMithgol/602 и https://t.me/ReadMithgol/603 и https://t.me/ReadMithgol/604 и https://t.me/ReadMithgol/605 и https://t.me/ReadMithgol/606 я разсмотрѣлъ начало истории формата GIF и употребление средства animeloop для автоматического поиска таких сцен в видеозаписях (прежде всего в аниме), которые годятся для сохранения в виде бесшовных зацикленных анимаций. Примѣръ такой анимации прилагаю.
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/602 прилагаю.
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/603 прилагаю.
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/604 прилагаю.
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/606 прилагаю. 💢 Если изобилие таких прикладываний кого-нибудь бѣситъ и выглядит почти как флуд, то мягко напомню: пять послѣднихъ сообщений могли бы невозбранно смѣниться единственным, если бы 410чанъ поддерживал прикрѣпленіе нѣсколькихъ иллюстраций к одному сообщению.
>>200808 https://youtu.be/sxXs0Yy5-0Y
>>201143 Всё плохое можно выключить в групповых политиках и службах (даже сторонний софт не понадобится), даже "назойливое по сравнению с прошлыми виндами" скачивание заплаток.
P.S.
Обновления на Винду выходят каждый второй вторник месяца (иногда первый). Это не так уж сложно проконтролировать. А так, если уж он до сих пор сидит на 7, то может досидеть до конца её поддержки в Файрфоксе, а потом уже решать, что дальше делать.
Главное верить.
>>199139 > Быть может, настала пора пересмотрѣть эту настройку. И пересмотрѣлъ: >>/dev/27058.
Сегодня и впредь 410чан не искажает цвѣта пикселов при миниатюризации изображений, находящихся не въ цвѣтовомъ пространстве sRGB. Реальными примѣрами таких изображений могут быть: ① Иллюстрации, созданные въ болѣе широком цвѣтовомъ пространстве Display P3 (прежде всего на современной эппловской технике). Дѣвочка в затопленном городе https://danbooru.donmai.us/posts/5826911 может считаться примѣромъ этого. ② Иллюстрации, созданные въ болѣе раннем широком цвѣтовомъ пространстве Adobe RGB 1998 года (на подобных https://www.ixbt.com/monitor/nec-pa241w.shtml#color японских дисплеях). Дѣвочка перед грозою https://danbooru.donmai.us/posts/4464772 может считаться примѣромъ этого. ③ Иллюстрации, изначально не помѣщавшіяся на 410чан, но переужатые современным кодировщиком jpegli съ помѣщеніемъ ихъ въ цвѣтовое пространство XYB (чтобы ещё на ≈10% опередить MozJPEG по соѿношенію качества и объёма файла, как это по адресу https://twitter.com/jyzg/status/1622979449900740611 обѣщано). Дѣвочка https://danbooru.donmai.us/posts/5942697 в первоисточнике занимает 18,9 мегабайта — результат ея XYB-переужатия прилагаю. Иными словами, проблема >>199139 устранена. Обладателям мобильных версий Файерфокса (или предшествующих Firefox 108) соболезную.
Я попробовал повторить результат https://410chan.org/b/arch/res/158687.html#158731 (чуть болѣе, чѣмъ двухлѣтней давности) при помощи современной версии libwebp (версии 1.3.0) и увидал четыре обстоятельства: ① При тогдашнем качестве («-q 1.186») файл получается чуть больше (19 940 байтов, а было 19 696 байтов). ② Такая точность качества не очень нужна, потому что при «-q 1.18» и даже при «-q 1.2» файл получается того же объёма (и внутренне тот же самый). ③ По всей видимости, этот объём предшествует волне обратной зависимости объёма файла от показателя качества, потому что при «-q 1.25» файл получается меньшего объёма (19 782 байта). ④ Слѣдовательно, ещё далѣе наращивая качество картинки и достигнув того момента, когда эта волна заканчивается, можно получить файл WebP съ замѣтно бóльшим показателем качества («-q 1.34»), но по своемý объёму (20 244 байта) этот WebP (который прилагаю) всё ещё будет меньше, чѣмъ шакальный JPEG https://410chan.org/b/arch/res/158687.html#158719 ⑤ Притом же этот WebP по своемý показателю качества (1,34) оказывается идентичен примѣру https://410chan.org/b/arch/res/158687.html#164965 и отличается от него только номером препроцессора (тут 5, а там 4, то есть простой «sharp_yuv») и немного объёмом файла (тут 20 244 байта, а там 20 200 байтов), так что визуальное сравнение того и другого позволяет наглядно оцѣнить (при отсутствии других важных отличий) только пользу того дополнительного сглаживания сегментов (segment-smoothness), которое отличает пятый препроцессор от четвёртого, да ещё и цѣну этой пользы (то есть не похѣрились ли нѣкоторые области картинки тѣмъ сглаживанием).
Достижение >>201744 притом позволяет невозбранно показать на 410чане, чего достигает при сжатии того же исходного изображения кодировщик jpegli, работающий в режиме создания файлов JPEG въ цвѣтовомъ пространстве XYB. Вызов команды «cjpegli --xyb --distance=18.03 --chroma_subsampling=420» (дополненной через пробѣлъ именами исходного файла и результата) создаёт XYB JPEG объёмом 20 261 байт, который прилагаю. По сравнению с шакальным JPEG https://410chan.org/b/arch/res/158687.html#158719 получилось на байт больше, а по сравнению с MozJPEG https://410chan.org/b/arch/res/158687.html#158729 получилось на два байта меньше. Сравнение с MozJPEG показывает громадный рост качества большинства мелких деталей и плавных цвѣтовыхъ переходов, достигнутый при ≈равном объёме файла. Естественно, при таком сильном сжатии качество WebP (не говоря уж об AVIF) по-прежнему остаётся недосягаемым для формата JPEG, однако в рамках этого формата создатели jpegli бесспорно достигли новой вершины соѿношенія качества и объёма файла.
Посмотрел, как замечательно сжимает https://avif.io/ в лосслесс режиме (rav1e в браузере через WASM), решил почитать подробнее. Во-первых, оказалось, что rav1e в принципе не поддерживает lossless-сжатие, несмотря на вводящую в заблуждение галочку https://github.com/xiph/rav1e/issues/151 >avif.io does not actually produce lossless AVIF images, as its rav1e encoder doesn't currently support lossless mode, so it employs chroma subsampling which has the effect of producing a much smaller image А во-вторых, узнал, что lossless-режим у AVIF-формата весьма специфичный: иногда сжимает хуже, чем lossless у WebP, а кроме того, он ещё и не настоящий – для тех случаев, когда на вход подаётся картинка в цветовом пространстве RGB, т.к. происходит конвертация в YUV с неизбежными потерями. https://github.com/AOMediaCodec/av1-avif/issues/111#issuecomment-717710961 тл;др: >Neltulz: >AVIF lossless isn't even true lossless, since it requires the image be converted to yuv4:4:4 or yuv4:2:0, which means if your image is originally RGB, you're incurring a lossy conversion just by changing from RGB to YUV. I've heard of ways in which the image can be losslessly converted between RGB and YUV, but that is unorthodox and I do not recommend it. >leo-barnes: >You may want to take a look at issue https://github.com/AOMediaCodec/av1-avif/issues/89 >With that fix in place, doing fully lossless coding with a modest compression ratio gain should be possible. >Neltulz: >What AVIF needs, is a way for it to detect input colorspace, and store the image losslessly in that color space. Pick the right lossless compression format that best suits the job. That means, that AVIF is going to bloat in complexity as it tries to please every color space possibility. At that point, we need a dedicated lossless image format that isn't AVIF to avoid AVIF ballooning into an even bigger kitchen sink format than WebP. Adding support for all of this is just going to add complexity to decoding and make it difficult for developers to keep up with the advancements of AVIF. >It's my opinion that AVIF should have the lossless compression method removed completely (since it's stupid and encourages people to waste a bunch of time encoding in an inferior lossless format), and make room for an actual lossless image format that supports multiple color spaces and picks the best lossless compression method for the job, supports multiple bit depths, and HDR.
>>201781 По-моему, идея «lossless AVIF в принципе никогда не lossless» слишком далеко уклонилася ѿ дѣйствительности. (Если желаете неопровержимо доказать правоту этой идеи хотя бы в одном частном случае, не говоря уж про «никогда», то тогда попробуйте обнаружить такой исходный файл, который не выдержит провѣрку «magick compare -metric ae исходный.png результат.avif nul» опосля преобразования «avifenc --jobs 8 --codec aom --speed 0 --lossless исходный.png результат.avif», напримѣръ.) Словосочетание «происходит конвертация в YUV» обычно означает «из значений RGB по опредѣлённымъ формулам получают значения YUV — съ нѣкоторою неточностью, если при этом не наращивать разрядность», это я понимаю. Однако в случае AVIF это скорѣе означает «значения RGB тупо засовывают в алгоритм, предназначенный для сжатия значений YUV без потерь — на выходе получают значения RGB, сжатые без потерь, однако степень сжатия хѣровенькая, потому что алгоритм разрабатывался не для RGB». По крайней мѣрѣ, именно так я понял словосочетание «lossless RGB today sends the color channels through a video format designed for YCbCr» и дальнѣйшее объяснение пользы YCgCo-R в комментарии https://old.reddit.com/r/AV1/comments/kupvvl/firefox_will_support_the_avif_image_format_based/givfb5h/ (автор которого представился экс-сопредседателем группы разработчиков формата, и вроде как с начала 2021 года никто его там не успѣлъ обвинить в самозванстве — должно быть, и впрямь экс-сопредседатель). С точки зрения формата такое засовывание (RGB на мѣсто YUV) выглядит как употребление нулевого номера матричных коэффициентов (из числа тѣхъ номеров, которые приводятся в таблице №4 на странице №12 в документе Rec. ITU-T H.273 июльской версии 2021 года, со страницы https://www.itu.int/rec/T-REC-H.273-202107-I/en скачиваемой). Этот номер означает «ваши координаты пикселов — это не YUV, а RGB или XYZ». Автор комментария https://github.com/AOMediaCodec/av1-avif/issues/129#issuecomment-1206821544 утверждал даже, что новые кодовые номера (среди которых и номер для YCgCo-R) непремѣнно вскорѣ одобрены будут ко включению в ту таблицу. (Вот только утверждал он это в августе прошлого года — а воз, говоря словами баснописца Крылова, и нынѣ тамъ.) На всякий случай напоминаю, что YCgCo-R является трёхмерным пространством яркости-зелёности-оранжевости, преобразование из которого в RGB и обратно не приводит к потерям, однако для той безпотерьности требуется минимальный (однобитовый) рост размѣрности зелёности и оранжевости по отношению к остальным координатам. (То есть если координаты RGB восьмибитны, то яркостная координата Y также может быть восьмибитною, а вот координаты Cg и Co должны быть девятибитными, поскольку могут быть отрицательными. Напримѣръ, если R=10 и B=220, то тогда Co = R−B = −210.) Корпорация Microsoft по адресу https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/2008_ColorTransforms_MalvarSullivanSrinivasan.pdf излагает всю необходимую математику. По адресу https://spie.org/Publications/Proceedings/Paper/10.1117/12.797091 сказано, что это изложение впервые опубликовано в сентябре 2008 года, так что въ нынѣшнемъ (2023) году это пространство сможет справлять пятнадцатилѣтіе. Польза использования YCgCo-R в AVIF заключается в том, что это пространство гораздо болѣе YUV-подобно, так что алгоритм сжатия, совершаемого без потерь, должен лучше работать в нём по сравнению съ нынѣшнею обработкою сырых RGB, которая обеспечивает очень малое и недостаточное сжатие. Таблица https://docs.google.com/spreadsheets/d/1DHJ0TajtxWDV6bfLwIZPHztxDuB3x3SS-HZ2Yi3sbRc (которую автор вышеозначенной реплики, в сабрэддите /r/AV1 выложенной, привёл с упоминанием неназванной подгруппы разработчиков, работу которой подытоживал Derek Buitenhuis из Vimeo), вроде бы подтверждает собою утверждение «должен лучше работать». Диаграммы из этой таблицы прилагаю скриншотом. (Внимание в них надо обращать на величину зелёного столбика.) Само по себе наращивание битности на один бит, необходимое для YCgCo-R, не сдѣлается помѣхою для роста степени сжатия, потому что нынѣшній алгоритм сжатия без потерь, заложенный в AVIF (и ниже в AV1), сам по себе вроде бы предусматривает наращивание битности на один бит, по крайней мѣрѣ, при нѣкоторыхъ операциях. (Такое впечатление создаётся при чтении https://aomediacodec.github.io/av1-spec/av1-spec.pdf на странице 296 из 669.) Сразу скажу ещё, что есть и альтернативное мнѣніе https://twitter.com/jyzg/status/1477305288961282058 о том, что алгоритм сжатия в AVIF в принципе не очень годится для сжатия статических изображений (даже совершаемого с внесением потерь).
Опосля правок, внесённых в исходный код cjpegli 12 мая, результат >>201776 достигается при «--distance=18.11» вмѣсто «--distance=18.03».
Анимированные AVIF теперь поддерживаются во браузере Mozilla Firefox (начиная с версии Firefox 113). Нетрудно видѣть, что ожидание >>199930 подходит к концу только теперь. По адресу https://t.me/ReadMithgol/628 я сообщаю нѣкоторыя подробности этого, а тут прилагаю растровую копию этого сообщения.
По адресу https://github.com/ImageOptim/gifski/issues/298 явствуетъ (скринъ-шотъ прилагаю), что авторъ gifski умудрился собрать очередную версію такимъ образомъ, чтобы она не работала на процессорахъ ранѣе Haswell, да ещё и не пересобиралъ двѣ недѣли опосля того, какъ ему сообщили объ этомъ — можетъ быть, и не пересоберётъ никогда, никогда. Ѽ, етить.
>>202084 Ну, в первом мире процессор из 20-х, который мощнее твоего IvyBridge, наверняка стоит меньше, чем один тамошний МРОТ. А один Haswell-овский i7 даже до российского МРОТа не дотягивает по цене. https://www.ozon.ru/product/protsessor-intel-core-i7-4790-haswell-3600mhz-lga1150-l3-8192kb-oem-oem-bez-kulera-280710291 Возможно, и тебе настала пора обновиться.
>>202085 Да-да, разумѣется, цѣна обновленія равняется стоимости новаго чипа Haswell — зачѣмъ же учитывать то обстоятельство, что чипы Haswell (и затѣмъ Broadwell) нуждаются въ сокетѣ LGA 1150, тогда какъ чипы Ivy Bridge (и до нихъ Sandy Bridge) использовали сокетъ LGA 1155, что исключаетъ простую возможность втыканія одного вмѣсто другого, так что придётся поневоле перемѣнять и процессоръ, и материнскую плату, и оперативную память, и видеокарту, и дисплей, и операціонную систему, и всё это въ обстоятельствахъ дѣятельнаго вооружённаго международнаго противостоянія (силою котораго настала полная жопа и съ цѣнами, и съ ассортиментомъ, и съ покупательною способностью денегъ, и съ гарантіей производителей, и съ побужденіемъ производителей дистанціонно отключать свои продукты или заставлять ихъ «работать» вредоносно) и притомъ ещё при отсутствіи ясности по вопросу о томъ, какая система WCG и особенно HDR восторжествует (всё равно что покупать приводъ HD DVD въ 2006 году, который въ 2008 году пришлось бы выбросить и покупать блюрэевый, или всё равно что до появленія приводовъ DVD±RW купить аппаратную реализацію только одного формата — но разница въ томъ, что хорошій комплектъ монитора и видюхи неизбѣжно тогда обойдётся гораздо дороже любого оптическаго привода и притомъ потребует, можетъ быть, очередного обновленія операціонной системы, во всёмъ подобнаго послѣдствіямъ прежняго рѣшенія Корпораціи Microsoft не притащить HDR въ семёрку), и при почти полной гарантіи черезъ пару лѣтъ остаться за порогомъ новыхъ техническихъ требованій не только игровой, но и всякой другой виртуальной реальности или какихъ-нибудь стереопанорамныхъ видеозаписей 8K, ёптъ.
>>202096 размазывает_по_стенке.гиф
>>202096 > и оперативную память Haswell поддерживает DDR3. > и видеокарту Тоже не факт. Но мне это лень гуглить. > и дисплей Это-то почему? VGA провод в новый комп тык, HDMI провод в новый комп тык, и готово. > и операціонную систему Можно старый диск в новый комп воткнуть, хотя, возможно, винда будет ругаться про активацию из-за другого отпечатка устройства, а дополнительные дрова через прокси придётся качать. > всё это въ обстоятельствахъ дѣятельнаго вооружённаго международнаго противостоянія (силою котораго настала полная жопа и съ цѣнами, и съ ассортиментомъ, и съ покупательною способностью денегъ, и съ гарантіей производителей, и съ побужденіемъ производителей дистанціонно отключать свои продукты или заставлять ихъ «работать» вредоносно) Цена того цп на ОЗОНе говорит, что жопа, к счастью, частично продолжает оставаться по-детски сексуальной. > и при почти полной гарантіи черезъ пару лѣтъ остаться за порогомъ новыхъ техническихъ требованій не только игровой, но и всякой другой виртуальной реальности или какихъ-нибудь стереопанорамныхъ видеозаписей 8K, ёптъ Ну, ты уже за порогом. Первые звоночки, во всяком случае, явно есть. Так что смотри. Жопа в любой момент может стать по-настоящему взрослой, жирной и толстой. Может быть, стоит сменить шило на чуть более свежее мыло. Может, (спустя какое-то время) стоит на что-то действительно хорошее раскошелиться.
>>202099 Поясняю: видеокарту и оперативную памѧть (и всё прочее въ этомъ спискѣ) понадобится перемѣнить потомý, что ужъ если достигнута необходимость вмѣстѣ съ процессоромъ замѣнить и материнскую плату, то тогда получается, что вмѣшательство въ аппаратное обеспéченіе выглядит такъ значительно, что ужъ почему бы и не перескочить сразу на сáмыя новыя модели ихъ. А не то получается вздоръ: купить Haswell и мать его только для того, чтобы работала новая версія gifski? — она того не стóитъ по величинѣ своихъ новинокъ, такъ что можно и на 1.10.0 далѣе сидѣть.
Остановитесь.
>>202137 Сколько времени на замазку-то ушло. Тяжело тебе, поди, на Чиочане сидеть.
>>202137 Вы пользуетеся ядрами Yonah пятнадцатилѣтней давности? — очень сочувствую, но ориентироваться на их возможности при создании видеороликов я не буду, потому что тогда в 410чановские 5000 килобайтов ни одной сколько-нибудь продолжительной видеоцитаты не помѣщу, поневоле пришлось бы самоограничиваться двузначным числом секунд. Очень далёкими от дѣйствительности выглядят процитированные на этом же скриншоте воззрѣнія человѣка, который очень сильно сконцентировался на произвольных алфавитных ассоциациях: ранѣе усвоенное название формата TIFF (с двумя «F») мѣшаетъ ему правильно записать название формата «AVIF» (с одной «F»), ранѣе усвоенное сокращение «WP9» принуждает его всякий раз при виде названия формата «VP9» вспоминать и упоминать Windows Phone 9, причём непремѣнно записывая с нарочно внесёнными ошибками («шиндуспхоне9») под давлением окружающей его на Абучане массы быдла, а формат WebP он называет не иначе как «вебрепа» или «вебрепка» (я даже не собираюсь формулировать и высказывать догадку о причинах этого), однако при этом нифигушеньки не понимает, как работает механизм патентных отчислений и почему крупные сайты отказываются от поддержки HEVC. За предѣлами этого скриншота он же пишет «HEIFF» с двумя «F», всерьёз считает анимированные PNG неподдерживаемым форматом, опосля появления gifski создаёт GIF другими средствами и вообще ведёт себя как человѣкъ совершенно невежественный и даже с лёгкою припиздью. Беспрерывною нецензурщиною он стремится замаскировать разрыв между дѣйствительностью и собою, но тот слишком значителен для этого устремления.
