Эта запись (одна или две таблицы квантования) может абсолютно не соответствовать тому качеству, которое есть у конкретного джипега. Можно легко сделать ужасный джипег, у которого качество будет 100%. Вы правы в том, что такая запись есть, вопрос лишь в том, насколько она верна.
А вот это место статьи очень интересное: «После любого последующего количества перекодирований с тем же качеством картинка не меняется.» Сколько раз пробовали это сделать? Пришлите пожалуйста исходный файл или ссылку на него, интересно попробовать.
Что касается «определённых условий», то можно их конкретно сформулировать в явном виде, чтобы можно было проверить на практике?
Таблицы квантования, которые хранятся в хидере джипега, показывают лишь то, как был сжат джипег в последний раз. Что было до этого — совершенно неизвестно. Этот файл уже могли десятки раз сжимать с разными параметрами, а может быть, это первое сжатие. В этом и есть существенная проблема джипега. Подразумевается, что оригинал хранится несжатым, а сжатая картинка используется неизменной. Если это не так, то потери накапливаются с каждым очередным пережатием и со временем качество джипега становится всё хуже.
Мы сделали измерения производительности библиотеки Fastvideo SDK для каждой стадии обработки RAW кадра на Jetson Nano. На GPU реализована схема обработки RAW кадров от камеры для получения RGB. Тесты с камерами сделаем в ближайшее время.
Есть разные варианты лицензирования SDK в зависимости от набора модулей и условий использования, а также есть порядок работы с заказчиками. Присылаете запрос, подробное описание задачи, что хотите получить, какое есть железо, как хотите интегрировать SDK в свой софт и т.д. Мы присылаем наше предложение.
Спасибо за информацию, мы у Вас тоже учимся :)
Будем использовать этот софт вместе с ценой для Amazon в качестве Price/Performance эталона для дальнейших разработок.
Если хранить несжатые изображения, то на это потребуется в 10-15 раз больше места. Размер памяти на Tesla V100 равен 32 ГБ. Так, конечно, было бы быстрее, но кажется, что для кеша мало места.
Сжатая картинка занимает 0.2-0.5 МБайт, память видеокарты не более 24 ГБ, так что прямо в GPU можно хранить не более 100 тысяч таких картинок. Если количество изображений для кеша имеет такой порядок, то можно попробовать. Правда, сэкономить удастся только на копировании в видеокарту, а это и так делается очень быстро через x16 PCIE-3.0, т.е. со скоростью порядка 10-11 ГБайт/с. Возможно, такой кеш лучше хранить на быстром диске где-то рядом.
Так сделайте измерения на 72 виртуальных CPU и покажите результат. Без умножений и экстраполяций. Мы показали как есть на реальном железе.
Стоимость будет меньше, а скорость ещё выше вот на этой видеокарте: www.nvidia.com/en-us/design-visualization/quadro/rtx-6000
Мы за пользователя ничего не решаем, я всего лишь сказал, что для 8 МПикс картинок производительность решения на видеокарте станет больше благодаря более высокому разрешению картинки. Это просто факт.
С интересом читал Ваши статьи про ресайз. Результаты очень интересные.
Спасибо за информацию, тут есть что обсудить.
1. Для видеокарты мы рассмотрели худший вариант, т.е. работу с изображениями небольшого разрешения, поскольку при этом видеокарта остаётся недозагруженной. Этот вариант является наилучшим для CPU, особенно если ещё предположить, что производительность будет расти линейно с увеличением количества ядер. Но нужно принимать во внимание и такие подробности:
а) В этом процессоре частота 3.5 ГГц только в турбо-режиме (в обычном 2.5 ГГц) и неизвестно, какая частота будет при максимальной загрузке. Это нужно проверять, без тестов нельзя.
б) 36 виртуальных ядер (18 реальных) — это отлично. Мы как раз сделали тесты с libjpeg-turbo и точно знаем, что умножение на 36 является излишне оптимистичным. Для декодирования джипегов в многопоточном режиме нужно умножать примерно на 20 для такого железа, но это тоже нужно проверять для всей схемы обработки, а не только для декодера.
2. Что касается цен, то в данном случае Tesla V100 — не оптимальный вариант, по стоимости сравнимый с последними CPU Intel Xeon. В этой видеокарте есть ядра для аппаратного ускорения нейросетей, которые в данной задаче никак не используются. Поэтому я и написал, что оптимальный по цене вариант можно выбрать для заданного набора параметров задачи, так что практически в любом варианте подойдут менее дорогие видеокарты. Тогда при корректном сравнении придётся взять более слабый CPU и ситуация станет совсем другой.
3. Мы сделали тест с ресайзом в 2 раза исключительно для удобства понимания, никакие упрощённые алгоритмы при этом не использовались. Чтобы тест показывал производительность с разных сторон, имеет смысл уменьшать картинку 1920х1080 не в 2-4 раза, а до разрешения 1919х1079 (можно до 1904х1071, чтобы не искажать отношение сторон). Тогда мы и увидим настоящую производительность ресайза. Когда делают ресайз 2560->320, то таким образом явно улучшают результат для CPU. Ситуация, когда нужен ресайз менее чем в 2 раза, вполне рабочая. У нас ресайз в 2 раза делается за 0.27 мс, а ресайз до 1919х1079 занимает 0.39 мс. Интересно, сколько получается на CPU?
как вы видите, для видеокарты при переходе от 2К к 1К производительность практически не растет
4. Действительно, при уменьшении не растёт, при увеличении — растёт. Мы как раз работаем на оптимизацией работы с маленькими разрешениями, так что точно будет быстрее. Возможно, в пару раз. А для картинок 4К производительность получается в разы больше, поскольку при таком разрешении можно загрузить видеокарту как следует.
5. Что касается предварительной подготовки изображений, то делать её придётся в любом случае. Пользователь запросто может прислать картинку на 8 или 12 МПикс, а сохранять её в таком виде не стоит. Поэтому придётся декодировать, ресайзить и кодировать в оффлайне. В этот момент мы и добавляем маркеры нашим кодером, а jpegtran обычно используется только в тех случаях, когда нужно добавлять маркеры без выполнения ресайза, т.е. очень редко. Если же не добавлять маркеры, а использовать исходное большое разрешение, то для такого случая производительность нашего решения будет ещё выше, если сравнивать с аналогичным решением на CPU.
Про OpenCV — это ошибка, исправлю.
Наши бенчмарки декодера были сделаны для рестарт интервала 2. Наилучший для нашего декодера рестарт интервал равен единице, но при этом размер файла может увеличиться до 15% по сравнению со случаем без маркеров, поэтому остановились на двойке.
Я знаю, что libjpeg-turbo считает в целых числах, но не думаю, что это правильно. Получается, что при кодировании приходится делать три округления, когда можно сделать только одно. То же самое происходит и при декодировании. Джипег не является беспотерьным алгоритмом именно из-за этих округлений, но ничего хорошего они не несут.
Дело в том, что дискретное косинусное преобразование выполняется не над всем кадром, а над каждым блоком 8х8 исходного изображения. Поэтому вряд ли можно в частотной области сделать ресайз для джипега с произвольным коэффициентом масштабирования. А для ресайза в степень двойки есть такой простой пример: компонент DC (пиксел с координатами 0,0 в блоке 8х8 после косинусного преобразования) является средней яркостью блока 8х8, но даже ресайз в 8 раз по ширине и высоте так делать нельзя, получится очень грубо. Такое усреднение даёт очень приблизительный результат и любой бикубик или ланцош сделает всё гораздо лучше.
В случае с JPEG2000, где по сути используется пространственно-частотное преобразование, ресайз в 2 раза по ширине и высоте — это компонента LL вейвлетного разложения, которая получается очень просто, но там разложение делают для всей картинки или для отдельного тайла, но не для блока 8х8.
Можно для начала посмотреть на рыночные доли NVIDIA и AMD — они сильно отличаются в пользу NVIDIA, т.е. таких карточек намного больше. Большой плюс NVIDIA в том, что у них есть полный спектр видеокарт — мобильные, для ноута/десктопа, серверные. Вот в этом документе есть впечатляющий список приложений на CUDA — www.nvidia.com/content/gpu-applications/PDF/gpu-applications-catalog.pdf
Приложений для CUDA не много, а очень много. К сожалению, никогда не видел аналогичного документа для OpenCL.
Универсальность OpenCL может являться преимуществом только для неоптимизированных решений. Как только захотите добиться максимальной производительности, сразу же придётся принимать во внимание особенности железа, т.е. универсализм OpenCL тут же исчезнет. Будет проприетарщина, но уже на OpenCL.
Обычно заказчик покупает рабочие станции для оптимизированных решений, а не наоборот. А срочно портировать OpenCL на CUDA вряд ли придётся: такая разработка и отладка обычно занимает много времени, поэтому лучше сразу подумать, на каком железе и где всё это будет работать. Конечно, есть ситуации когда это не так (например, случай с Маком), но я говорю о часто встречаемых, которых видел немало.
С моей точки зрения есть смысл изучать CUDA. Тем более сейчас, когда тематика по нейросетям и искусственному интеллекту явно на подъёме. По этой тематике приложений очень много и работы тоже.
В алгоритме JPEG есть несколько стадий, которые не стоит считать в целых числах: цветовое преобразование, дискретное косинусное и квантование. Мы их считаем с одинарной точностью.
Сравнить достаточно просто: скорее всего даже самая простая реализация в лоб на самой медленной карте последнего поколения (GF 1050) будет упираться только в шину. Скорость 16x PCIe 3.0 примерно 11 Гб/c. Для ресайза 2560*1600 → 320*200 по шине нужно прокачать примерно 16 Мб данных. Это будет примерно 690 операций/секунду.
Можно совместить копирования и вычисления с помощью CUDA Streams, тогда теоретический потолок пропускной способности поднимется в два раза, хотя на практике так быстро пока не получается. К тому же, очень часто алгоритм ресайза находится не в самом начале общей схемы обработки изображений и все данные уже находятся в памяти видеокарты, т.е. их никуда не нужно копировать. Поэтому мы для тестов производительности измеряем время работы алгоритма на GPU без учёта копирований.
Для проверки производительности алгоритма мы используем два теста: сжатие изображений 2К и 4К в 2 раза по каждой оси и уменьшение размеров изображения на 1 пиксел по ширине и по высоте. Во втором тесте размер данных почти не изменяется и для оценки производительности вычислений такой подход кажется более оправданным.
Другое дело, что на видеокарте можно сделать не только ресайз, а что-то еще интересное. Самый шик был бы делать на видеокарте декодирование из JPEG и других графических форматов, тогда было бы пофиг на скорость шины. Но что-то пока нет открытых кодеков популярных форматов.
Мы именно так и делаем, т.е. вся обработка изображений выполняется на видеокарте. Получается очень быстро и можно делать ресайз джипегов на лету, задавая индивидуальные параметры ресайза для каждой картинки. При этом скорость декодирования джипегов у нас чуть ниже, чем скорость ресайза. Здесь можно посмотреть наши бенчмарки для ресайза и декодирования.
И даже те, что есть, требуют специально подготовленных джипегов, с рестарт-маркерами. С остальными форматами все еще хуже.
Да, без рестарт-маркеров не получается параллельное декодирование джипегов (декодирование по Хаффману). Но можно без потери качества добавить рестарт-маркеры самостоятельно с помощью утилиты jpegtran. Рестарт-маркеры являются частью стандарта JPEG, так что это разумный и вполне официальный подход для решения задач быстрого декодирования.
Чтобы получить 25 к/с на 4К, нужны быстрые SSD, CPU, GPU. Значение 9 фпс может быть из-за того, что это HDD, хотя скорости карточки 680 можеть не хватать. Пожалуйста попробуйте быстрый SSD, если это возможно. Или пришлите пару кадров DNG, мы посмотрим в чём может быть дело. Функции ресайза и кропа на GPU есть, но они пока не выведены наружу, скоро это будет.
Группа вконтакте есть — vk.com/fastcinemadng
А вот это место статьи очень интересное: «После любого последующего количества перекодирований с тем же качеством картинка не меняется.» Сколько раз пробовали это сделать? Пришлите пожалуйста исходный файл или ссылку на него, интересно попробовать.
Что касается «определённых условий», то можно их конкретно сформулировать в явном виде, чтобы можно было проверить на практике?
Будем использовать этот софт вместе с ценой для Amazon в качестве Price/Performance эталона для дальнейших разработок.
Ок, округляйте после каждой стадии, как и libjpeg-turbo 2.0.
Стоимость будет меньше, а скорость ещё выше вот на этой видеокарте:
www.nvidia.com/en-us/design-visualization/quadro/rtx-6000
Мы за пользователя ничего не решаем, я всего лишь сказал, что для 8 МПикс картинок производительность решения на видеокарте станет больше благодаря более высокому разрешению картинки. Это просто факт.
Спасибо за информацию, тут есть что обсудить.
1. Для видеокарты мы рассмотрели худший вариант, т.е. работу с изображениями небольшого разрешения, поскольку при этом видеокарта остаётся недозагруженной. Этот вариант является наилучшим для CPU, особенно если ещё предположить, что производительность будет расти линейно с увеличением количества ядер. Но нужно принимать во внимание и такие подробности:
а) В этом процессоре частота 3.5 ГГц только в турбо-режиме (в обычном 2.5 ГГц) и неизвестно, какая частота будет при максимальной загрузке. Это нужно проверять, без тестов нельзя.
б) 36 виртуальных ядер (18 реальных) — это отлично. Мы как раз сделали тесты с libjpeg-turbo и точно знаем, что умножение на 36 является излишне оптимистичным. Для декодирования джипегов в многопоточном режиме нужно умножать примерно на 20 для такого железа, но это тоже нужно проверять для всей схемы обработки, а не только для декодера.
2. Что касается цен, то в данном случае Tesla V100 — не оптимальный вариант, по стоимости сравнимый с последними CPU Intel Xeon. В этой видеокарте есть ядра для аппаратного ускорения нейросетей, которые в данной задаче никак не используются. Поэтому я и написал, что оптимальный по цене вариант можно выбрать для заданного набора параметров задачи, так что практически в любом варианте подойдут менее дорогие видеокарты. Тогда при корректном сравнении придётся взять более слабый CPU и ситуация станет совсем другой.
3. Мы сделали тест с ресайзом в 2 раза исключительно для удобства понимания, никакие упрощённые алгоритмы при этом не использовались. Чтобы тест показывал производительность с разных сторон, имеет смысл уменьшать картинку 1920х1080 не в 2-4 раза, а до разрешения 1919х1079 (можно до 1904х1071, чтобы не искажать отношение сторон). Тогда мы и увидим настоящую производительность ресайза. Когда делают ресайз 2560->320, то таким образом явно улучшают результат для CPU. Ситуация, когда нужен ресайз менее чем в 2 раза, вполне рабочая. У нас ресайз в 2 раза делается за 0.27 мс, а ресайз до 1919х1079 занимает 0.39 мс. Интересно, сколько получается на CPU?
4. Действительно, при уменьшении не растёт, при увеличении — растёт. Мы как раз работаем на оптимизацией работы с маленькими разрешениями, так что точно будет быстрее. Возможно, в пару раз. А для картинок 4К производительность получается в разы больше, поскольку при таком разрешении можно загрузить видеокарту как следует.
5. Что касается предварительной подготовки изображений, то делать её придётся в любом случае. Пользователь запросто может прислать картинку на 8 или 12 МПикс, а сохранять её в таком виде не стоит. Поэтому придётся декодировать, ресайзить и кодировать в оффлайне. В этот момент мы и добавляем маркеры нашим кодером, а jpegtran обычно используется только в тех случаях, когда нужно добавлять маркеры без выполнения ресайза, т.е. очень редко. Если же не добавлять маркеры, а использовать исходное большое разрешение, то для такого случая производительность нашего решения будет ещё выше, если сравнивать с аналогичным решением на CPU.
Наши бенчмарки декодера были сделаны для рестарт интервала 2. Наилучший для нашего декодера рестарт интервал равен единице, но при этом размер файла может увеличиться до 15% по сравнению со случаем без маркеров, поэтому остановились на двойке.
В случае с JPEG2000, где по сути используется пространственно-частотное преобразование, ресайз в 2 раза по ширине и высоте — это компонента LL вейвлетного разложения, которая получается очень просто, но там разложение делают для всей картинки или для отдельного тайла, но не для блока 8х8.
Приложений для CUDA не много, а очень много. К сожалению, никогда не видел аналогичного документа для OpenCL.
Универсальность OpenCL может являться преимуществом только для неоптимизированных решений. Как только захотите добиться максимальной производительности, сразу же придётся принимать во внимание особенности железа, т.е. универсализм OpenCL тут же исчезнет. Будет проприетарщина, но уже на OpenCL.
Обычно заказчик покупает рабочие станции для оптимизированных решений, а не наоборот. А срочно портировать OpenCL на CUDA вряд ли придётся: такая разработка и отладка обычно занимает много времени, поэтому лучше сразу подумать, на каком железе и где всё это будет работать. Конечно, есть ситуации когда это не так (например, случай с Маком), но я говорю о часто встречаемых, которых видел немало.
С моей точки зрения есть смысл изучать CUDA. Тем более сейчас, когда тематика по нейросетям и искусственному интеллекту явно на подъёме. По этой тематике приложений очень много и работы тоже.
Можно совместить копирования и вычисления с помощью CUDA Streams, тогда теоретический потолок пропускной способности поднимется в два раза, хотя на практике так быстро пока не получается. К тому же, очень часто алгоритм ресайза находится не в самом начале общей схемы обработки изображений и все данные уже находятся в памяти видеокарты, т.е. их никуда не нужно копировать. Поэтому мы для тестов производительности измеряем время работы алгоритма на GPU без учёта копирований.
Для проверки производительности алгоритма мы используем два теста: сжатие изображений 2К и 4К в 2 раза по каждой оси и уменьшение размеров изображения на 1 пиксел по ширине и по высоте. Во втором тесте размер данных почти не изменяется и для оценки производительности вычислений такой подход кажется более оправданным.
Мы именно так и делаем, т.е. вся обработка изображений выполняется на видеокарте. Получается очень быстро и можно делать ресайз джипегов на лету, задавая индивидуальные параметры ресайза для каждой картинки. При этом скорость декодирования джипегов у нас чуть ниже, чем скорость ресайза. Здесь можно посмотреть наши бенчмарки для ресайза и декодирования.
Да, без рестарт-маркеров не получается параллельное декодирование джипегов (декодирование по Хаффману). Но можно без потери качества добавить рестарт-маркеры самостоятельно с помощью утилиты jpegtran. Рестарт-маркеры являются частью стандарта JPEG, так что это разумный и вполне официальный подход для решения задач быстрого декодирования.
Группа вконтакте есть — vk.com/fastcinemadng