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

Он все это делает дольше?

Это надо изучить. Ответ совершенно не очевден.

Тот случай, когда CPU новый, а GPU 15 лет на службе?

Наоборот, когда коре2 справляется лучше чем игровые видюхи Кризис+.

В любом случае, при чем тут мой вьювер?

Нужны тесты! Вдруг он даёт отрицательные улучшения?

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

Справедливости ради, сабж ничем не помог, скорость примерно та же что и у feh(который на CPU думаю).

Так там все упирается в декодирование. Если речь идет о каком-то стандартном формате типа jpeg/png, то скорость работы всех вьюверов будет +/- одинаковой.

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

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

Аналогично - make deb валится из-за отсутствия version.h при том что саму версию определяет правильно. Странное.

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

Это надо изучить. Ответ совершенно не очевден.

Что мешает? :)

Наоборот, когда коре2 справляется лучше чем игровые видюхи Кризис+.

Уверен, что применить icc или сделать иное преобразование на CPU будет гораздо дольше. GPU будет делать это в рантайме без каких-либо лагов, а CPU будет крутить кулер несколько секунд.

Нужны тесты! Вдруг он даёт отрицательные улучшения?

Нужны - делайте. Для себя я тесты сделал давно, поэтому мой вьювер до сих пор развивается.

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

Аналогично - make deb валится из-за отсутствия version.h при том что саму версию определяет правильно. Странное.

Это на свежесклонированном репозитории?

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

Аналогично

У меня была сколько-то летняя забытая копия, и после git pull проект не собрался.
Починилось выполнением git-clear из git-extras.

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

Если речь идет о каком-то стандартном формате типа jpeg/png, то скорость работы всех вьюверов будет +/- одинаковой.

А аппаратное декодирование фото/видео не задействуется? На каких то видеоускорителях видел подержку всяких jpeg и кучи других фотоформатов. И это даже отлично работало когда разбирал/собирал видео по кадрам.

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

безнадёжно однопоточно.

Разве он сам что-либо распаковывает? Он же использует внешние библиотеки для этого, а они, в свою очередь, могут быть многопоточными. Чтобы быть быстрым, feh не обязан сам быть многопоточным.

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

Что мешает? :)

Займусь! Но время... Думаю пару дней понадобится чтобы собрать и запустить.

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

Не помню ни одного многопоточного декодера фото. Я конечно больше половины из них не знаю, но самые распостранённые jpeg/png - однопоточные.

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

А аппаратное декодирование фото/видео не задействуется?

Декодирование на CPU, применение LUT на GPU. Или я не понял вопрос?

На каких то видеоускорителях видел подержку всяких jpeg и кучи других фотоформатов. И это даже отлично работало когда разбирал/собирал видео по кадрам.

Вполне возможно что есть и такое. А возможно, что в память видеокарты в потоке грузятся смежные кадры.

Большинство видеоредакторов использует прокси (встроенный, внешний), который просто выдает уменьшенные размеры кадров по запросу и эвристически набивает в потоке кеш кадрами, которые могут понадобиться редактору.

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

Не помню ни одного многопоточного декодера фото. Я конечно больше половины из них не знаю, но самые распостранённые jpeg/png - однопоточные.

А если использовать OpenCV для загрузки\декодирования картинки? Он вроде многопоточный всегда был.

Прямо даже интересно стало. Попробую этот png загрузить в imshow. Сколько займет интересно по времени.

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

Я конечно больше половины из них не знаю, но самые распостранённые jpeg/png - однопоточные.

Как минимум j2k умеет в многопоточность - opj_codec_set_threads(..., threads_count).

А libjpeg тормозной и однопоточный, libjpeg-turbo существенно шустрее как минимум за счет simd.

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

А если использовать OpenCV для загрузки\декодирования картинки? Он вроде многопоточный всегда был.

На «мелких» картинках смысла скорее всего нет, а на больших все упрется в скорость доступа к памяти. Но я не уверен, а проверить не смогу, т.к. явно не осилю написание декодера png/jpeg даже для CPU.

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

Но я не уверен, а проверить не смогу, т.к. явно не осилю написание декодера png/jpeg даже для CPU.

Так в opencv декодеры встроены. Просто вызов imread(если память не изменяет).

void 	cv::imread (const String &filename, OutputArray dst, int flags=IMREAD_COLOR_BGR)
 	Loads an image from a file.
Loki13 ★★★★★
()
Последнее исправление: Loki13 (всего исправлений: 1)
Ответ на: комментарий от andreyu

Не, всё правильно понял.

Я именно что ffmpeg'ом раздёргивал видеопоток на кучу png/jpeg чтобы потом попиксельно сравнивать кадры. Так вот именно кодирование одной картинки было самой тяжёлой операцией, но аппаратный кодировщик сильно ускорял. Не помню, х86 или всё таки малина, а если малина то не помню, старый omx или новый mmal. А может я наобророт, собирал видео из кадров.

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

Нет, после git pull. Починилось удалением src/version.cpp - он в .gitignore поэтому git status показывал что всё ок. Понятия не имею почему он не пересоздавался при билде.

zabbal ★★★★☆
()

@IIIypuk, @dataman, @LINUX-ORG-RU, @Loki13 залил фиксы в master.

Надеюсь, все удалось пофиксить.

@annulen, если я правильно понял, то краш происходит на переключении из оконного в полноэкранный режим. Фикс переключения я уже залил. Надеюсь, проблема была связана именно с ним.

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

Починилось удалением src/version.cpp - он в .gitignore поэтому git status показывал что всё ок. Понятия не имею почему он не пересоздавался при билде.

Проблема в переезде со snake_case на CamelCase, а файл version.cpp был в .gitignore. Обновил игнор-лист.

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

Ну и отлично, значит я корректно оценил проблему.

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