А известно ли вам не сильно распространенное, но тем не менее, мнение, что ресайзить иконки — это «фу»?
Как мне недавно стало известно, истинные эстеты иконок ресайзят их исключительно в векторе, с привязкой к координатной сетке пикселей. Что это даёт? — pixel fitting, резкие края вертикальных/горизонтальных линий.
Господа разработчики под Андроид редко грешат качеством, но вы всё таки присмотритесь внимательней к тому же material design-у, и к разнице между тем, получается у вас при ресайзе и тем, что лежит у них в пакетах.
Не совсем понятно, о какой коррекции ошибок идет речь. О, да, я вижу что в алгоритме она присутствует, но я повредил кусочек вашего «hello world», и матрицу уже ни одна программа распознать не сумела. А вот с QR-кодом этот фокус проходит без проблем.
У него беспроблемные самые древние и самые свежие релизы — с ними-то как раз всё в порядке.
А вот те, что посерёдке — там как раз это экспериментальное безобразие и включено.
Дайте-ка угадаю — очередной «привет» от m0nkrus-а? Он, конечно, парень хороший, но вредный, как Баба Яга. И когда народ критиковал его идею с патчем ядра, он никого и слушать не стал. А зря.
На мой взгляд, если приходят только плохие «специалисты» — мала зарплата. У меня как раз был такой случай: начальство стало в позу и сказало «больше чем N не заплатим»; в результате я месяц интервьюировал невежд и психов, но так и не подобрал достойного человека.
Это самое «ужимание», оно не полностью роботизированный процесс, там нужно прикладывать ручки и время. Хочешь попрактиковаться? Местный пользователь x128 выложил свою среду для оптимизации — CQ, но пользоваться ею желающих немного.
Дружище, я понимаю, что тебя зело прёт, когда наши соотечественники чего либо «достигают», но здесь это выглядит, мягко говоря, не очень уместно.
Дело в том, что многоцветные gif-ы умели делать ещё ископаемые утилиты вроде «GIF Construction Set». А из современного их создаёт, например, тот же бесплатный CQ.
Напомню, что для Виндовоза среди прочих программ есть возможность запустить пакетную обработку в Color Quantizer'е, а он, CQ, судя по результатам тестов, входит в первую десятку оптимизаторов PNG в мире.
Ограничения — пакетная оптимизация JPEG-ов пока не поддерживается, только PNG.
Народ, как оно?
У меня работает просто никаковенно. Я бы даже сказал, «скорее не работает, чем работает».
Вопрос — я где-то ошибаюсь, или оно так альфочкой и осталось?
UPD: Пункт (2) таки ошибочен, зацикливание в APNG есть, в удовлетворительном виде.
А пункт (1) наоборот, требует более расширенной трактовки. Оказывается, среди всего прочего APNG не умеет чередовать кадры с разной глубиной цвета; реализация этой возможности ничего не стоила бы авторам формата, но позволила бы легко экономить размер при сжатии анимации.
Резюмирую — грамотная реализация стандарта, подобного APNG, может улучшить сжатие статических картинок (в некоторых случаях, по прикидкам, до 15% экономии); текущая реализация APNG этого не позволяет.
Давайте я всё-таки черкну пару строк о том, чем плох APNG, и почему было бы скверно, если бы его приняли стандартом.
1). Палитры. В отличие от gif, для анимаций с палитрой НЕ поддерживается режим «у каждого фрейма своя палитра». Это здорово сужает спектр применения анимации, и приводит к смешному результату, когда некоторые анимированные gif-ы оказываются компактнее в оригинале, чем те же мультики, закодированные в apng и вынужденные применять 24-битный цвет. Почему авторы не учли эту почти очевидную вещь — загадка природы.
2). Зацикливание. {Не проверено!} Плохое управление зацикливанием анимации. Якобы, у gif-a и тут больше возможностей: в частности, у gif-ов есть забавнейший режим «прокрутить анимацию один раз и остановиться», а тут его нет. Кстати, напомню, комбинация из «у каждого фрейма свой цвет» + «прозрачность не затирает картинку, что была снизу» + «прокрутить анимацию только один раз» позволяет записывать многоцветные gif-ы, которые (сюрприз!) иногда оказываются даже компактней размерами, чем «однослойный» PNG.
3). Перспективы. Вы можете спросить: «зачем тебе такие экзотические свойства?» и вот что я вам отвечу: формат PNG изначально ущербен (я сейчас объясню, не торопитесь нервничать) — он абсолютно не рассчитан на эффективное сжатие больших по площади изображений. Видимо, его авторы просто не предполагали, что в этом возникнет необходимость, ведь дело было довольно давно.
Итак, из-за того, что «фильтры» PNG применяются к строкам целиком (всегда!), мы наблюдаем унылую картину сжатия; пример: берём большую картинку с разнообразным наполнением, режем её на несколько частей, и сжимаем «большую» картинку, а затем разрезанные части по отдельности, и с удивлением замечаем, что «разрезанные» картинки в сумме заняли меньше места, чем большая картинка.
Здесь и может помочь анимация — предположим, каждая из разрезанных частей хранится в отдельном фрейме, и сжимается по отдельности, а затем из них, как из мозаики, собирается исходное статическое изображение. Впрочем, это скорее тема для отдельной статьи.
И тут появляется вопрос — есть весьма перспективные идеи по доработке apng (так сказать, apng v2), включающие в себя как решение вопросов (1) и (2), так и другие «полезняшки»; так вот — к кому обращаться в этими идеями? Что за люди утверждают подобные стандарты?
Господа! Приведенный пример в высшей степени не нагляден.
1) Давайте сразу учтем, что уж коль png срабатывает без потерь по этой картинке с коэффициентом сжатия 74%, то нет никакого смысла применять любой алгоритм сжатия с потерями, который отработает хуже (в статье заявлено сжатие 77%).
2) Поэтому, предлагаю выложить в комментариях образцы, подвергшиеся сжатию со степенью <20%. Это позволит наглядно оценить характер вносимых алгоритмом искажений, и сделать выводы о пригодности данного алгоритма «в реальной жизни».
Как мне недавно стало известно, истинные эстеты иконок ресайзят их исключительно в векторе, с привязкой к координатной сетке пикселей. Что это даёт? — pixel fitting, резкие края вертикальных/горизонтальных линий.
Господа разработчики под Андроид редко грешат качеством, но вы всё таки присмотритесь внимательней к тому же material design-у, и к разнице между тем, получается у вас при ресайзе и тем, что лежит у них в пакетах.
Потому, что столь любимый толпой 2.0 уже в печенках сидит.
А вот те, что посерёдке — там как раз это экспериментальное безобразие и включено.
ну его в пень, разводить срач
Дело в том, что многоцветные gif-ы умели делать ещё ископаемые утилиты вроде «GIF Construction Set». А из современного их создаёт, например, тот же бесплатный CQ.
Ограничения — пакетная оптимизация JPEG-ов пока не поддерживается, только PNG.
У меня работает просто никаковенно. Я бы даже сказал, «скорее не работает, чем работает».
Вопрос — я где-то ошибаюсь, или оно так альфочкой и осталось?
А пункт (1) наоборот, требует более расширенной трактовки. Оказывается, среди всего прочего APNG не умеет чередовать кадры с разной глубиной цвета; реализация этой возможности ничего не стоила бы авторам формата, но позволила бы легко экономить размер при сжатии анимации.
1). Палитры. В отличие от gif, для анимаций с палитрой НЕ поддерживается режим «у каждого фрейма своя палитра». Это здорово сужает спектр применения анимации, и приводит к смешному результату, когда некоторые анимированные gif-ы оказываются компактнее в оригинале, чем те же мультики, закодированные в apng и вынужденные применять 24-битный цвет. Почему авторы не учли эту почти очевидную вещь — загадка природы.
2). Зацикливание. {Не проверено!} Плохое управление зацикливанием анимации. Якобы, у gif-a и тут больше возможностей: в частности, у gif-ов есть забавнейший режим «прокрутить анимацию один раз и остановиться», а тут его нет. Кстати, напомню, комбинация из «у каждого фрейма свой цвет» + «прозрачность не затирает картинку, что была снизу» + «прокрутить анимацию только один раз» позволяет записывать многоцветные gif-ы, которые (сюрприз!) иногда оказываются даже компактней размерами, чем «однослойный» PNG.
3). Перспективы. Вы можете спросить: «зачем тебе такие экзотические свойства?» и вот что я вам отвечу: формат PNG изначально ущербен (я сейчас объясню, не торопитесь нервничать) — он абсолютно не рассчитан на эффективное сжатие больших по площади изображений. Видимо, его авторы просто не предполагали, что в этом возникнет необходимость, ведь дело было довольно давно.
Итак, из-за того, что «фильтры» PNG применяются к строкам целиком (всегда!), мы наблюдаем унылую картину сжатия; пример: берём большую картинку с разнообразным наполнением, режем её на несколько частей, и сжимаем «большую» картинку, а затем разрезанные части по отдельности, и с удивлением замечаем, что «разрезанные» картинки в сумме заняли меньше места, чем большая картинка.
Здесь и может помочь анимация — предположим, каждая из разрезанных частей хранится в отдельном фрейме, и сжимается по отдельности, а затем из них, как из мозаики, собирается исходное статическое изображение. Впрочем, это скорее тема для отдельной статьи.
И тут появляется вопрос — есть весьма перспективные идеи по доработке apng (так сказать, apng v2), включающие в себя как решение вопросов (1) и (2), так и другие «полезняшки»; так вот — к кому обращаться в этими идеями? Что за люди утверждают подобные стандарты?
1) Давайте сразу учтем, что уж коль png срабатывает без потерь по этой картинке с коэффициентом сжатия 74%, то нет никакого смысла применять любой алгоритм сжатия с потерями, который отработает хуже (в статье заявлено сжатие 77%).
2) Поэтому, предлагаю выложить в комментариях образцы, подвергшиеся сжатию со степенью <20%. Это позволит наглядно оценить характер вносимых алгоритмом искажений, и сделать выводы о пригодности данного алгоритма «в реальной жизни».