GPicView нужен аналог

[Pro]

gdk-pixbuf это весьма важный пакет, переносом одного файла никак не починится, а перенос всего пакета gdk-pixbuf возможно сломает  систему т.к. другие библиотеки gtk завязаны на эту версию пакета.

[RoDoN]

Из Richy. У меня нормально открывает.

Из Richy - это тоже самое, что из PR-13.12, а выше я писал, что там все ok, но либы то там более старых версий.

[DdShurick]

Из Richy - это тоже самое, что из PR-13.12

Да, но: скомпилировал свежий gdk-pixbuf-2.32.1, потребовалось обновить glib, libjpeg-turbo,  libffi, libpng16, libtiff - всё равно работает.

[RoDoN]

Сравнил в ROX-е свойства проблемного файла, который при открытии дает ошибку (слева на рис.) и пересохраненного в mtpaint файла, который теперь нормально открывается в GPicView (справа на рис.), заметил одно отличие в проблемном написано progressive, а в нормальном - baseline, т.е. файлы отличаются оптимизацией.

Оптимизированные для веба фото — это jpeg, а jpeg делится на два типа: базовый последовательный (baseline) и прогрессивный (progressive). Последовательный jpeg — это один скан изображения сверху вниз в полном разрешении, а прогрессивный jpeg — это серия сканов улучшающегося качества. Так они и рендерятся — последовательный jpeg отрисовывается сверху вниз («тик, тик, тик, …»), а прогрессивный быстро размечает свою территорию и затем совершенствуется (по крайней мере так задумано).

Теперь остается вопрос, как сделать, чтобы в PRA нормально распознавались и открывались прогрессивные (progressive) jpeg-файлы.

[sfs]

обновляем libjpeg и радуемся.

К сожалению в последнее время обновления не приносят радости, а часто наоборот, вгоняют в печаль.

Да. Обновил xorg в ПРА64. Получил проблемы совместимости с имеющимися видеодровами, перестала работать настройка dpi. Плюсов не нашел. Задумался о необходимости обновления базы PRA (планировал это на новый год) 

[Satevis]

Теперь остается вопрос, как сделать, чтобы в PRA нормально распознавались и открывались прогрессивные (progressive) jpeg-файлы.

На второй странице печатал про сжатие progressive, правда не так подробно объясняя %(
GPicView - gdk-pixbuf - libpixbufloader-jpeg - libjpeg - файл со сжатием progressive
или в этой цепочке есть ещё звено, т.к. открывают GPicView в PR-1510 и SPicView (у которого точно есть свои либы)
Или

gdk-pixbuf это весьма важный пакет, переносом одного файла никак не починится, а перенос всего пакета gdk-pixbuf возможно сломает  систему т.к. другие библиотеки gtk завязаны на эту версию пакета.

проблемы в существующей версии gdk-pixbuf и нужно просить GTK, чтобы починили.

[Satevis]

Даже многие редакторы изображений использующие gdk-pixbuf выдают такую же ошибку т.е. проблема с (progressive) широка...
И найден лёгкий аналог lximage-qt, но ему нужен pcmanfm-qt, котырый тянет за собой либы lxqt.
На который в свою очередь уже обращал внимание. Т.е. если собрать дистр на lxqt можно юзать свежий qBitorrent и множество других qt прог в минимализме.
З.Ы. Ещё бы в окне открыть\сохранить в qt приложениях, в левой части добавить диски, флешки (а  то там только комьютер и хоме директория). Кто-нибудь умеет?

[Pro]

Может кто проверить, на смонтированном mount.cifs сетевом диске gpicview не переходит на следующее изображение, приходится каждый файл из файл-менеджера открывать

[Roader]

Может кто проверить, на смонтированном mount.cifs сетевом диске gpicview не переходит на следующее изображение, приходится каждый файл из файл-менеджера открывать

Версия 16-03 game copy2ram. Отрабатывает правильно. Проверял на сетевой форточной шаре (ntfs), просмотр фотографий (jpg) из Thunar`a & mc. А вот если распаковать эскизы через uextract, то в в Thumbs.db_распакован (как-то так) при их просмотре может обругаться на невозможность открытия, но по следующему щелчку открывает.

[Pro]

Проверял на сетевой форточной шаре (ntfs), просмотр фотографий (jpg) из Thunar`a & mc.

не не, открывать то открывает, а внутри самого gpicview если на следующие фотки переходить, переходит?

[Roader]

Да переходит. И в распакованных эскизах действия только из вьювера.