» XnView

в пакетном режиме xnview вытаскивает из raw размер больше чем официально указано на аппарате, отчего так?

stanline

Могут быть разные единицы измерения, да и в RAW содержаться служебные данные, а аппарат может указывать размер сжатой картинки к примеру в JPEG. По крайней мере у себя на телефоне я его показометру не верю, а смотрю после реальные данные на флешке с учётом размера кластера.

так и знал. имелось Ввиду размер ширина высота

stanline

Устройство может выводить картинку подгоняя её под условный размер кадра заданный в прошивке. Возможно что имеет место данное событие.

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

В последнее время перестала работать обрезка фото в XNViewMP под Windows 7 SP1 64bit - не появляется прямоугольник выделения. Пробовал ставить 32бит версию, экспериментировал с совместимостью - ничего не меняется. Жаль, перешел на FastStone, хотя XNViewMP нравится больше. Интересно, есть возможность починить обрезание фото?

Yaromaxx

А я думал что только я один такое наблюдаю. По моему в v0.70 - v0.71 она работала, в v0.72 сломалась. Баг-репорт написал, ждём исправлений.

Yaromaxx

В теме на форуме XnViewMP получено и третье независимое подтверждение наличия ошибки, так что думаю автор её исправит в ближайшей версии ибо известна как сама ошибка, так и способ проверки её наличия.

Можно ли в "Пакетной обработке" (или еще где в XnView, но тоже поточно) сделать так, чтобы изображения разного типа обрабатывались тоже по-разному?

Хронически приходится сжимать папки, где одновременно лежат и ч/б, и цветные изображения (отсканированные книги). Ч/б сканы при этом надо сжать одним образом (TIFF CCITT G4), а цветные другим (JPEG с Q таким-то).
То есть надо как-то указать не один выходной формат, а два - для ч/б свой и для цветных свой. Плюс, чтобы шла при обработке автоматическая сортировка - если ч/б, то обрабатываем так, а если цветные, то эдак.

Можно ли сделать такое силами XnView?
Пока что обычно пакетно сжимаю ч/б часть папки, а потом вручную, поштучно делаю цветную часть. Времени такое съедает немало, хочется как-то автоматизировать.

Shangry

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

Victor_VG

Я не нашёл возможности средствами сабжа производить выборку из группы фотографий.
Там же в пакетном обработке условий нет вообще.
Может как-то поможет NConvert, хотя-бы ориентируясь на расширения....

Victor_VG

Цитата:

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

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


Цитата:

Может тут проще создать несколько пакетных заданий и отрабатывать их к примеру скриптом?

Да можно и просто одновременно несколькими потоками обработку запустить, делал такое и не раз.
Но там обычно большая стопка папок, в которой вперемешку и ч/б, и цветные. И чтобы их сначала рассортировать, а потом опять вместе сложить, примерно столько же времени уйдет, сколько у меня сейчас уходит.

Dmb_2007

Цитата:

Там же в пакетном обработке условий нет вообще.

Я тоже пока ничего подходящего не нашел. Просто надеялся, что оно есть, просто с ходу не очень заметно.


Цитата:

Может как-то поможет NConvert, хотя-бы ориентируясь на расширения....

К сожалению, там одни только TIFF.

Shangry
Dmb_2007

Так в этом и смысл потоковой обработки что блок получает на входе однотипные данные к которым применяется ряд преобразований. А если данные разные то надо формировать несколько заданий, а в одном задача в принципе не решаема.

Shangry
Ч/Б - действительно Ч/Б? В каком формате сканы? Мне видится только такой вариант: с помощью плагина WDX for Images в Total Commander или Double Commander сделать два списка и уже их скармливать программе.

Skif_off

Так это и FarMediaInfo умеет, только после вывод надо чем-то парсить. Ну, если для Far Manager есть встроенная поддержка Lua v5.1 и Moonscript v0.26 и парсер можно на них написать ибо плагин умеет выводить данные или в клипбоард или в редактор и их можно перенаправить в парсер к примеру вызывая его как автостартующий редакторный макрос, а в ТС какими средствами решать задачу разбора вывода этого плагина (при условии что его можно перехватить) который вдобавок не обновлялся с 2007-го года?

Для Far при просмотре мы можем видеть данные картинки в панелях плагинов (у меня на х64 Far используются FarImageView или Review (команды I|CtrlI)) или в QuickView используя скрипт Picture.lua написанный zg (минимально требуемая ОС WinXP, для плагина FarImageView реальный минимум Win7, ну может у кого и на Vista запустится, но писался он под семёрку) и отдать команду копирования/пометки файла, а после создать к примеру на него хардлинк в другой каталог и тот скормить пакетному заданию. А в ТС насколько я в курсе средств работы с симлинками, хардлинками и JUNCTION нет и как сказал приятель на днях спрашивавший об этом Гислера и в обозримом будущем их появление не предвидится ибо тот по его словам не желает терять совместимость с Win31/95, а потому не станет переписывать код файловых операций работающий в ТС ещё с времён WINNT 4.0.

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

Victor_VG

Цитата:

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

Не уверен, что есть иной выход, если только писать разработчикам, но не думаю, что фича, если и появится, появится в ближайшей перспективе. Смотреть перед сжатием каждую картинку - это вообще не вариант. Если попробовать автоматизировать (батники, Lua, AutoIt/AHK), то, наверное, можно обойтись XnConvert или вообще NConvert?

FarMediaInfo точно умеет? Проверить не могу, но, думаю, Exiv2 не прокатит, а что выдаёт по картинкам MediaInfo не помню, честно говоря.

Цитата:

плагина ... который вдобавок не обновлялся с 2007-го года?

Обновлен: 25.10.2013
Про линки: ТС, равно как и Far, во многом интересны плагинами и дополнениями, для ТС есть инструменты, позволяющие их создавать, если приятель не в курсе, то пусть немного напрягётся
Предлагаю не начинать дискуссию TC vs. Far или Far vs. TC

В XnView нельзя вытащить инфу о цвете? Возможно, получится разделить сортировкой? Правда, наверное, уже не рекурсивно, только по папкам.
Хотя мы ещё не услышали о формате сканов...

Skif_off

Вот типичный отчёт для первых попавшихся под руку [more=JPEG]Общее
Полное имя : 1212112894_cat_19.jpg
Формат : JPEG
Размер файла : 40,8 Кбайт

Изображения
Формат : JPEG
Ширина : 600 пикселей
Высота : 387 пикселей
Цветовое пространство : YUV
Субдискретизация насыщенности : 4:2:0
Битовая глубина : 8 бит
Метод сжатия : С потерями
Размер потока : 40,8 Кбайт (100%)

EXIF
GDI+.Luminance Table : 4
GDI+.Chrominance Table : 4[/more] и [more=JPEG2000]Общее
Полное имя : 0507_Taipei_Taiwan.jp2
Формат : JPEG 2000
Профиль формата : MPEG-4
Идентификатор кодека : jp2
Размер файла : 1,50 Мбайт

Изображения
Формат : JPEG 2000
Ширина : 1280 пикселей
Высота : 960 пикселей
Цветовое пространство : RGB
Субдискретизация насыщенности : 4:4:4
Битовая глубина : 8 бит
Метод сжатия : Без потерь[/more]. В JPEG2000 либа ошиблась спутав Lura Wave сжатие с MPEG4, но это учитываемо.

Victor_VG

Цитата:

Так в этом и смысл потоковой обработки что блок получает на входе однотипные данные к которым применяется ряд преобразований. А если данные разные то надо формировать несколько заданий, а в одном задача в принципе не решаема.

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

Но если в XnView нет никаких возможностей ветвленной обработки, то ничего не поделаешь.


Цитата:

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

Но опять же, как/чем сделать сортировку не вручную, а автоматически?
Когда уже рассортировано/разложено, то дальше нет проблем. Но вот как раскидать, да еще, когда сканов изрядное количество?

Skif_off

Цитата:

Ч/Б - действительно Ч/Б? В каком формате сканы?

Ч/б - в смысле Black&White, т.е. битоналка.
Форматом там обычный TIFF, только сканировщики зачем-то задали сохранение в несжатом TIFF. Ну и приходится переделывать в TIFF G4.

Цветные тоже TIFF.


Цитата:

Мне видится только такой вариант: с помощью плагина WDX for Images в Total Commander или Double Commander сделать два списка и уже их скармливать программе.

Если WDX for Images может автоматом разложить ч/б и цветные сканы по отдельным папкам, то можно попробовать.
Только в состоянии ли он при обработке стопки папок с перемешанными сканами создать на выходе две стопки, с такими же именами папок, как у исходных? Т.е. воспроизвести исходное дерево папок в двух экземплярах, чтобы в одном были только ч/б, а в другом - только цветные.

Shangry

Как вариант перехват вывода плагина макросом который сейчас умеет запускать внешние программы функцией Win.system() эта возможность появилась в LuaFar b478 (в b479 прибиты х64 варнинги VC++ 2010). Вам какая сборка нужна х86 для 32-х битных ОС или х64? Если х64, то достаточно просто архив распаковать и запустить, х86 пока в работе - у меня не все инструменты установлены и потому на сервере старый вариант лежит.

Добавлено:
А WDX как я понял запустив его под DC того что вам нужно не умеет. По крайней мере вариант от 2007-года на который была ссылка. И кстати, раз у вас только TIFF то можно прикинуть вариант к примеру с NSIS - там можно прикрутить бинарный анализатор и логику копирования файлов в разные каталоги. Хулиганство конечно, но почему бы и нет?

Добавлено:
Skif_off

Кстати, поиском версии WDX for Images новее чем 0.5 я не отыскал. Может и где есть поновее, но мне не попалась.

P.S.

Да не особо интересно ибо ТС (да DC) не стоит и ставить не планирую.

Victor_VG

Цитата:

Как вариант перехват вывода плагина макросом который сейчас умеет запускать внешние программы функцией Win.system()

В смысле, просматривает сканы и на каждый обнаруженный скан запускает его обработку указанной программой, согласно заданному набору условий?


Цитата:

Вам какая сборка нужна х86 для 32-х битных ОС или х64?

У меня стоит ХР.


Цитата:

И кстати, раз у вас только TIFF то можно прикинуть вариант к примеру с NSIS

Сколько я смог понять, это просто разновидность инсталлятора.

Victor_VG
Я понимаю, кто-то любит консольные файловые менеджеры, кто-то GUI'шные, но это совсем не повод для невнимательности плагин был написан и выложен в 2007м - версия 0.1 beta, а позже, уже в октябре 2013го, обновлён в итоге до версии 0.5.

Shangry

Цитата:

Сколько я смог понять, это просто разновидность инсталлятора.

В общем-то да, но возможности есть разные.

Цитата:

Ч/б - в смысле Black&White, т.е. битоналка.

[more=Тогда я бы для начала попробовал так:]
- установил плаг WDX for Images в Total Commander или Double Commander;
- создал пользовательскую колонку с режимом изображения, выбрал и включил сортировку по этому полю;
- зашёл в папку, в которой лежат изображения, включил вид без подкаталогов;
- в TC и DC есть команды копирования имён файлов с полными путями в буфер
- есть два списка, теперь осталось посмотреть параметры nconvert.exe на этой, например, странице и разобраться, как написать txt'шный файл со списком и настройками для конвертации.

Вот с тем, куда сохранять - вопрос. Если nconvert.exe умеет менять имя выходного файла (суффиксом или префиксом), то валить все рядом с оригиналами, потом найти их (в крайнем случае - по дате) и переместить с сохранением структуры каталогов.
По идее, если собираетесь делать часто, можно попробовать автоматизировать сразу после выделения файлов с копированием в нужный каталог...[/more]

P.S. ScanKromsator или Scan Tailor не умеют ничего подобного?

P.P.S. TIFF G4 - без потерть и любой софт переварит? Несжатый и LZW мне кажутся поуниверсальнее, всё-таки.

P.P.P.S. На оптимальность не претендую и удачи, надеюсь, вы не тот недоумок, который выложил атлас крови, где картинки - самое главное, битональным DjVu

Shangry

Примерно так - скрипт в цикле зовёт плагин, а его результат в разборку. Но написать NSIS-программу сортировки смотрящую отдельные поля хидера попроще будет:

OpenFile() -> Read(ofset,bytes) -> Compare(b/w,color) -> If "b/w" Then copy ./1` Else copy ./2 -> End

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

Skif_off

Цитата:

Тогда я бы для начала попробовал так:

Спасибо, надо будет поколдовать. Быстро думаю не выйдет, сначала ТС надо будет освоить (у меня штатным файл менеджером Far). Но может в итоге что-нибудь да получится.


Цитата:

P.S. ScanKromsator или Scan Tailor не умеют ничего подобного?

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


Цитата:

TIFF G4 - без потерь и любой софт переварит?

А в чем здесь может быть проблема? TIFF G4 понимает практически любая софтина, разве что кроме совсем узкоспециализированных. Плюс почти мгновенное сжатие и открывание.
Недаром он считается стандартом де-факто для ч/б-сжатия.


Цитата:

Несжатый и LZW мне кажутся поуниверсальнее, всё-таки.

Для цветных и "серых" TIFF - согласен. А для ч/б особого смысла нет.

Victor_VG

Цитата:

Примерно так - скрипт в цикле зовёт плагин, а его результат в разборку. Но написать NSIS-программу сортировки смотрящую отдельные поля хидера попроще будет:
OpenFile() -> Read(ofset,bytes) -> Compare(b/w,color) -> If "b/w" Then copy ./1` Else copy ./2 -> End

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

Shangry

Ну, тут уж проще с Lua/Moonscript подружится. Предлагаемый WDX под DC толком не работает, а с NSIS можно решить задачу, просто у себя я пока эту среду разработки не развернул, но он умеет читать отдельные биты в файле и там можно сделать такой анализ просто - весь анализатор сводим к паре элементов - сначала считать байты из файла, затем выбранный фрагмент сравниваем с шаблоном и в зависимости от результата выбираем ветку копирования. Такая программа может и каталоги обходить, а в ТС вам придётся всё делать руками. Смотрите сами по времени счета задачи.

Добавлено:
И кстати, насчёт отлаженности решения - в любом случае готового решения для вашей задачи нет и его надо разрабатывать с нуля ибо задача нестандартная.

Yaromaxx

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

Victor_VG Да бага-то и нет... Зажимаем Ctrl - выделяем область фото, нажимаем ОБрезать - работает.

Yaromaxx

Погляжу как буду с картинками возится. Может я что-то не доглядел? Надо будет сначала доки почитать - там могут быть описаны не замеченные мной изменения...

Что совсем удручает в XnView, так это портящие жизнь баги, которые живут уже годами.

Фиг-знает-сколько лет назад уже писал о багах авторам, но в последней версии они до сих пор есть.
Заново создал баг репорты, просьба заинтересованных поддержать.

1) jpeg-crop иногда безвозвратно фигачит фотографию, если она отображается на экране повернутой по exif-у (если вырезается малый фрагмент, то путается ширина с высотой кропа, результат - запарывается фотография - делайте бэкапы! )
Создал тему на форуме: http://newsgroup.xnview.com/viewtopic.php?f=36&t=31259

2) если выделить все фотки в папке и задать поворот на основе exif-а, то для каждого (!!!) изображения создается временный файл (даже тех, кого не нужно вращать)! В результате, если среди фоток требующих поворота немного, то проще выделить только их, чем ждать, пока будут бестолку копироваться все изображения в папке.
Приходится использовать альтернативу, которая такой фигней не страдает: http://forum.ru-board.com/topic.cgi?forum=5&topic=15055&start=1540#lt
Создал тему на форуме: http://newsgroup.xnview.com/viewtopic.php?f=36&t=31264

3) Еще раздражает периодически такой баг: при jpeg-crop-е пишется, что файл только для чтения (перезапуск чаще всего помогает) - локализовать баг не смог, но встречается достаточно часто.

Victor_VG
Вообще какая-то шутка юмора получается Идем в Настройки-Инструменты-Мышь, ставим настройки: Левая кнопка - Создание выделенной области, Ctrl-Левая кнопка - Перемещение изображения (т.е. меняем назначение комбинаций местами) - все работает как надо, возвращаем назад - и рамку выделения можно перемещать только с зажатым Ctrl.
Неожиданно видеть свой ответ, переведенный на английский на официальном форуме .

Yaromaxx

Так иначе бы этой ошибкой никто б и не занялся...

Подскажите где можно скачать плагины для XnView 2.25