Simple Viewer GL v2.99 — просмотрщик изображений

Сделал инициализацию giflib только на этапе загрузки первого фрейма. Стало СУЩЕСТВЕННО быстрее.
Так что спасибо, что пнули меня за тормозную реализацию gif.

Фикс в development бранче.

third-party/xcf/CMakeFiles/XcfTools.dir/build.make:182: ошибка выполнения рецепта для цели «third-party/xcf/CMakeFiles/XcfTools.dir/xcftools/pixels.cpp.o»
make[2]: *** [third-party/xcf/CMakeFiles/XcfTools.dir/xcftools/pixels.cpp.o] Ошибка 1
CMakeFiles/Makefile2:122: ошибка выполнения рецепта для цели «third-party/xcf/CMakeFiles/XcfTools.dir/all»
make[1]: *** [third-party/xcf/CMakeFiles/XcfTools.dir/all] Ошибка 2
Makefile:83: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 2

Что за дистрибутив?
У меня под macOS, Gentoo собралось. CI shippable и bitbucket тоже собрали.

Debian Unstable

Случайно запустил make из корневого каталога с исходниками — собралось.

Случайно запустил make из корневого каталога с исходниками — собралось.

Ваше мнение о поддержке XCF?

Сделал инициализацию giflib только на этапе загрузки первого фрейма. Стало СУЩЕСТВЕННО быстрее.
Так что спасибо, что пнули меня за тормозную реализацию gif.

Фикс в development бранче.

Будем тестить, но…

У меня тут с xcftools проблема, вот лог. Есть идеи?

У меня тут с xcftools проблема, вот лог. Есть идеи?

Возможно из-за флага -pedantic-errors - предупреждения о signed / unsigned comparison трактуются как ошибки.
Я только закончил чистку кода xcftools от таких предупреждений, попробуйте забрать свежую версию.

А почему собираете в дебаге и с отключенной оптимизацией? Вьювер же в дебаге тормозит жестоко, особенно на всяких pnm.

Возможно из-за флага -pedantic-errors - предупреждения о signed / unsigned comparison трактуются как ошибки.

Это дефолт в генте. Плюс это позволяет видеть, где в коде творится наркомания.

Я только закончил чистку кода xcftools от таких предупреждений, попробуйте забрать свежую версию.

Отпишусь через пару часов — у меня компиляется qtwebengine, это надолго.

А почему собираете в дебаге и с отключенной оптимизацией?

Я ничего не трогал, собирает дефолтная функция екласса. Надо будет заглянуть в мейкфайл.

(EE) Can't initialize GLFW.

Версия полугодовой примерно давности работала.

(EE) Can't initialize GLFW.

Это значит, что GLFW не может проинициализировать OpenGL контекст. Обычно это из-за драйвера. К примеру драйвер был обновлен, но модуль ядра остался старый, т.к. иксовая сессия не завершалась (грубо говоря, после обновления системы, она не перезапускалась).

JPEG2000, бывает, нужен.

Собрался с силами и добавил поддержку jp2 на основе openjpeg. Через пол часа залью на bitbucket.

Скомпилялось. GIF-анимации жуёт ощутимо шустрее, процессор не насилует.

XCF не сожрало, видимо потому, что у меня GIMP из мастера ( AP, это нормально?).

Остальное пока не тестил.

Скомпилялось. GIF-анимации жуёт ощутимо шустрее, процессор не насилует.

Ну так да, теперь инициализация делается только на загрузке картинки. А потом просто дергаются нужные фреймы с нужным тайм-аутом.

XCF не сожрало, видимо потому, что у меня GIMP из мастера ( AP, это нормально?).

У меня из всего набора XCF не грузится около 10% (это версия 008). И еще около 10% иногда рисует лишние слои (версия 003).

Скиньте мне проблемный XCF, я посмотрю что с ним не так.

Скиньте мне проблемный XCF, я посмотрю что с ним не так.

Да чего там смотреть?

Warning: XCF version 12 not supported (trying anyway...)

Говорит само за себя.

Ладно, фиг с ним. (%

Да, вполне нормально.

Обнаружилась ещё вот такая шняга: https://github.com/Fennec-kun/Minimal-GIMP-XCF-Loader/blob/master/xcf.cpp

Но этот загрузчик тоже не учитывает изменения в 2.9.

Обнаружилась ещё вот такая шняга: https://github.com/Fennec-kun/Minimal-GIMP-XCF-Loader/blob/master/xcf.cpp

Позже попробую прикрутить его и сравню на своей базе файлов.

Вот и правильно. Человеку понадобилось, человек захотел — человек сделал. Уважительный тебе плюс за труд.

FYI:

https://git.gnome.org/browse/gimp/commit/?id=36dec4e6b077851a3ced62e18149d68e...

https://git.gnome.org/browse/gimp/commit/?id=17fb6447872be8feb020858c6cb565b5...

Добавили маски для групп слоёв.

Добавили маски для групп слоёв.

Ага, уже 13 версия xcf.

Собрался с силами и добавил поддержку jp2 на основе openjpeg. Через пол часа залью на bitbucket.

Вот это скорость, спасибо!

Пока не собирается:

• Scanning dependencies of target sviewgl
  [ 21%] Building CXX object CMakeFiles/sviewgl.dir/src/checkerboard.cpp.o
  In file included from /PATH_TO_SVGL/simple-viewer-gl.git/src/quad.h:12:0,
                   from /PATH_TO_SVGL/simple-viewer-gl.git/src/checkerboard.h:12,
                   from /PATH_TO_SVGL/simple-viewer-gl.git/src/checkerboard.cpp:10:
  /PATH_TO_SVGL/simple-viewer-gl.git/src/renderer.h:16:10: fatal error: GLFW/glfw3.h: No such file or directory
   #include <GLFW/glfw3.h>
            ^~~~~~~~~~~~~~
  compilation terminated.
  

  Не проверяется наличие glfw3, а только glfw:

  -- Found GLFW: /usr/include (found version "2.7.2") 
  

• [ 21%] Building CXX object CMakeFiles/sviewgl.dir/src/formats/formatjp2k.cpp.o
  /PATH_TO_SVGL/simple-viewer-gl.git/src/formats/formatjp2k.cpp: In function ‘const char* {anonymous}::getColorSpaceName(COLOR_SPACE)’:
  /PATH_TO_SVGL/simple-viewer-gl.git/src/formats/formatjp2k.cpp:159:14: error: ‘OPJ_CLRSPC_UNKNOWN’ was not declared in this scope
           case OPJ_CLRSPC_UNKNOWN:
                ^~~~~~~~~~~~~~~~~~
  [cut]
  ...
  

  Неправильно обнаруживается openjpeg2. У меня пока установлен openjpeg2 2.1.

  -- Found OpenJPEG: /usr/lib/x86_64-linux-gnu/libopenjp2.so
  -- OpenJPEG support enabled
  

  А здесь хард-код 2.3:

  # Include dir
  FIND_PATH(OPENJPEG_INCLUDE_DIR openjpeg.h
      /usr/local/include/openjpeg
      /usr/local/include/openjpeg-2.3
      /usr/local/include
      /usr/include/openjpeg
      /usr/include/openjpeg-2.3
      /usr/include
      )
  

Кстати:

-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- Found GLFW: /usr/include (found version "2.7.2") 
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8") 
-- Found PNG: /usr/lib/x86_64-linux-gnu/libpng.so (found version "1.6.34") 
-- Found JPEG: /usr/lib/x86_64-linux-gnu/libjpeg.so  
-- Found TIFF: /usr/lib/x86_64-linux-gnu/libtiff.so (found version "4.0.8") 
-- Found GIF: /usr/lib/x86_64-linux-gnu/libgif.so (found version "5.1.4") 
-- Found WEBP: /usr/include  
-- Checking for module 'lcms2'
--   Found lcms2, version 2.8
-- Found lcms version 2.08, /usr/lib/x86_64-linux-gnu/liblcms2.so
[cut]
-- Checking for module 'libexif'
--   Found libexif, version 0.6.21
-- Found IMLIB2: /usr/lib/x86_64-linux-gnu/libImlib2.so  
-- ImLib2 support enabled
-- Found OpenJPEG: /usr/lib/x86_64-linux-gnu/libopenjp2.so
-- OpenJPEG support enabled
-- Checking for module 'OpenEXR'
--   Found OpenEXR, version 2.2.0
-- Checking for module 'IlmBase'
--   Found IlmBase, version 2.2.0
-- OpenEXR support enabled

Даже после установки openjpeg2 2.3.0:

build$ grep -rI OPENJPEG_INCLUDE_DIR 
CMakeCache.txt:OPENJPEG_INCLUDE_DIR:PATH=/usr/include

Ага, SVGL находит франкенштейна из include старый openjpeg 1.5 и lib новый:

$ dpkg -S /usr/include/openjpeg.h
libopenjpeg-dev:amd64: /usr/include/openjpeg.h

cmake/FindOpenJPEG.cmake

Поддержка pkg-config есть уже и в 2.1:

$ pkg-config --cflags libopenjp2
-I/usr/include/openjpeg-2.1 
$ pkg-config --libs libopenjp2
-lopenjp2 

Выглядит лаконично: cmake/modules/FindOpenJPEG.cmake @ darktable

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c14df24..4637987 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -47,11 +47,11 @@ if(IMLIB2_FOUND)
     include_directories(${IMLIB2_INCLUDE_DIR})
 endif()
 
-find_package(OpenJPEG REQUIRED)
-if(OPENJPEG_FOUND)
-    message(STATUS "OpenJPEG support enabled")
+pkg_check_modules(OpenJPEG2 libopenjp2)
+if(OpenJPEG2_FOUND)
+    message(STATUS "OpenJPEG2 support enabled")
     add_definitions(-DOPENJPEG_SUPPORT=1)
-    include_directories(${OPENJPEG_INCLUDE_DIR})
+    include_directories(${OpenJPEG2_INCLUDE_DIRS})
 endif()
 
 pkg_check_modules(OPENEXR OpenEXR)
@@ -153,8 +153,8 @@ if(IMLIB2_FOUND)
     target_link_libraries(sviewgl ${IMLIB2_LIBRARY})
 endif()
 
-if(OPENJPEG_FOUND)
-    target_link_libraries(sviewgl ${OPENJPEG_LIBRARIES})
+if(OpenJPEG2_FOUND)
+    target_link_libraries(sviewgl ${OpenJPEG2_LIBRARIES})
 endif()
 
 if(OPENEXR_FOUND AND ILMBASE_FOUND)

И удалить cmake/FindOpenJPEG.cmake.

Ещё можно заменить OPENJPEG_SUPPORT на OPENJPEG2_SUPPORT:

$ grep -rI OPENJPEG_SUPPORT
CMakeLists.txt:    add_definitions(-DOPENJPEG_SUPPORT=1)
src/imageloader.h:#if defined(OPENJPEG_SUPPORT)
src/imageloader.cpp:#if defined(OPENJPEG_SUPPORT)
src/imageloader.cpp:#if defined(OPENJPEG_SUPPORT)
src/imageloader.cpp:#if defined(OPENJPEG_SUPPORT)
src/formats/formatjp2k.cpp:#if defined(OPENJPEG_SUPPORT)
src/formats/formatjp2k.h:#if defined(OPENJPEG_SUPPORT)

Кстати, а что это за задержка где-то в 1 секунду при старте? С одной стороны, всего 1 секунда, а с другой - так достаёт.

Не проверяется наличие glfw3, а только glfw:
Неправильно обнаруживается openjpeg2. У меня пока установлен openjpeg2 2.1.

Спасибо. Есть идеи, как это сделать правильно?

Инфа по найденным модулям отображается по-разному. Иногда даже без версии.

Видимо модули писали разные люди.

И удалить cmake/FindOpenJPEG.cmake

Супер, спасибо за проделанную работу.

Кстати, а что это за задержка где-то в 1 секунду при старте? С одной стороны, всего 1 секунда, а с другой - так достаёт.

Может долго инициализируется glfw? А вообще нужно будет под профайлером погонять.

Внес изменения в cmakelists.txt, сделал gif, tiff, webp, openexr, jpeg2000 опциональными, поддержка зависит от наличия библиотек при сборке.

зачем тег opengl поставил?

зачем тег opengl поставил?

Затем, что вьювер без opengl даже не соберется.

Тред не читал, чем это лучше gliv?

Тред не читал,

Что мешает вам это сделать?

чем это лучше gliv?

Я не знаю ваш критерий «лучше», но для меня он лучше по этим причинам:

- поддерживает не только «стандартные» форматы (psd, ai, eps, ico, icns, targa, gif, zx-spectrum screen, ...).
- поддерживает внедренные icc-профайлы, что позволяет отображать правильно цвета.
- поддерживает gif-анимацию.
- умеет переключать страницы в многостраничных форматах.
- минималистичный интерфейс.
- отсутствие свистоперделок.
- показывает информацию о выделенном участке изображения.
- показывает информацию о пикселе.
- умеет двигаться вперед/назад от того изображения, которое было передано в качестве параметра.
- умеет рекурсивно обходить директорию.
- определяет формат изображения по содержимому, а не только по расширению.
- нет зависимости от gtk+ (наверное для кого-то это является фичей).

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

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

Годно, накатил. А зачем в гайде и пайплайне четыре команды установки сборочных зависимостей подряд, если можно всё одной накатить? Лишнее засорение логов APT только, и четыре раскочегаривания базы вместо одного.

А ещё оно не умеет показывать картинки по ссылке, так что на замену feh не конает пока. И +/- на нумпаде не поддерживает.

Билд по оффтопик?

А зачем в гайде и пайплайне четыре команды установки сборочных зависимостей подряд, если можно всё одной накатить?

Просто для наглядности разделил по логическим группам.

Лишнее засорение логов APT только, и четыре раскочегаривания базы вместо одного.

Наверное стоит собрать группы в переменные и передать их скопом в одну команду.

А ещё оно не умеет показывать картинки по ссылке, так что на замену feh не конает пока.

Увы, но feh и прочие пока не могут заменить мне мой вьювер.

И +/- на нумпаде не поддерживает.

Готово, в development бранче.

Билд по оффтопик?

Если вы о windows, то я даже не пробовал собирать.

Кроме того feh прибит гвоздями к imlib2. А imlib2 имеет плохую поддержку форматов, заявленных как поддерживаемые.

А ещё оно не умеет показывать картинки по ссылке

А можно пример, для чего нужна такая возможность и почему она не может быть заменена на bash + curl/wget + любой_вьювер?

почему она не может быть заменена на bash + curl/wget + любой_вьювер?

Потому что через пайп сабж тоже картинки не кажет. На - просто не реагирует, на /dev/stdin кажет крокодильчика. А прописывать явно сохранение во временный файл — лишняя возня. Альзо, неплохо бы отображать картинку по мере скачивания. Web-браузеры так издревле умеют, а в просмотрщиках не встречал.

А прописывать явно сохранение во временный файл — лишняя возня

Но именно так и действует feh - скачивает файл.

В любом случае я уже добавил опциональную поддержку через curl. Доступно в development ветке.

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

Только если формат это позволяет. К примеру gif-interlaced - там каждая 4-я строка рисуется.

Потому что через пайп сабж тоже картинки не кажет.

В принципе нет проблемы добавить поддержку --, но так ли это нужно?

но так ли это нужно?

Ради юниксвея — почему бы и нет?

Доступно в development ветке.

Зачем ветке что-то доступное в development? Месье не русский?

Не собирается, однако:

cp: не удалось выполнить stat для 'sviewgl.png': Нет такого файла или каталога

Только если формат это позволяет

А которые из поддерживаемых не позволяют? Я не только про чересстрочность, а и про то, чтобы уже догруженные чанки (кусок изображения) показать. Или, если это что-то многослойное типа XCF — по слоям и по кускам. Сие также полезно, если файл побитый, например.

Ради юниксвея — почему бы и нет?

Ну нет так нет.

Доступно в development ветке.

Зачем ветке что-то доступное в development?
Месье не русский?

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

Не собирается, однако:

$ make

Не добавилась в репозиторий иконочка, поди?

Переместилась в другое место.

А которые из поддерживаемых не позволяют?

Почти все не позволяют.

Я не только про чересстрочность, а и про то, чтобы уже догруженные чанки (кусок изображения) показать. Или, если это что-то многослойное типа XCF — по слоям и по кускам. Сие также полезно, если файл побитый, например.

Такой реквест лучше направить разработчикам feh или кому-либо еще. Для себя я смысла в этом не вижу. Тем более, что загружать текстуры в видеопамять чанками вьювер умеет давно.

Попробуйте по слогам прочитать то, что написал я

тоесть граматека и пунктуацея нинужны можна просто устную речь как то записэвать ясна

Для себя я смысла в этом не вижу

А пулл-реквесты-то принимаются?

Попробуйте по слогам прочитать то, что написал я

тоесть граматека и пунктуацея нинужны можна просто устную речь как то записэвать ясна

Конкретика будет или вы очередной любитель-балабол?

А пулл-реквесты-то принимаются?

Зависит от пулл-реквеста.

Конкретика будет

Конкретика: вот целый тред дефисов, пользуйтесь.

Зависит от пулл-реквеста.

От качества кода или [не]нужности фичи?

Конкретика: вот целый тред дефисов, пользуйтесь.

Это не конкретика а виляние хвостом. Куда по вашему я должен вставить дефис?

От качества кода или [не]нужности фичи?

И от одного, и от другого.

Куда по вашему я должен вставить дефис?

Между «development» и «ветке». Приложение до определяемого слова употребляется через дефис (Вася-дворник, Linux-система), после — через пробел (дворник Вася, система Linux). А тут — вопиющая пунктуационная калька с английского, которую я часто наблюдаю в интернетах, особенно от айтишников. Профдеформация-с.

Куда по вашему я

Впрочем, это неизлечимо, к кому я взываю...

И от одного, и от другого.

Так и до форков недалеко :3

А тут — вопиющая пунктуационная калька с английского, которую я часто наблюдаю в интернетах, особенно от айтишников.

Спасибо. Теперь я смело могу кастовать вас в каждом своем сообщении, поскольку вы взяли на себя обязанность исправлять мою грамматику.

Впрочем, это неизлечимо, к кому я взываю...

Доктор, вам виднее.