При всей необычности такой превьюшки, знающие о progressive JPEG и Adam7 у PNG могут ждать заметное время прогрузки изображения… я тоже ждал секунд 15, прежде чем понял в чём дело.~
Ты неправильно сохраняешь изображение с эффектом пикселизации. =) JPEG разбивает изображения на блоки 8х8 и проводит над ними квантизацию. Что для однородных квадратиков совершенно избыточно. А PNG как раз умеет обращаться с однотонными областями, к тому же, жмёт без потерь.
Ты только посмотри — 43,2 KiB (53,9 KiB без оптимизации)...
А твой постовой превьюшек имеет вес 305 КiБ (256 KiB с оптимизацией).
Во-вторых, супер-ответа от меня не жди, я там так, по-верхам бегал… могу что-то важное не знать или перепутать. Однако, приступим.
В качестве программы кодирования у меня на них, как и на всё прочее, Xvid4PSP. Поскольку у тебя линупс, наверное, отправлю тебя осваивать FFmpeg, прекрасная библиотека по кодированию всего медиа на свете.
В WebM можно для видео пихнуть кодек либо VP8 либо VP9. Последний я просто обажаю, это прекрасный кодек нового поколения. К сожалению, в честь новизны, у него совместимость похуже. Но не отчаивайся и на использовании VP8, он не очень сильно уступает AVC, который сейчас в основных оборотах.
Далее. Разница в качестве кодировния (на моём опыте) между предустановкми «Real Time» и «Good» что VP8 что у VP9 где-то в два раза. Разница в скорости, правда, куда побольше. А вот разница в качестве кодирования между «Good» и «Best» уже не очень большая, что-то около 15%. И при том «Best» намного медленее, потому считаю его задротством.
Как помню, у обоих VP-шек есть ещё твик на дополнительную обработку по скорости/качеству, выраженный значением от -16 до +16, включая 0. Так вот (на моём опыте) крутить его дальше +-4 не имеет особого смысла.
Режим битрейта, если возможно, ставь CQ (более продвинутый CRF, к сожалению, не завезли). Ставится примерно так. 18 — хорошее качество. 21 — среднее. 24 — терпимое. Также, для VP8 я бы прибавил 1-2 мысленно, таки видел у него закидоны с квантизацией. Ну и для «Real Time» 1-2 в плюс мысленно потому что кодек спешит, мылит малость.
Так. С моим знанием VP8-9 вроде всё.
Теперь о аудиокдеках. С ними примерно та же ситуация, Vorbis имеет лучше совместимость, Opus лучше качеством.
Конечно, если совместимость особо не нужна, стоит выбирать Opus.
Режим битрейта лучше VBR, то есть переменный, чтобы аудиокодек не толкался в заданном.
Теперь о примерных битрейтах аудио.
Для обоих кодеков оптимальным будет ~200 kbit/s. Ниже ~100 kbit/s и выше ~320 kbit/s делать не стоит. В первом случае искажений будет многовато, а во-втором, они уже и так почти неотличимы от lossless.
Можно забить и на ~1MiB. Я пояснил про этот трюк не потому что ужаснулся весу, а потому что считаю знание достойно интересным и ценным.
Критического перекоса по весу нет. Поэтому, всё же, считаю что сжатие является не символическим и просит оптимизации, а не наличия. Что же касается подхода «сжимай по-максимуму», то считаю его необязательным, при всей моей любви к оптимизации, она отнимает время и силы, за которые альтернативно можно было бы сделать что-то другое, например, ещё рисунков порисовать.
В первом случае, квадратики 24*24 пикселя сделал, на глаз… когда забыл уменьшить картинку, да. Когда уменьшил ширину до 1000 пикселей ширины (как у автора поста), уже подсчитал пиксели — квадратики 10*10 пикселей.
При просто хорошем сжатии (заюзаны лучшие настройки в XnView) PNG выходит 31,9 KiB. А JPEG (100, 4:4:4) 26,1 KiB. Лол.
Впрочем, я догадываюсь от чего это всё… Если квадратик попадает в один блок JPEG, то всё, вписан. А PNG сжимает построчно, хоть и с дельта-фильтрами. А то что jpge вдруг отстал, так в честь его фокусов по «сглаживанию артефактов», тут тупо кодировать надо по квадратам.
37 комментариев
При всей необычности такой превьюшки, знающие о progressive JPEG и Adam7 у PNG могут ждать заметное время прогрузки изображения… я тоже ждал секунд 15, прежде чем понял в чём дело.~
В общем синий экран смерти.) На рабочий стол что ли поставить.
Ты только посмотри — 43,2 KiB (53,9 KiB без оптимизации)...
А твой постовой превьюшек имеет вес 305 КiБ (256 KiB с оптимизацией).
Так получается 20,4 KiB (24,2 KiB без оптимизации) на PNG...
Только не говори про webm for retards, у меня линукс.
Во-вторых, супер-ответа от меня не жди, я там так, по-верхам бегал… могу что-то важное не знать или перепутать. Однако, приступим.
В качестве программы кодирования у меня на них, как и на всё прочее, Xvid4PSP. Поскольку у тебя линупс, наверное, отправлю тебя осваивать FFmpeg, прекрасная библиотека по кодированию всего медиа на свете.
В WebM можно для видео пихнуть кодек либо VP8 либо VP9. Последний я просто обажаю, это прекрасный кодек нового поколения. К сожалению, в честь новизны, у него совместимость похуже. Но не отчаивайся и на использовании VP8, он не очень сильно уступает AVC, который сейчас в основных оборотах.
Далее. Разница в качестве кодировния (на моём опыте) между предустановкми «Real Time» и «Good» что VP8 что у VP9 где-то в два раза. Разница в скорости, правда, куда побольше. А вот разница в качестве кодирования между «Good» и «Best» уже не очень большая, что-то около 15%. И при том «Best» намного медленее, потому считаю его задротством.
Как помню, у обоих VP-шек есть ещё твик на дополнительную обработку по скорости/качеству, выраженный значением от -16 до +16, включая 0. Так вот (на моём опыте) крутить его дальше +-4 не имеет особого смысла.
Режим битрейта, если возможно, ставь CQ (более продвинутый CRF, к сожалению, не завезли). Ставится примерно так. 18 — хорошее качество. 21 — среднее. 24 — терпимое. Также, для VP8 я бы прибавил 1-2 мысленно, таки видел у него закидоны с квантизацией. Ну и для «Real Time» 1-2 в плюс мысленно потому что кодек спешит, мылит малость.
Так. С моим знанием VP8-9 вроде всё.
Теперь о аудиокдеках. С ними примерно та же ситуация, Vorbis имеет лучше совместимость, Opus лучше качеством.
Конечно, если совместимость особо не нужна, стоит выбирать Opus.
Режим битрейта лучше VBR, то есть переменный, чтобы аудиокодек не толкался в заданном.
Теперь о примерных битрейтах аудио.
Для обоих кодеков оптимальным будет ~200 kbit/s. Ниже ~100 kbit/s и выше ~320 kbit/s делать не стоит. В первом случае искажений будет многовато, а во-втором, они уже и так почти неотличимы от lossless.
Всё.
«ты неправильно сжимаешь» («ты неправильно не сжимаешь»)
а во сколько раз конкретно это изображение уменьшилось-увеличилось для пикселей?)
Критического перекоса по весу нет. Поэтому, всё же, считаю что сжатие является не символическим и просит оптимизации, а не наличия. Что же касается подхода «сжимай по-максимуму», то считаю его необязательным, при всей моей любви к оптимизации, она отнимает время и силы, за которые альтернативно можно было бы сделать что-то другое, например, ещё рисунков порисовать.
В первом случае, квадратики 24*24 пикселя сделал, на глаз… когда забыл уменьшить картинку, да. Когда уменьшил ширину до 1000 пикселей ширины (как у автора поста), уже подсчитал пиксели — квадратики 10*10 пикселей.
JPEG, wJPG (обёртка для прекрасного jpge+leanify), 100 качества, 4:4:4, оптимизация opt_ep — 27,5 KiB
PNG, оптимизация opt_ep — 28,5 KiB
При просто хорошем сжатии (заюзаны лучшие настройки в XnView) PNG выходит 31,9 KiB. А JPEG (100, 4:4:4) 26,1 KiB. Лол.
Впрочем, я догадываюсь от чего это всё… Если квадратик попадает в один блок JPEG, то всё, вписан. А PNG сжимает построчно, хоть и с дельта-фильтрами. А то что jpge вдруг отстал, так в честь его фокусов по «сглаживанию артефактов», тут тупо кодировать надо по квадратам.
Благодарю, Шпрота. Ценный опыт. =)
МарсЛуна атакует!Очень годная пикча!
Ставлю лайк! =)
з.ы. Рисунок использован в качестве КДПВ для Полуночной Палитры № 267