• +1
    чем плох png

    PNG — формат для сжатия без потерь. Все, что в нем сохраняется, можно достать бит-в-бит. Соответственно, для данных с большим количеством энтропии он чрезвычайно не эффективен, потому что вынужден хранить все шероховатости и неровности исходного изображения. Фотографии как раз содержат большое кол-во энтропии.


    Форматы с потерями (такие как JPEG), наоборот, хранят лишь приближенное изображение оригинала, изменяя его таким образом, чтобы оно занимало меньший размер. В случае фотографий размер файла может быть меньше в десять раз без заметных глазу отличий в изображении.

    Ideal OS: перезагрузка десктопных операционных систем (часть 1)
  • +19

    «Господи, почему все так плохо работает! Оформлю-ка своё нытье как статью и прикреплю фотографию экрана в PNG, так будет намного лучше»

    Ideal OS: перезагрузка десктопных операционных систем (часть 1)
  • 0

    Я может быть глупость спрошу, но вот это предсказание нужно чтобы выбрать одну из двух ветвей выполнения. Если предсказание не сбылось, то результат работы с неверной веткой просто отбрасывается. Можно ли пойти сразу по двум веткам одновременно и отбросить результат работы той, что не сбылась?

    История предсказания переходов с 1 500 000 года до н.э. по 1995 год
  • 0
    браузеры и раньше нормально обрабатывали блоки в ссылках, даже во времена IE6;

    В Firefox 2, который вышел на 5 лет позже IE6, были серьезные проблемы с ссылками вокруг блоков

    Ссылки вокруг блоков
  • 0

    Ахаха. Но вы же так и не исправили то, что я вам прислал

    Снижаем цены на локальные SSD-накопители в «вытесняемых» инстансах и инстансах по требованию
  • 0
    Цена в большинстве регионов составит 0,80 долл. США за 1 Гб в месяц

    Поясните пожалуйста из чего складывается такая бешеная цена. За 500 Гб в месяц придется отдать $400. Это больше, чем стоимость одного накопителя Intel 3D NAND такого объема.

    Снижаем цены на локальные SSD-накопители в «вытесняемых» инстансах и инстансах по требованию
  • 0

    Померил на реальном железе с i5-4430:


    Текущая версия Pillow-SIMD 4.1.0


    2560×1600 → 26x16 bic      1002 op/s
    2560×1600 → 320x200 bic    630 op/s
    2560×1600 → 2048x1280 bic  153 op/s
    2560×1600 → 5478x3424 bic  40 op/s

    Pillow-SIMD с улучшениями, которые пока не вошли ни в одну версию:


    2560×1600 → 26x16 bic      1028 op/s
    2560×1600 → 320x200 bic    730 op/s
    2560×1600 → 2048x1280 bic  242 op/s
    2560×1600 → 5478x3424 bic  59 op/s

    Теоретический максимум по шине PCIe 3.0 16x


    2560×1600 → 26x16 bic      671 op/s
    2560×1600 → 320x200 bic    661 op/s
    2560×1600 → 2048x1280 bic  409 op/s
    2560×1600 → 5478x3424 bic  120 op/s
    Как я сделал самый быстрый ресайз изображений. Часть 3, числа с фиксированной точкой
  • 0
    Сравнить достаточно просто: скорее всего даже самая простая реализация в лоб на самой медленной карте последнего поколения (GF 1050) будет упираться только в шину. Скорость 16x PCIe 3.0 примерно 11 Гб/c. Для ресайза 2560*1600 → 320*200 по шине нужно прокачать примерно 16 Мб данных. Это будет примерно 690 операций/секунду.

    Результаты Pillow-SIMD 3.4 на одном ядре с AVX2 для той же операции с бикубическим фильтром — 175 операций/секунду. Сопоставимый по стоимости процессор для выбранной видеокарты будет 4-ядерный i5, то есть на всех ядрах теоретически будет 700 операций/секунду. На практике может быть немного поменьше: ресайз на двух ядрах дает двухкратный прирост, а вот для четырех ядер надо проверять.

    Другое дело, что на видеокарте можно сделать не только ресайз, а что-то еще интересное. Самый шик был бы делать на видеокарте декодирование из JPEG и других графических форматов, тогда было бы пофиг на скорость шины. Но что-то пока нет открытых кодеков популярных форматов. И даже те, что есть, требуют специально подготовленных джипегов, с рестарт-маркерами. С остальными форматами все еще хуже.
    Как я сделал самый быстрый ресайз изображений. Часть 3, числа с фиксированной точкой
  • –1

    И много вы знаете успешных проектов написанных на Python за те «много лет», что в нем не было сборки мусора?

    О том, как в Instagram отключили сборщик мусора Python и начали жить
  • 0

    Это плохая идея. При разных операциях при формировании конечного пикселя может учитываться разное количество исходных. При ресайзе будут учитываться 2×scale×W исходных пикселей, где scale — коэффициент уменьшения, а W — окно фильтра. При Гауссовом размытии до трех сигма в каждую сторону.

    Опасайтесь прозрачных пикселей
  • 0

    Да никто вам не мешает объеденить две операции, если у вас две операции. Просто в статье речь об одной операции, той, которая создает пролемы. В статье общий способ, вы даже сказали что формула та же. Вы же говорите «я знаю, как можно проще» и предлагаете частный.

    Опасайтесь прозрачных пикселей
  • 0
    Получается, это баг видеокарт.

    Что вы называете видеокартой? Видеокарта — это набор железа. Еще есть драйвера, графические API, ваш код шейдеров. Все это заставляет видеокарту работать так или иначе. Видеокарта делает то, что ей скажут. Статья о том, как заставить работать правильно.

    Опасайтесь прозрачных пикселей
  • 0

    Понял о чем вы. Растягивать текстуру 2*2 — это грубо говоря наложить градиент. И дизайнеру может хотеться, чтобы градиент шел из красного непрозрачного в зеленый прозрачный. При умножении такого трудно добиться. Но это не значит, что такое поведение без умножения — один из вариантов нормы. Нет, правильный скейлинг и субпиксельный рендеринг может быть только с умножением. А то, что вам иногда нужно другое поведение — это изобразительный прием. Изобразительные приемы бывают разные и вы можете реализовать их через шейдеры. К скейлингу это не будет иметь отношения.

    Опасайтесь прозрачных пикселей
  • +2

    Хранить можно и в памати. Но даже если для оптимизации загрузки хранить в файлах в таком же виде, то ничего страшного не случится: вы же будете знать, что это формат приумноженной альфы и будете выводить его правильно. Конечно, другие просмоторщики не будут этого знать и будут открывать так как у автора на рисунке, с черным. Если это например ресурсы игры, то это не страшно.

    Опасайтесь прозрачных пикселей
  • 0

    Соглашусь, значительно отличается. Не понимаю, что тут испорчено, это верный результат.

    Опасайтесь прозрачных пикселей
  • 0

    Зачем такой выбор, какой в нем смысл? О потере какой информации идет речь и при чем тут запись в файл, если мы говорим об обработке и выводе на экран?


    Давайте вернемся к вашему исходному утверждению: «теперь этот цвет будет мало того, что прозрачным, так еще и чернить и он будет некорректно орисовываться поверх белых поверхностей». В браузерах кроме Сафари background-градиенты строятся именно с помощью приумноженного альфаканала. Сделав градиент, например, от красного непрозрачного, к зеленому прозрачному, вы можете убедиться, что никакого черного там нет.

    Опасайтесь прозрачных пикселей
  • +2
    Не подскажете как перевести ARGB->RGB.

    Никак. Оно не «переводится». Вы можете наложить ARGB изображение на что-то (сплошной цвет или другое сплошное изображение), после чего альфа везде будет равна единице и тогда вы её сможете отбросить.

    Опасайтесь прозрачных пикселей
  • +2
    Посмотрите сами на его картинку-пример — эта картинка испорчена!

    Картинка тут конечно зря приведена, она только запутывает

    Опасайтесь прозрачных пикселей
  • +2
    То есть теперь этот цвет будет мало того, что прозрачным, так еще и чернить и он будет некорректно орисовываться поверх белых поверхностей!

    Это неправда. Premultiplied Alpha нужна для вычислений, а не для вывода на экран. Для вывода на альфу нужно обратно разделить. Когда вы после вычислений получите rgba(51,51,51,0.2) и разделите на альфу, вы получите обратно rgba(255,255,255,0.2).

    Опасайтесь прозрачных пикселей
  • 0

    В статье есть пример:


    Заметьте, как много в SIMD-коде приходится делать явно при загрузке значений. В скалярном коде ничего этого нет, компилятор сам понимает, что раз мы умножаем 8-битное целое на float, то первое тоже нужно конвертировать в float.
    Как я сделал самый быстрый ресайз изображений. Часть 2, SIMD
  • 0

    Нет, тут речь о любых 256-битных AVX инструкциях, т.е. AVX1 и AVX2.

    Как я сделал самый быстрый ресайз изображений. Часть 2, SIMD
  • +3
    Самый быстрый по сравнению с чем?

    Как вы понимаете, у меня нет возможности писать об этом в каждой части, поэтому специально для этого была написана часть 0.


    Звучит совсем не как «самый быстрый ресайз изображений» в мире.

    Совершенно верно. Звучит как «Как я сделал самый быстрый ресайз изображений. Часть 2». И каждое слово тут важно.

    Как я сделал самый быстрый ресайз изображений. Часть 2, SIMD
  • 0

    Таблица соответствия как раз по ссылке.

    Новый чип от Applied Micro готов потягаться с Intel Xeon
  • +1

    Grossws хочет сказать, что в статье ошибка и имеется в виду конечно же AVX-512, а не AVX. В сам AVX, конечно, ничего добавить не могут.

    Новый чип от Applied Micro готов потягаться с Intel Xeon
  • 0

    … или исключить из рандома цвета, близкие к фону (чёрному в данном случае).

    Безболезненная прививка объектного мышления
  • +4
    Место сейчас стоит копейки

    Ну да и вас есть выбор: разместить на этом месте в 5 раз больше фотографий или сохранить на память всё несовершенство матрицы, ошибки фильтр Байера и прочей постобработки, ведь это всё так важно, эти данные иначе уже потом не восстановить.

    FLIF – идеальный формат для изображений?
  • +1

    Спасибо за ссылку, очень интересно. Авторы не совсем утверждают, что «лучше джипега», они говорят:


    In our opinion, at low qualities and for photographs, dedicated lossy formats like WebP, JPEG or BPG still produce better results. However, at very high-quality, we think lossy FLIF is a better option.
    FLIF – идеальный формат для изображений?
  • +7
    Не во всех, не всегда. Но все типы изображений можно преобразовать, чтобы понять, стоит ли использовать FLIF для них.

    Зачем преобразовывать в Флиф фотографии, чтобы понять, стоит ли его использовать? Для фотографий он очевидно не подходит. И это не какой-то сложный синтетический случай, это на вскидку 80% существующих на земле изображений, хранящихся в файлах.

    FLIF – идеальный формат для изображений?
  • 0

    Y422 — это chroma subsampling? К данном формату не имеет никакого отношения, потому что во-первых он RGB, во-вторых, loseless.

    FLIF – идеальный формат для изображений?
  • +4

    Скажите, а больше вы подобных фраз в тексте не видите?


    FLIF – идеальный формат для изображений?
    Работает для любого типа изображений
    Преимущество FLIF заключается в том, что он хорошо работает для разных типов изображений.

    FLIF – идеальный формат для изображений?
  • +3

    Комон, вы пишете техническую статью на техническом ресурсе и признаете, что ваши слова ничего не значат. Т.е. вы намеренно вводите людей в заблуждение?

    FLIF – идеальный формат для изображений?
  • +1
    Прочитал статью еще два раза. Не увидел, кто я «предлагаю заменить Jpeg Флифом». Вы ничего не перепутали?

    Я ничего не перепутал. Я же процитировал место, где вы перечисляете для чего применяются разные форматы, а потом ваши слова: «Флиф хорошо работает для разных типов изображений». И если бы только я что-то перепутал, еще несколько человек не оставило бы комментарии в ключе «убийца JPEG».

    FLIF – идеальный формат для изображений?
  • +1

    Jpeg — формат сжатия с потерями. Меняя уровень потерь, который мы читаем приемлемым, мы можем получить результат хоть в 10 раз меньше, хоть в 100. FLIF — формат сжатия без потерь. Там даже в названии это написано. «Без потерь» значит не то, что «он такой клевый, что когда сжимает, не появляется потерь», а что он намеренно так сжимает, чтобы потерь не было. Это принципиально другой способ сжатия, нежели в джипеге. При всем желании мы не добьемся от Флифа приемлемого размера для многих типов изображений, где много деталей, но их сохранение один-в-один не требуется. А вы предлагаете заменить Jpeg Флифом.

    FLIF – идеальный формат для изображений?
  • +4
    WebP предлагает просто огромное множество функционала

    Мне так не показалось. Кол-во бит на канал фиксировано, конвертация в YCbCr обязательна, даже 2x2 chroma subsampling обязателен. Не очень-то много простора, чтобы разгуляться.

    FLIF – идеальный формат для изображений?
  • –2
    Для обычных фотографий, где можно допустить частичные потери, лучше подходит JPEG.

    Преимущество FLIF заключается в том, что он хорошо работает для разных типов изображений.

    @sunnybear, вы же разработчик WEBO, вы писали книгу по оптимизации сайтов в том числе изображений. Я не понимаю, как вы можете писать такую ахинею.

    FLIF – идеальный формат для изображений?
  • 0

    Lossless формат — идеальный формат для изображений? Что только не напишешь в погоне за просмотрами и комментариям.

    FLIF – идеальный формат для изображений?
  • 0

    *и плодят потоки, чтобы не ждать ответа от сервера.

    Реализация на Python многопоточной обработки данных для парсинга сайтов
  • 0

    Часто компилятор в Линуксе — часть операционной системы и обновляется только с ней. Релизы Убунты LTS, например выходят раз в 2 года и актуальны года 4.

    Как я сделал самый быстрый ресайз изображений. Часть 1, общие оптимизации