homm
–1

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

homm
0

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

homm
0

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

homm
0
Получается, это баг видеокарт.

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

homm
0

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

homm
+2

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

homm
0

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

homm
0

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


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

homm
+2
Не подскажете как перевести ARGB->RGB.

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

homm
+2
Посмотрите сами на его картинку-пример — эта картинка испорчена!

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

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

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

homm
+1
homm
0

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


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

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

homm
+3
Самый быстрый по сравнению с чем?

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


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

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

homm
0

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

homm
+1

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

homm
0

https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512


Правда не понятно, что такое Purley

homm
0

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

homm
+4
Место сейчас стоит копейки

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

homm
+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.
homm
+7
Не во всех, не всегда. Но все типы изображений можно преобразовать, чтобы понять, стоит ли использовать FLIF для них.

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

homm
0

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

homm
+4

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


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

homm
+3

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

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

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

homm
+1

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

homm
+4
WebP предлагает просто огромное множество функционала

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

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

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

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

homm
0

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

homm
0

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

homm
0

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

homm
0

А можете объяснить на пальцах, почему так? Я вижу вот как:
Раз мы делаем брутфорс, чтобы найти оригинал сообщения для одного лишь SHA1 в среднем нужно будет перебрать 2⁸⁰ сообщений. Когда мы найдем хоть одно совпадение, мы можем проверить, удовлетворяет ли это сообщение хэшу MD5. Вероятность, что совпадет, будет 1/2⁶⁴. Т.е. нам надо будет проверить в среднем 2⁶⁴ сообщений, уже подошедших для SHA1, т.е. уже являющимися в среднем одним из 2⁸⁰ оригинальных сообщений. Т.е. в среднем лишь одно из 2⁸⁰×2⁶⁴ сообщений будет удовлетворять обоим хэшам.

homm
0
атака на их комбинацию — это 2⁶⁴+2⁸⁰

А не 264+80 ли?

homm
0

Понял, в чем проблема. В opencv координаты перевернуты и im.shape[0] — это высота изображения. Картинка сильно горизонтальная, поэтому downsampling_factor из начального комментария 0serg был сильно занижен. 0.3 действительно нормальное значение.


Тем не менее sigmaX получается такая же, производительностью я правильно намерил. Так что все равно получается в 15 раз медленнее. В OpenCV блюр не аппроксимация, но реализован очень хорошо и при сигме 3.9 работает со скоростью аппроксимации, а то и быстрее.

homm
0
Оптимальный уровень размытия

Оптимальный для чего? Я же говорю, что результат получается очень aliased.

homm
0
DistortNeo предлагает примерно такой вариант ресайза

Конечно же нет. DistortNeo предлагал «всё делать за один проход без использования промежуточного изображения». У вас тут добавляется еще два прохода для блюра. Но давайте все равно посмотрим на ваше предложение.


Это вполне жизнеспособный подход и он должен быть довольно быстрым

Он по определению не может быть более быстрым. Начну с того, что непонятно как вы задали extra_smoothing_factor = 0.3. При этом значении результат получается ну очень aliased. Так-то и в свертках можно сильно уменьшить радиус фильтра и получить то же самое по качеству и выигрышу в производительности. Так что давайте возьмем значение, когда результат более-менее похоже на бикубик.


extra_smoothing_factor = 0.8


Смотрите сами, GaussianBlur это тоже свертка. Радиус её равен 0.8 × W / w × ≈2.5, где ≈2.5 — коэффициент, на который opencv домножает сигму, чтобы определить границы GaussianBlur. Мне не известно точное значение, известно что для качественного блюра оно должно быть от 2 до 3.


Т.е. в вашем варианте происходит W×H сверток с радиусом W / w × 2. Если делать как я, то понадобится w×h сверток с радиусом W / w × 2. Ну очевидно же, что при уменьшении W×H >> w×h. Что и подтверждается практикой:


In [38]: im = Image.open('../pixar.jpg')
    ...: im.load()
    ...: %time im.resize((512, 214), Image.BICUBIC)
    ...: 
Wall time: 34.1 ms

In [39]: extra_smoothing_factor = .8
    ...: im = cv2.imread(r"../pixar.jpg")
    ...: %time im = cv2.GaussianBlur(im, (0,0), sigmaX=downsampling_factor*extra_smoothing_factor)
    ...: %time im = cv2.resize(im, (512, 214), interpolation=cv2.INTER_LINEAR)
    ...: cv2.imwrite(r"../pixar.cv2.03.png", im)
    ...: 
Wall time: 582 ms
Wall time: 1.39 ms
homm
+1

Спасибо вам большое! Как вы видите, меня больше интересует прикладная сторона и моих знаний недостаточно чтобы объяснить почему так правильно, а так неправильно. Но теперь у меня будет место, куда я смогу ссылаться.

homm
0

Когда исходное изображение разбивается на квадараты и берется среднее, это называется supersampling.

homm
0
такой способ вполне себе имеет право на жизнь

Спасибо большое. За сим предлагаю закончить.