LINUX.ORG.RU

Simple Viewer GL 3.3.1

 , , , ,


0

1

Simple Viewer GL – лёгкий однооконный просмотрщик изображений.

Многое из того, что раньше делалось на CPU, теперь выполняется на GPU.

В строке статуса, которую можно отключать клавишей i, отображается базовая информация: формат, разрешение, размер в памяти (CPU + GPU), размер на диске. В режиме информации о пикселе, который включается клавишей p, отображается бабл с информацией о позиции, цвете пикселя, параметрах выделенной области.

Simple Viewer GL умеет определять тип файла по его сигнатуре (параметр -a), а не только по расширению файла. Поддерживается рекурсивный обход директории (параметр -r).

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

Поддерживаемые форматы:

  • PNG
  • JPEG
  • JPEG 2000
  • HEIF
  • PSD (Adobe Photoshop)
  • AI (Adobe Illustrator)
  • EPS
  • XCF (GIMP)
  • GIF
  • SVG
  • TIFF
  • TARGA
  • ICO
  • ICNS (Apple Icon Image)
  • BMP
  • PNM
  • DDS
  • XWD
  • SCR (ZX-Spectrum screen)
  • XPM
  • WebP
  • OpenEXR

Поддерживаются GNU/Linux, FreeBSD и macOS. Существует сторонний форк для Windows.

Новое в Simple Viewer GL 3.3.1:

  • переработана архитектура вьювера;
  • а потому и новый чуть более гибкий рендерер;
  • благодаря рендереру профили и прочие преобразования перенёс с CPU на GPU;
  • благодаря переработанной архитектуре починил и загрузку, и прогресс (спиннер);
  • значительно снизился расход памяти. Теперь память по возможности выделяется только под несколько чанков. Нет полной распакованной копии изображения в памяти;
  • информация о пикселе тянется из видеокарты;
  • счётчик расхода памяти учитывает видеопамять;
  • добавил превью для форматов которые его поддерживают. Если есть превью в EXIF, то беру из него;
  • переработал интерфейс. Переделал рендерер, обновил и ImGui из ветки с поддержкой докинга окон;
  • новый попап EXIF в доке справа, а в него добавил категории и поиск;
  • переработал панель статуса. Просто сделал удобнее её внутри, а заодно поправил визуал;
  • теперь панель статуса не перекрывает изображение. И вообще, любое закреплённое у края окно не перекрывает изображение;
  • расширил поддержку PSD. Теперь поддерживаются практически все вариации;
  • добавил поддержку HEIF (AVIF/HEIC);
  • починил greyscale jpeg2k – теперь яркость корректная;
  • добавил поддержку цветовых профилей там, где их не было, но формат их поддерживал;
  • и ещё кучу того, что и вспомнить не могу, а логи читайте сами, мне лень.

Наверняка что-нибудь отломал, поэтому буду рад замечаниям и советам.

Лицензия GPL-2.0.

>>> Simple Viewer GL on GitHub

★★★★★

Проверено: dataman ()
Последнее исправление: hobbit (всего исправлений: 5)
Ответ на: комментарий от andreyu

Почему -j без числа плохо?

If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.

Потому что это средство для DoS-атаки на свою машину. Будет в проекте 1000 файлов — оно 1000 компиляторов запустит.

annulen ★★★★★
()
Ответ на: комментарий от dataman

Кстати, обнаружил, что вьюверы на основе qt6 (gwenview, qview) тоже некорректно показывают этот svg.

ogion ★★★
()
Ответ на: комментарий от andreyu

Так все ядра и занимает, и вся система становится неотзывчивой.
Несколько раз сталкивался с таким, и с тех пор сначала смотрю, что там в Makefile. :)

dataman ★★★★★
()
Ответ на: комментарий от iron

Поправил на $(MAKE) с установкой количества джобов по количеству ядер.

Надеюсь, этот фикс будет работать везде.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от IIIypuk

Если я правильно оценил проблему, то фикс готов и не должен ничего поломать.

Кстати, я подозреваю, что можно было обойтись и без фикса - создать конфиг (вьювер не только читает из него настройки, но может сохранять в нем параметры окна - координаты и размеры).

Фикс залил.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от dataman

Так все ядра и занимает, и вся система становится неотзывчивой.

Любимая проблема ядра Linux :)

В любом случае, советы услышал, фикс сделал.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

Поправил на $(MAKE) с установкой количества джобов по количеству ядер.

Спасибо. Работает на 15-STABLE.

iron ★★★★★
()
Ответ на: комментарий от dataman

Я бы и ThorVG 1.0 предложил

Отзываю предложение. :)
Там тоже есть утилита tvg-svg2png, и она c smath_big.svg тоже не справилась.
ImageMagick справилась, а GraphicsMagick – нет:

$ gm convert smath_big.svg smath_big.png
gm convert: Non-conforming drawing primitive definition (fill).

dataman ★★★★★
()
Ответ на: комментарий от andreyu

Разве оно не по количеству ядер определяет количество запускаемых процессов?

Нет, я же привёл цитату из мана. Запускает все цели, которые доступны (т.е. у которых зависимости собраны)

annulen ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

у меня гном 2, а на втором компе кде 3.5. а гейгном с гейкозитором свой пользуй сам.

bernd ★★★★★
()

nothing provides libFmtLib.so()(64bit) needed by simple-viewer-gl-3.3.4-1.x86_64

собираю rpm, либа должна ставится или статикой линковаться?

irton ★★★★★
()
Ответ на: комментарий от andreyu

Попробуй через wget. Я проверил, грузит нормально.

IIIypuk ★★★★★
()
Ответ на: комментарий от irton

В Генте с Ебилдом та же фигня, эта либа совсем другим файлом лежит

lrwxrwxrwx 1 root root     12 mar 12 16:09 /usr/lib64/libfmt.so -> libfmt.so.12
lrwxrwxrwx 1 root root     16 mar 12 16:09 /usr/lib64/libfmt.so.12 -> libfmt.so.12.1.0
-rwxr-xr-x 1 root root 149608 mar 12 16:09 /usr/lib64/libfmt.so.12.1.0
Myp3ik ★★★
()
Ответ на: комментарий от irton

собираю rpm, либа должна ставится или статикой линковаться?

Статика, fmtlib бандлится с проектом - third-party/fmtlib/

andreyu ★★★★★
() автор топика

серый JPEG2000 размером 25928х44039х10bpp открывает, и даже памяти не очень много ест. Открывает медленно, потом не тормозит.

Это же изображение конвертированнное в обычный JPEG открывает, тоже долго, но сжирает при этом раза в 3 больше памяти чем при открытии JPEG2000.

Было бы весьма неплохо, если бы не тормозил так аццки при открытии.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 2)
Ответ на: комментарий от Stanson

Было бы весьма неплохо, если бы не тормозил так аццки при открытии.

Полагаю, все упирается в декодирование. На своей стороне я большего сделать не смогу.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

Полагаю, все упирается в декодирование.

На GPU декодировать например. JPEG точно будет хорошо распараллеливаться.

Шустрых и удобных смотрелок для больших картинок нормальных нету, а большие картинки нынче не такая уж и редкость.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

На GPU декодировать например. JPEG точно будет хорошо распараллеливаться.

Как я уже говорил ранее - я не осилю декодер jpeg на GPU. Да и на CPU тоже не осилю.

Если есть готовый аналог libjpeg или libjpeg-turbo на GPU, то почему бы не попробовать.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

И в чем тогда смысл?

В параллельной распаковке, очевидно. Для больших картинок выигрыш будет существенным, даже несмотря на потери на копирование. Тем более что картинка в итоге всё равно должна оказаться в видеопамяти. Т.е. в идеале нужно загрузить в память GPU только пожатую картинку и всё. Это намного быстрее, чем грузить в память GPU несжатую картинку.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

В параллельной распаковке, очевидно.

То бишь, предлагается из картинки 20K x 30k сделать 2K x 3K картинку. Зато на GPU. Ну так себе идея.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

То бишь, предлагается из картинки 20K x 30k сделать 2K x 3K картинку.

нет, предлагается грузить в GPU сжатую JPEG’ом картинку до 65k x 65k и пусть GPU её распаковывает внутри себя параллельно по нескольок тысяч блоков за раз в несжатую каринку до 65k x 64k.

На кой хрен ресайзить-то? Да и картинку в смотрелке вообще нафиг не надо выгружать из GPU.

Если есть GPU, то зачем грузить картинку в память CPU, разжимать её помощи CPU, а потом этот гигантский raw один хрен грузить в GPU. Можно же просто загрузить сжатую картинку в GPU и пусть оно там в своей памяти всю работу и сделает.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 3)
Ответ на: комментарий от andreyu

Если есть готовый аналог libjpeg или libjpeg-turbo на GPU, то почему бы не попробовать.

Не думаю, что прямо аналог, но я на C++ нашёл: https://github.com/ChenRunyang/JPEG_decode_OpenCL.
Но пишу со смартфона, так что пока не пробовал. :)

dataman ★★★★★
()
Ответ на: комментарий от Stanson

На кой хрен ресайзить-то?

А я почем знаю? Так написано в самом начале readme проекта:

I recommend to use this lib with resize feature, because data transform between CPU and GPU is very expensive.

Я хз, что это значит, потому и спрашиваю.

Можно же просто загрузить сжатую картинку в GPU и пусть оно там в своей памяти всю работу и сделает.

Это звучит логично, но как именно работает эта либа?

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

Это звучит логично, но как именно работает эта либа?

Так же как libjpeg только распаковка на GPU. Тебе из неё нужна только та часть которая грузит в GPU распаковщик, загружает сжатую картинку и запускает распаковку на GPU. Тебе не нужно выгружать из GPU распакованную картинку, поэтому и предупреждение про медленную передачу данных между CPU и GPU тебя не касается.

Аналогично можно сделать и с другими форматами со сжатием, написав соответствующие распаковщики на OpenCL загружая их в GPU.

Если тебе прикольно возится со смотрелкой для картинок, то почему бы не разобраться и в программировании на OpenCL который по-сути сишечка для GPU и не портировать на GPU распаковщики разных форматов. Будет невероятно шустрая смотрелка картинок.

Распакованное изображение в памяти GPU можно сразу выводить на экран как кусками 1-в-1, так и масштабируя железом со всеми модными плюшками которые умеет GPU.

Несжатая картинка 65k x 65k в 24bit RGB будет занимать 12Гб памяти. Нынче видюхи и побольше памяти имеют. Если памяти меньше, то можно распаковывать кусками, например, по мере надобности. Сжатая картинка и код распаковщика формата влезут в память любой видеокарты которая умеет OpenCL.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Будет невероятно шустрая смотрелка картинок.

Только работать она будет у ограниченного числа пользователей. Пока профит не ясен для меня.

Будет свободное время, поковыряю еще раз палочкой распаковку на GPU.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Несжатая картинка 65k x 65k в 24bit RGB будет занимать 12Гб памяти.

Скорее всего, в памяти GPU она будет занимать не 3 байта на пиксель, а 4 байта на пиксель, 16Гб.

Кроме того, нужно место для исходных данных, буфера, и выходных данных.

в память любой видеокарты которая умеет OpenCL.

А много ли таких?

Еще немного потыкал палочкой в этом направлении:

  • OpenCL неплохо поддерживается на целевых платформах вьювера.
  • Может результат сразу положить в текстуру.
  • Есть фундаментальная проблема - декодер Huffman нельзя распараллелить. Так что эту часть все равно придется делать на CPU И, если я правильно понял, libjpeg не предоставляет API для этого шага, а значит придется врукопашную выдирать из него куски кода.

Я пока не созрел для такой серьезной задачи.

andreyu ★★★★★
() автор топика
Последнее исправление: andreyu (всего исправлений: 1)
Ответ на: комментарий от andreyu

Только работать она будет у ограниченного числа пользователей.

OpenCL в отличии от всяких вендорлокнутых CUDA и пр. работает везде. Даже там, где вообще нет GPU способного выполнять код. Просто будет на CPU работать.

Пока профит не ясен для меня.

Профит в том, что если какой-никакой GPU есть, то будет шустро. Если GPU нет то будет как обычно.

Stanson ★★★★★
()
Ответ на: комментарий от andreyu

А много ли таких?

Все современные (младше 10 лет) Intel, AMD, Nvidia. По-моему даже для каких-то Mali и PowerVR кто-то что-то делал, но я не знаю доделал ли.

Есть фундаментальная проблема - декодер Huffman нельзя распараллелить.

Так надо распараллеливать не Huffman, а блоки JPEG. Пусть каждый юнит GPU распаковывает свой блок.

Я пока не созрел для такой серьезной задачи.

Там задача не столько в переделке кода, сколько вдуплить как OpenCL работает и какие особенности у этой сишечки.

А так - сишечка и сишечка.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Просто будет на CPU работать.

Сложно назвать это работой :)

Профит в том, что если какой-никакой GPU есть, то будет шустро.

Декодер Huffman нельзя распараллелить. Декодирование все равно придется на CPU выполнять. Остальные этапы да, можно перенести на GPU.

Если GPU нет то будет как обычно.

Если OpenCL будет на CPU, то будет существенно медленнее jpeg-turbo на CPU.

Есть какие-нибудь вьюверы, которые выполняют декодирование jpeg на GPU, чтобы сравнить профит?

andreyu ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Так надо распараллеливать не Huffman, а блоки JPEG.

Но декодирование Huffman все равно останется на GPU, а это все равно существенный и важный шаг.

Там задача не столько в переделке кода, сколько вдуплить как OpenCL работает и какие особенности у этой сишечки.

Ну так исходники вьювера открыты :)

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

Сложно назвать это работой :)

Будет точно так же как у тебя сейчас.

Декодер Huffman нельзя распараллелить.

А декодер-то зачем непременно распараллеливать?

Декодирование все равно придется на CPU выполнять

С какого перепугу? Процессоры GPU без проблем могут выполнять непараллелящийся код.

Остальные этапы да, можно перенести на GPU.

Там этапов-то нету. Берёшь JPEGовские блоки, скармлиаешь декодеру, получаешь квадратики изображения. Просто процессоров в GPU много, и GPU может одновременно распаковывать разные блоки на разных процессорах. Даже непараллелящимся распаковщиком.

Но декодирование Huffman все равно останется на GPU, а это все равно существенный и важный шаг.

Если OpenCL будет на CPU, то будет существенно медленнее jpeg-turbo на CPU.

Существеннее не будет. Та же сишечка скомпилируется LLVM в код процессора, а не в код GPU. Примерно как шлангом.

Есть какие-нибудь вьюверы, которые выполняют декодирование jpeg на GPU, чтобы сравнить профит?

Ну так поищи на жидхабе, если тебе не нравится либа, на которую я ссылку дал. Может есть и с бенчмарками и с типа вьювером. Ещё наверно у игрушкописателей можно глянуть - текстуры-то выгоднее в сжатом виде в видяху подгружать, а не распаковывать на CPU и грузить разжатый в GPU.

Но декодирование Huffman все равно останется на GPU, а это все равно существенный и важный шаг.

Процессоров GPU у тебя сотни, если не тыщи. Распаковывать нераспараллеливаемым распаковщиком сотни блоков одновременно очевидно намного быстрее.

Ну так исходники вьювера открыты :)

Ну так я-то по вьюверам не прикалываюсь особо.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

А декодер-то зачем непременно распараллеливать?

Приведу аналогию. Есть задача добраться из точки A в точку B в пределах одного города. Маршрут уже оптимизирован, но хочется еще какого-то ускорения. Есть вариант ехать на машине, корректируя маршрут с учетом пробок. А пассажир хочет лететь на самолете, т.к. его скорость самолета существенно выше скорости автомобиля. Но пользователь забывает, что до аэропорта ехать далеко, требуется куча предпосадочных и послепосадочных процедур.

С какого перепугу? Процессоры GPU без проблем могут выполнять непараллелящийся код.

С того перепугу, что GPU рассчитан на параллельную работу - в этом его сила. А выполнять задачу, которую нельзя распараллелить на все вычислительные блоки GPU, будет существенно медленнее, чем выполнять ее на CPU.

Существеннее не будет. Та же сишечка скомпилируется LLVM в код процессора, а не в код GPU. Примерно как шлангом.

Там уже вся сила в подготовки кода под CPU. Код подготовленный для GPU плохо будет работать для CPU.

Ну так поищи на жидхабе, если тебе не нравится либа, на которую я ссылку дал.

У меня встречное предложение. Если не нравится как я реализовал вьювер, то берите код и правьте так, как считаете нужным.

Может есть и с бенчмарками и с типа вьювером. Ещё наверно у игрушкописателей можно глянуть - текстуры-то выгоднее в сжатом виде в видяху подгружать, а не распаковывать на CPU и грузить разжатый в GPU.

Ну вот, вам и карты в руки.

Процессоров GPU у тебя сотни, если не тыщи. Распаковывать нераспараллеливаемым распаковщиком сотни блоков одновременно очевидно намного быстрее.

Прочитал несколько раз, но мысль не уловил.

Ну так я-то по вьюверам не прикалываюсь особо.

Просто нужно чем-то время занять, ОК.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

Приведу аналогию. Есть задача добраться из точки A в точку B в пределах одного города. Маршрут уже оптимизирован, но хочется еще какого-то ускорения. Есть вариант ехать на машине, корректируя маршрут с учетом пробок. А пассажир хочет лететь на самолете, т.к. его скорость самолета существенно выше скорости автомобиля. Но пользователь забывает, что до аэропорта ехать далеко, требуется куча предпосадочных и послепосадочных процедур.

Аналогия вообще мимо.

Правильная аналогия:

Тебе надо перевезти 100 тонн груза. У тебя есть машинки которые больше 1 тонны не увезут. Одна машинка никак не может перевезти эту тонну быстрее чем проедет путь из А в Б. Как перевзти 100 тонн груза быстрее используя эти машинки? Да просто взять 100 машинок, загрузить кажду 1 тонной груза и отправить в точку Б их все сразу. Выигрыш в 100 раз, при том, что каждая отдельно взятая машинка никак не «распараллеливает» свою тонну груза.

С того перепугу, что GPU рассчитан на параллельную работу - в этом его сила.

Каким конкретно образом он «рассчитан на параллельную работу»? В GPU нет одного единственного процессора который выполняет какие-то команды параллельных вычислений. Там сотни процессоров, хоть и весьма укушенных по сравнению с CPU, но вполне сопособных делать необходимые для распаковки отдельного блока JPEG операции согласно алгоритму.

Там уже вся сила в подготовки кода под CPU. Код подготовленный для GPU плохо будет работать для CPU.

Подготовка кода OpenCL выполняется при компиляции этого кода под ту или иную архитектуру. Которая происходит не заранее, а при работе программы в зависимости от того, какое железо в данный момент доступно.

У меня встречное предложение. Если не нравится как я реализовал вьювер, то берите код и правьте так, как считаете нужным.

Мне нравится как реализован вьювер. Мне не нравится что он тормозит при загрузке изображения.

Прочитал несколько раз, но мысль не уловил.

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

Просто нужно чем-то время занять, ОК.

Ну да, человеку который пишет 100500й вьювер картинок для линукса явно просто нужно чем-то время занять. Вполне достойное занятие, тащемта. особенно если ему самому нравится. Вот я и предложил чем его занять, тем более что у него этот 100500й вьювер вполне получается, в отличии от сотен каких-нибудь, прости Господи, растаманов или электронщиков.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от dataman

Попробовал, слишком кривая.

Если я решусь на использование GPU для распаковки JPEG, то за основу возьму декодер Huffman из libjpeg, остальное врукопашную перенесу на GPU.

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

andreyu ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Правильная аналогия:

Эта «правильная» аналогия постоянно теряет из виду декодирование, которое нельзя распараллелить.

Там сотни процессоров, хоть и весьма укушенных по сравнению с CPU, но вполне сопособных делать необходимые для распаковки отдельного блока JPEG операции согласно алгоритму.

И в итоге все усилия свести к «ну хоть как-то и у кого-то работает». А будет ли профит большой вопрос.

Подготовка кода OpenCL выполняется при компиляции этого кода под ту или иную архитектуру. Которая происходит не заранее, а при работе программы в зависимости от того, какое железо в данный момент доступно.

Вы спец - вам и флаг в руки. А я уже утомился повторять где находится бутылочное горлышко и что GPU тут никак не поможет.

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

Ну вы всегда можете показать мастер-класс.

Ну да, человеку который пишет 100500й вьювер картинок для линукса явно просто нужно чем-то время занять. Вполне достойное занятие, тащемта. особенно если ему самому нравится. Вот я и предложил чем его занять, тем более что у него этот 100500й вьювер вполне получается, в отличии от сотен каких-нибудь, прости Господи, растаманов или электронщиков.

Ну да, ведь без вас я не знаю чем мне заняться.

andreyu ★★★★★
() автор топика
Ответ на: комментарий от andreyu

за основу возьму декодер Huffman из libjpeg

Кстати, у Google есть jpegli на C++ с некоторыми улучшениями кодирования и декодирования:

This repository contains a JPEG encoder and decoder implementation that is API and ABI compatible with libjpeg62.

Надо будет пощупать. :)

dataman ★★★★★
()
Ответ на: комментарий от andreyu

Эта «правильная» аналогия постоянно теряет из виду декодирование, которое нельзя распараллелить.

Мда…

Ответь мне, нахрена вообще распараллеливать декодирование блока, когда задача запускать это самое нераспараллеливаемое декодирование одновременно на куче процессоров для кучи отдельных пожатых блоков из которых собственно и состоит JPEG.

А я уже утомился повторять где находится бутылочное горлышко и что GPU тут никак не поможет.

Бутылочное горлышко в количестве процессоров. JPEG состоит из квадратиков, каждый из которых пожат неким алгоритмом. Любой процессор - в CPU ли, в GPU ли может за раз разжать только один квадратик. Если процессоров много, то можно разжимать много квадратиков одновременно, только и всего. Если процессоров столько же сколько квадратиков в JPEG, то JPEG можно разжать за одно выполнение алгоритма разжатия одновременно на всех имеющихся процессорах. Если процессор один - то придётся разжимать квадратики один за другим, что, собственно, и происходит в стандартной libjpeg, и именно по этой причине твоя смотрелка дико тормозит при открытии достаточно большого файла.

В GPU намного больше процессоров чем в CPU. Твой проект один хрен заточен на использование GPU, о чём даже в названии оного есть упоминание в виде буковок GL. Так в чём тогда проблема использовать процессоры GPU если уж использование GPU и так подразумевается.

Более того, JPEG вообще можно разжимать произвольными кусками, координаты и размер которых кратны размеру квадратиков.

Метеоспутники, например, летая вокруг Земляшки непрерывно передают в канале LRPT бесконечный JPEG с картинкой полосы поверхности которая попадает в данный момент на сенсор состоящей из 196 пожатых квадратиков 8х8. Размер этого JPEG вообще бесконечен по вертикали. Тем не менее, прекрасно получается разжимать только то, что начинает попадать в антенну когда спутник появляется из-за горизонта и до тех пор пока он не скроется за горизонт Небольшой кусочек бесконечного JPEG. Без всяких там заголовков и «загрузки всего файла».

Ну да, ведь без вас я не знаю чем мне заняться.

Наше дело продложить. :)

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

В GPU намного больше процессоров чем в CPU.

Не стесняюсь спросить, а сколько и тех и других процессоров на твоём ПК?

dataman ★★★★★
()
Ответ на: комментарий от dataman

Не стесняюсь спросить, а сколько и тех и других процессоров на твоём ПК?

На ноуте в CPU - 2 ядра 2.6ГГц, в GPU согласно clinfo - 20 compute units 1ГГц. ПК выклячен, лень включать, там в GPU под сотню наверно.

Если бы загружаемый в смотрелку JPEG разжимался на GPU моего ноута, то это было бы в 4-5 раз быстрее чем на CPU. 6-8 секунд вместо полминуты - это весьма существенно.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Нет, ты тут один знанием обладаешь. Поделись.

i-rinat ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.