[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Animapcha image [@] [?]
Тема   ( ответ в 185114)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM, WEBP размером до 5000 кБ.
  • Ныне 3076 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 получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
55 сообщений пропущено. Показаны 50 последних сообщений
No. 199716  
>>199659
No. 199717  
>>199657
Аплоадь на панду для фарма поинтов, выводи на деньги, являйся владельцем картинок с потёртых аккаунтов и до изменений контентополитики.
No. 199718  
>>199717
Какой такой вывод? Максимум голдстар купить. Девочке нашептали, что для голдстаров доступно больше галерей.
No. 199720  
>>199718
>баунти за галереи в hath/gold
Люди не глупыя, где-то сканлейтеры эти фантики в реальные денежные знаки всё-таки переводят.
No. 199930  
quote.webp - (426.66KB, 1149×4095)
199930
Во браузере Mozilla Firefox версии 111 ожидается возможность смотрѣть анимированные AVIF.

По адресу https://t.me/ReadMithgol/572 я разсмотрѣлъ это обстоятельство в ряду других улучшений той же версии.

(Растровую копию прилагаю.)
No. 200485  
screenshot.webp - (195.79KB, 1200×1130)
200485
По адресу https://twitter.com/FidonetRunes/status/1627660168119869442 я сообщил (скриншот прилагаю) о том, что теперь формат JPEG XL располагает кодировщиком, способным (с параметрами «--allow_expert_options --effort=10») сжать без потерь даже такие файлы PNG, которые прежде не были для него сжимаемыми, но что всё же для этих файлов lossless WebP достигает ещё меньшего объёма.
No. 200564  
screenshots.webp - (1.35MB, 1280×3454)
200564
По адресу https://t.me/ReadMithgol/587 я помѣстилъ краткое пояснение того, каким образом учёт рѣдкости тѣхъ клѣтокъ сѣтчатки, которыя ѿкликаются на синий цвѣтъ, позволил создателям формата JPEG XL (и кодировщика jpegli) сильнѣе сжимать изображения за счёт перехода к использованию цвѣтового пространства XYB.

Скриншот сообщения прилагаю совмѣстно с копиями скриншотов, к нему прилагавшихся в Телеграме.

Кто пожелает ретвитнуть, тому предлагаю https://twitter.com/FidonetRunes/status/1629019451487035394 ретвитнуть.
No. 200720  
Прилагаемый GIF (результат работы gifski) не желает циклически воспроизводиться у меня в Mozilla Firefox версии 110.0.1, хотя в IE11 всё в порядке.

Казалось бы, GIF как GIF, просмотрщиками (и XnView, и Honeyview) просматривается циклически, чего же недостаёт Файерфоксу, мать его, а?
No. 200762  
error.webp - (12.71KB, 899×154)
200762
>>200485
Эта штука валится на JPEGах.
No. 200764  
165634967879.webp - (109.79KB, 400×600)
200764
Похоже, что эту фичу в общем случае смысла использовать нет. Даже такую вот маленькую картинку cjxl, с прочими настройками из >>199642, кодирует 30 минут, в то время как с -e 9 та же картинка кодируется за 8 секунд. C --effort 10 картинка получается в 90991 байт, то бишь на 616 байт меньше, чем с -e 9.
No. 200808  
Когда Мицгол пересядет на десятку? Хотя бы LTSC 2021?

И да, Precure — дойная корова, не имеющая культурной ценности
No. 201039  
>>185114
Чё там с новерью?
No. 201046  
death.png - (865.04KB, 2840×1176)
201046
>>201039
Аватарки и суицид.
No. 201050  
>>201046
Но там же не только Уютный есть, в /b тоже какой-то актив наблюдается.
No. 201057  
>>201050
Это из /b как раз.
No. 201059  
>>201057
(0_0) Впрочем, Лина там завсегдатай, так что ничего нового.
No. 201097  
По адресу 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 для автоматического поиска таких сцен в видеозаписях (прежде всего в аниме), которые годятся для сохранения в виде бесшовных зацикленных анимаций.

Примѣръ такой анимации прилагаю.
No. 201098  
quote1.webp - (416.62KB, 1211×4096)
201098
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/602 прилагаю.
No. 201099  
quote2.webp - (359.89KB, 1141×4060)
201099
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/603 прилагаю.
No. 201100  
quote3.webp - (376.83KB, 1141×4096)
201100
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/604 прилагаю.
No. 201101  
quote4.webp - (371.78KB, 2044×4036)
201101
Растровую копию упомянутого сообщения https://t.me/ReadMithgol/606 прилагаю.

💢 Если изобилие таких прикладываний кого-нибудь бѣситъ и выглядит почти как флуд, то мягко напомню: пять послѣднихъ сообщений могли бы невозбранно смѣниться единственным, если бы 410чанъ поддерживал прикрѣпленіе нѣсколькихъ иллюстраций к одному сообщению.
No. 201143  
>>200808

https://youtu.be/sxXs0Yy5-0Y
No. 201187  
image.png - (428.83KB, 3840×984)
201187
>>201143
Всё плохое можно выключить в групповых политиках и службах (даже сторонний софт не понадобится), даже "назойливое по сравнению с прошлыми виндами" скачивание заплаток.
No. 201188  
image.png - (54.51KB, 686×636)
201188
P.S.
No. 201189  
Обновления на Винду выходят каждый второй вторник месяца (иногда первый). Это не так уж сложно проконтролировать.
А так, если уж он до сих пор сидит на 7, то может досидеть до конца её поддержки в Файрфоксе, а потом уже решать, что дальше делать.
No. 201193  
Главное верить.
No. 201526  
>>199139

> Быть может, настала пора пересмотрѣть эту настройку.

И пересмотрѣлъ: >>/dev/27058.
No. 201744  
Сегодня и впредь 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) соболезную.
No. 201775  
NICE BOAT noalpha_q1_34-pre5.webp - (19.77KB, 1920×1280)
201775
Я попробовал повторить результат 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), которое отличает пятый препроцессор от четвёртого, да ещё и цѣну этой пользы (то есть не похѣрились ли нѣкоторые области картинки тѣмъ сглаживанием).
No. 201776  
NICE BOAT noalpha_xyb18_03ss420.jpg - (19.79KB, 1920×1280)
201776
Достижение >>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 бесспорно достигли новой вершины соѿношенія качества и объёма файла.
No. 201781  
6489165.webp - (2.37MB, 2952×2031)
201781
Посмотрел, как замечательно сжимает 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.
No. 201786  
screenshot.webp - (19.83KB, 1748×418)
201786
>>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 в принципе не очень годится для сжатия статических изображений (даже совершаемого с внесением потерь).
No. 201788  
Опосля правок, внесённых в исходный код cjpegli 12 мая, результат >>201776 достигается при «--distance=18.11» вмѣсто «--distance=18.03».
No. 201795  
quote.webp - (643.55KB, 730×4096)
201795
Анимированные AVIF теперь поддерживаются во браузере Mozilla Firefox (начиная с версии Firefox 113).

Нетрудно видѣть, что ожидание >>199930 подходит к концу только теперь.

По адресу https://t.me/ReadMithgol/628 я сообщаю нѣкоторыя подробности этого, а тут прилагаю растровую копию этого сообщения.
No. 202084  
screenshot.webp - (49.77KB, 1280×1958)
202084
По адресу https://github.com/ImageOptim/gifski/issues/298 явствуетъ (скринъ-шотъ прилагаю), что авторъ gifski умудрился собрать очередную версію такимъ образомъ, чтобы она не работала на процессорахъ ранѣе Haswell, да ещё и не пересобиралъ двѣ недѣли опосля того, какъ ему сообщили объ этомъ — можетъ быть, и не пересоберётъ никогда, никогда.

Ѽ, етить.
No. 202085  
>>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
Возможно, и тебе настала пора обновиться.
No. 202096  
>>202085

Да-да, разумѣется, цѣна обновленія равняется стоимости новаго чипа Haswell — зачѣмъ же учитывать то обстоятельство, что чипы Haswell (и затѣмъ Broadwell) нуждаются въ сокетѣ LGA 1150, тогда какъ чипы Ivy Bridge (и до нихъ Sandy Bridge) использовали сокетъ LGA 1155, что исключаетъ простую возможность втыканія одного вмѣсто другого, так что придётся поневоле перемѣнять и процессоръ, и материнскую плату, и оперативную память, и видеокарту, и дисплей, и операціонную систему, и всё это въ обстоятельствахъ дѣятельнаго вооружённаго международнаго противостоянія (силою котораго настала полная жопа и съ цѣнами, и съ ассортиментомъ, и съ покупательною способностью денегъ, и съ гарантіей производителей, и съ побужденіемъ производителей дистанціонно отключать свои продукты или заставлять ихъ «работать» вредоносно) и притомъ ещё при отсутствіи ясности по вопросу о томъ, какая система WCG и особенно HDR восторжествует (всё равно что покупать приводъ HD DVD въ 2006 году, который въ 2008 году пришлось бы выбросить и покупать блюрэевый, или всё равно что до появленія приводовъ DVD±RW купить аппаратную реализацію только одного формата — но разница въ томъ, что хорошій комплектъ монитора и видюхи неизбѣжно тогда обойдётся гораздо дороже любого оптическаго привода и притомъ потребует, можетъ быть, очередного обновленія операціонной системы, во всёмъ подобнаго послѣдствіямъ прежняго рѣшенія Корпораціи Microsoft не притащить HDR въ семёрку), и при почти полной гарантіи черезъ пару лѣтъ остаться за порогомъ новыхъ техническихъ требованій не только игровой, но и всякой другой виртуальной реальности или какихъ-нибудь стереопанорамныхъ видеозаписей 8K, ёптъ.
No. 202097  
>>202096
размазывает_по_стенке.гиф
No. 202099  
1684901394036793.jpg - (244.51KB, 1592×982)
202099
>>202096
> и оперативную память
Haswell поддерживает DDR3.
> и видеокарту
Тоже не факт. Но мне это лень гуглить.
> и дисплей
Это-то почему? VGA провод в новый комп тык, HDMI провод в новый комп тык, и готово.
> и операціонную систему
Можно старый диск в новый комп воткнуть, хотя, возможно, винда будет ругаться про активацию из-за другого отпечатка устройства, а дополнительные дрова через прокси придётся качать.
> всё это въ обстоятельствахъ дѣятельнаго вооружённаго международнаго противостоянія (силою котораго настала полная жопа и съ цѣнами, и съ ассортиментомъ, и съ покупательною способностью денегъ, и съ гарантіей производителей, и съ побужденіемъ производителей дистанціонно отключать свои продукты или заставлять ихъ «работать» вредоносно)
Цена того цп на ОЗОНе говорит, что жопа, к счастью, частично продолжает оставаться по-детски сексуальной.
> и при почти полной гарантіи черезъ пару лѣтъ остаться за порогомъ новыхъ техническихъ требованій не только игровой, но и всякой другой виртуальной реальности или какихъ-нибудь стереопанорамныхъ видеозаписей 8K, ёптъ
Ну, ты уже за порогом. Первые звоночки, во всяком случае, явно есть. Так что смотри. Жопа в любой момент может стать по-настоящему взрослой, жирной и толстой. Может быть, стоит сменить шило на чуть более свежее мыло. Может, (спустя какое-то время) стоит на что-то действительно хорошее раскошелиться.
No. 202106  
>>202099

Поясняю: видеокарту и оперативную памѧть (и всё прочее въ этомъ спискѣ) понадобится перемѣнить потомý, что ужъ если достигнута необходимость вмѣстѣ съ процессоромъ замѣнить и материнскую плату, то тогда получается, что вмѣшательство въ аппаратное обеспéченіе выглядит такъ значительно, что ужъ почему бы и не перескочить сразу на сáмыя новыя модели ихъ.

А не то получается вздоръ: купить Haswell и мать его только для того, чтобы работала новая версія gifski? — она того не стóитъ по величинѣ своихъ новинокъ, такъ что можно и на 1.10.0 далѣе сидѣть.
No. 202137  
2.png - (99.65KB, 1238×1259)
202137
Остановитесь.
No. 202138  
3f63d95ed2373378a88667ff2691b23a.jpg - (269.46KB, 1300×1091)
202138
>>202137
Сколько времени на замазку-то ушло. Тяжело тебе, поди, на Чиочане сидеть.
No. 202144  
>>202137

Вы пользуетеся ядрами Yonah пятнадцатилѣтней давности? — очень сочувствую, но ориентироваться на их возможности при создании видеороликов я не буду, потому что тогда в 410чановские 5000 килобайтов ни одной сколько-нибудь продолжительной видеоцитаты не помѣщу, поневоле пришлось бы самоограничиваться двузначным числом секунд.

Очень далёкими от дѣйствительности выглядят процитированные на этом же скриншоте воззрѣнія человѣка, который очень сильно сконцентировался на произвольных алфавитных ассоциациях: ранѣе усвоенное название формата TIFF (с двумя «F») мѣшаетъ ему правильно записать название формата «AVIF» (с одной «F»), ранѣе усвоенное сокращение «WP9» принуждает его всякий раз при виде названия формата «VP9» вспоминать и упоминать Windows Phone 9, причём непремѣнно записывая с нарочно внесёнными ошибками («шиндуспхоне9») под давлением окружающей его на Абучане массы быдла, а формат WebP он называет не иначе как «вебрепа» или «вебрепка» (я даже не собираюсь формулировать и высказывать догадку о причинах этого), однако при этом нифигушеньки не понимает, как работает механизм патентных отчислений и почему крупные сайты отказываются от поддержки HEVC.

За предѣлами этого скриншота он же пишет «HEIFF» с двумя «F», всерьёз считает анимированные PNG неподдерживаемым форматом, опосля появления gifski создаёт GIF другими средствами и вообще ведёт себя как человѣкъ совершенно невежественный и даже с лёгкою припиздью. Беспрерывною нецензурщиною он стремится замаскировать разрыв между дѣйствительностью и собою, но тот слишком значителен для этого устремления.
No. 202177  
quote1.webp - (702.25KB, 783×4083)
202177
19 мая и 21 мая по адресу https://t.me/ReadMithgol/629 и https://t.me/ReadMithgol/630 и https://t.me/ReadMithgol/631 и https://t.me/ReadMithgol/632 и https://t.me/ReadMithgol/633 и https://t.me/ReadMithgol/634 и https://t.me/ReadMithgol/635 и https://t.me/ReadMithgol/636 я выложил своё собственное пространное рассуждение о том, как сайты иногда перегибают палку в ограничении качества изображений, и вслѣдствіе того перегиба их борьба против пользователей, движимая стремлением к экономии объёма файлов, заканчивается печальной ситуацией взаимного проигрыша.

Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/629 прилагаю.
No. 202178  
quote2.webp - (661.38KB, 766×4096)
202178
Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/630 также прилагаю.
No. 202179  
quote3.webp - (720.00KB, 781×4083)
202179
Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/631 также прилагаю.
No. 202180  
quote4.webp - (697.90KB, 772×4096)
202180
Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/632 также прилагаю.
No. 202181  
quote5.webp - (1.08MB, 1181×4096)
202181
Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/633 также прилагаю.
No. 202182  
quote6.webp - (629.66KB, 730×4096)
202182
Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/634 также прилагаю.
No. 202183  
quote7.webp - (967.32KB, 1593×4096)
202183
Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/635 также прилагаю.
Удалить сообщение []
Пароль  
[Mod]