PictureView 3 — просмотр изображений различных форматов
PictureView 3 — просмотр изображений различных форматов
В этой теме обсуждается плагин PictureView 3.
Старый тред с обсуждением предыдущих версий: PictureView 1 и 2.
Дальнейшее развитие версии 1.5, переделано под API Far 3.0.
Об извлечении плагинов из дистрибутивов ACDSee.
PS: API как было убогим в Far 2, так и осталось...
Старый тред с обсуждением предыдущих версий: PictureView 1 и 2.
Дальнейшее развитие версии 1.5, переделано под API Far 3.0.
Об извлечении плагинов из дистрибутивов ACDSee.
PS: API как было убогим в Far 2, так и осталось...
- Attachments
-
- PictureView3_20140813_last_xp.7z
- Последняя версия, работающая на WinXP
- (321.22 KiB) Downloaded 1252 times
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Latest post of the previous page:
Проверил на паре картинок шириной 4-5К (PNG/JPEG) — вторая цифра уменьшилась на ~20 (с ~115/150). Но у третьей подобной картинки (JPEG) чуток подросла (на ~0-10 от ~130). Т.ч. как-то неоднозначно.
Фар есть инструмент, а не нянька. © 2009 DrKnS
PictureView 3 — просмотр изображений различных форматов
Это нигде не настраивается. Подозреваю, что в libgfl просто захардкодено какое-то низкое значение dpi, которое передаётся Ghostscript'у.
Для полезности информации необходимо добавить:
1) процессор (сколько ядер/тредов), 2) декодер (JpegRec или нет здесь сильно влияет), 3) площадь (примерная) картинки в мегапикселях.
Если ускорения не видно, то интересно, на сколько загружается процессор, если отключить "Опережающее декодирование" и подержать F5 на этом файле.
И это всё про постпроцессинг, который в заголовке называется "AutoY" (не "AutoLevels").
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
, 4 ядра, 8 тредов.
SEt wrote: ↑Wed 22 Aug, 2018 20:17transparent.png 4813 x 1888 x 32b 28% 20/869 - PictureView by GDI+ : PNG 164+82+10ms <AutoY>
IMG_1896_2.jpg 5171 x 3446 x 24b 26% 27/869 - PictureView by JpegRec [Progressive 444 qP12 r0] 283+126+0ms <AutoY>
foto2.jpg 4665 x 2953 x 32b 28% 28/869 - PictureView by JpegRec [Sequential 4444 YCCK qp12 R0] 167+134+1ms <AutoY>
foto2.jpg
CPU: ~31% (поначалу чуть больше; кстати, с включенным опережающим декодированием показатель тот же), при этом вторая цифра прыгала в диапазоне 60-80 (против прежних 130).
P.S.
Любопытно, у «медленного» JPEGа (foto2.jpg
) 32 бита на пиксель, а не обычные 24.
И вообще, вот что про них пишет ExifTool:
Фар есть инструмент, а не нянька. © 2009 DrKnS
PictureView 3 — просмотр изображений различных форматов
По foto2.jpg никакой постпроцессинг вообще не работает – оно YCCK(≈CMYK), так что все колебания времени исключительно из-за отрисовки. (Я не знаю, как адекватно и не жутко медленно там считать постпроцессинг.)
Уменьшение второй цифры при постоянной нагрузке легко объяснить – видеокарта выходит из энергосберегающего режима.
В остальных случаях ускорение постпроцессинга (разница средних значений второй цифры с постпроцессингом и без) от OpenMP, наверное, раза в 2.
PS: Кто-нибудь понимает, что пишет JpegRec в [] на предпоследнем месте?
Уменьшение второй цифры при постоянной нагрузке легко объяснить – видеокарта выходит из энергосберегающего режима.
В остальных случаях ускорение постпроцессинга (разница средних значений второй цифры с постпроцессингом и без) от OpenMP, наверное, раза в 2.
PS: Кто-нибудь понимает, что пишет JpegRec в [] на предпоследнем месте?
Last edited by SEt on Wed 22 Aug, 2018 21:46, edited 1 time in total.
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Как я понимаю, PictureView вызывает ф-ю gflLoadBitmap/gflLoadBitmapFromMemory, в которую передаётся заполненная структура GFL_LOAD_PARAMS, а вот уже в ней есть поле
EpsDpi
, в которое, подозреваю, и надо положить желаемое значение — например, 300 или 600. Сложно ли вам попробовать это сделать? А то с 72 DPI как-то маловато пользы от просмотра PDF/PS…Фар есть инструмент, а не нянька. © 2009 DrKnS
PictureView 3 — просмотр изображений различных форматов
Опс, действительно, настраивается. Проглядел...
Вот на испытание версии с 200 и 300 dpi. Уже 300 может довольно сильно тормозить. Опцию для этого делать пока не хочется, так что выбирайте.
Вот на испытание версии с 200 и 300 dpi. Уже 300 может довольно сильно тормозить. Опцию для этого делать пока не хочется, так что выбирайте.
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Спасибо!
На сканах не тормозит (т.к. нет растеризации), а на документах да, случается, но для меня приемлемо. Правда, на одной книжке намертво зависает (в весьма замысловатом сценарии; через несколько минут развисает), но это, вероятно, надо чинить в GFL SDK или в Ghostscript. Кстати, сложно ли сделать, чтобы и тут работало прерывание по Esc?
Зачем опцию? Есть же используемые в JpegRec кнопкосочетания Shift/Alt+F5 для переключения фактически параметра декодирования. Сложно ли и для декодера GFL использовать подобный же механизм управления? (Предлагаю градации 72, 150, 300, 600, 1200 DPI.)
Last edited by HaRT on Fri 24 Aug, 2018 14:29, edited 1 time in total.
Reason: Добавлено уточнение про развисание
Reason: Добавлено уточнение про развисание
PictureView 3 — просмотр изображений различных форматов
Новая версия:
Сделано. Но, честно говоря, декодер PDF в GFL не очень: даже с костылями он не только тормозит, но и понимает не все PDF, вместо некоторых страниц упорно декодирует первую, не освобождает выделяемую на каждую страницу память до выхода (или рефреша в PV с изменением DPI).
- GFL декодер позволяет по Shift/Alt+F5 изменять используемое DPI для PDF/PS/EPS файлов, текущее DPI отображается в заголовке.
- Добавлено некоторое количество костылей.
Сделано. Но, честно говоря, декодер PDF в GFL не очень: даже с костылями он не только тормозит, но и понимает не все PDF, вместо некоторых страниц упорно декодирует первую, не освобождает выделяемую на каждую страницу память до выхода (или рефреша в PV с изменением DPI).
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Спасибище!
Вы нас предупредили, недостатки расписали, соответственно, к PictureView никаких претензий.
Вот бы это ещё и было упомянуто в соответствующей секции
Readme.txt
…
А насколько сложно при выходе из плагина попросить Фар обновить заголовок окна? А то остаётся «картиночный» и в таскбаре сбивает с толку…
Можете ли прокомментировать?
Фар есть инструмент, а не нянька. © 2009 DrKnS
PictureView 3 — просмотр изображений различных форматов
У Far сейчас есть цивилизованный способ попросить его перерисовать заголовок? (Вариант сохранить самому/восстановить мне не нравится, так как так можно сохранить "Файл проверяется в..." или ещё что не то.)
А разве на GFL при открытии по имени можно как-то повлиять? Esc хоть и работает более агрессивно, но всё же цивилизованно.
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Не знаю, насколько это цивилизованно, но
Фар есть инструмент, а не нянька. © 2009 DrKnS
PictureView 3 — просмотр изображений различных форматов
Нет, менять заголовок окна через создание фиктивного диалога совершенно не хочется.
Я бы предпочёл, чтобы Far или сам перерисовывал заголовок после вызова плагинов, или хотя бы предоставлял цивилизованный способ это сделать через API. (Например, почему бы AdvControl(ACTL_REDRAWALL) не перерисовать заголовок?)
PS: Запустил под новым Far'ом – обнаружил ещё один забавный эффект: раньше при запуске по префиксу через "pic:name.ext<space>" Far срезал конечный пробел, а теперь не срезает. Даже и не знаю, правильно как было, как сейчас или плагин теперь должен срезать этот пробел.
Я бы предпочёл, чтобы Far или сам перерисовывал заголовок после вызова плагинов, или хотя бы предоставлял цивилизованный способ это сделать через API. (Например, почему бы AdvControl(ACTL_REDRAWALL) не перерисовать заголовок?)
PS: Запустил под новым Far'ом – обнаружил ещё один забавный эффект: раньше при запуске по префиксу через "pic:name.ext<space>" Far срезал конечный пробел, а теперь не срезает. Даже и не знаю, правильно как было, как сейчас или плагин теперь должен срезать этот пробел.
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
EPS и AI теперь можно (читай сообщения выше), SVG вроде по-прежнему никак (во всяком случае, у меня не получилось).
Фар есть инструмент, а не нянька. © 2009 DrKnS
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Для
*.ai
не отображается, хотя влияет: chromium.ai 13199 x 10199 x 24b 10% 6/14 - PictureView by GFL : ai [Uncompressed] 1789+1314+195ms <AutoY>
. Хотелось бы, чтобы и влияло, и отображалось.Фар есть инструмент, а не нянька. © 2009 DrKnS
PictureView 3 — просмотр изображений различных форматов
Да, для *.ai не было отображения. Добавил, будет в следующей версии. (Но их GFL умеет совсем плохо: края обрезаны, декодирует по 10+ секунд.)
А SVG, вроде, GFL никогда и не умел.
А SVG, вроде, GFL никогда и не умел.
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
PictureView 3 — просмотр изображений различных форматов
Спасибо
Всё же не везде одинаково плохо. исходники иконочек просмотреть вполне годится.
Весьма вероятно. XnView их смотрит только через плагин (в т.ч. умеет перекодировать посредством
rsvg-convert.exe
), но какая библиотека при этом задействуется, я не изучал.Фар есть инструмент, а не нянька. © 2009 DrKnS