FastRawViewer 1.5.5-1591 (release candidate)

Продолжаем подготовку к выпуску FastRawViewer 1.5.5, по сравнению с предыдущим анонсом добавилось:

UPD: Обновлено 20.01.2020: в новой сборке теперь актуальное руководство, кроме того поправлена проблема с XMP с неверным форматом даты

Поддержка камер:

  • Canon EOS M200 (предварительная поддержка)
  • Nikon Z50
  • Panasonic S1H (уже был упомянут в предыдущем анонсе, но для полноты списка)
  • Sony A9-II

Новые фичи

  • Новая настройка Touchscreen - White Balance dialog size
    Позволяет увеличить диалог ручной установки баланса белого в тачскрин-режиме для удобства управления пальцами. Стандартное значение "+30%" (от размера для стандартного режима.
  • В некоторых случаях при переключении из режима "просмотра плиткой" в режим "просмотра одного изображения" на экране на долю секунды возникает предыдущее изображение, которое показывалось в режиме "одного изображения" в предыдущий раз (отмечено только на Windows и только при использовании графического режима DirectX11).
    Чтобы подавить этот эффект включите галочку Preferences - Grid / Filmstrip - Suppress image flicker on grid/single image mode switch
    Это сделано именно галочкой, поскольку подавление мерцания занимает заметное время (5-15 миллисекунд).
    Данный режим автоматически включится для пользователей Graphics Engine: DirectX11.
  • Capture One v20 добавлена в список известных программе приложений.
  • Новая скрытая настройка (через скрипт ExpandCurrentFolder/NoExpandCurrentFolder). Если включить, то текущая папка в панели Folders будет всегда открываться (показывая вложенные папки).
  • Новая настройка XMP - Accept XMP date fields in (wrong) YYYY:MM:DD format
    Предназначена для корректной обработки XMP-блоков записанных Exiv2 (не проверял какими версиями) в которых дата в xmp:MetadataDate пишется в неверном формате.

Исправлены ошибки

  • Если из текущей папки были перемещены все файлы (Move to/Move to _Rejected/Move to Selected) и затем возвращены в исходную папку через Undo, то корректная навигация между файлами включалась только включением/выключением режима "просмотр плиткой".
  • RAW-файлы с 16-битных камер могли некорректно показываться при включенном GPU rendering.
  • DNG-файлы, сконвертированные из файлов Fuji SuperCCD могли показываться с синим оттенком.
  • DNG-файлы, сконвертированные из файлов PhaseOne могли показываться с артефактами.
  • На первом/последнем файле в Filmstrip - стрелочки влево/вправо начинали прокручивать изображение в главном окне.
  • macOS Catalina: обнаружение перезаписи XMP для другого файла могло работать некорректно на сетевых томах.
  • Улучшена работа с DNG-файлами конвертированными из RAF-файлов от камер Fuji SuperCCD.
  • Улучшена работа с CR2-файлами, конвертированными из файлов от камер Canon D2000/D6000 files.
  • Исправлено падение при разборе метаданных объектива из (некоторых) файлов Sony.
  • Если дата в XMP записана в неверном формате, обработка XMP не прекращается, просто считается что там (в блоке/sidecar) нет даты.

И, естественно, включены все изменения предыдущей беты FRV 1.5.5, не описанные тут для экономии места.

Ссылки для скачивания

Comments

даже не знаю это мелкий баг или задумка такая... хожу я стрелками влево-вправо по файлам (вперед назад, как клавиши присвоили)... но вот например на последнем файле стрелка вправо при зуме где ширина картинки > ширина панелька просмотра начинает изображение скроллировать мне вдруг (понятно что дальше некуда идти - но скроллировать же не просили при этом).

N/A

PS: это если что в Windows 7-10/64bit, тестовая версия с Qt 5.12: FastRawViewer-1.5.5.1575-x64-Setup-Test.exe

N/A

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

Исправлено в build 1578 (только для стрелочек вправо/влево, если есть страдания от еще чего-то - пишите), ссылки выше обновлены, качайте, пробуйте, жалуйтесь.

Но брать надо 1579, в 1578 косяк с XMP

Я тут поменял религию и отснял первый отпуск на Fuji X-T3. И что-то у FRV и ACR цвета разъезжаются совершенно неприлично. Просто ничего общего. В ACR всё по нулям, но выглядит это вот так:

FRV - http://lev.serebryakov.spb.ru/_sklad/xt3/xt3-raw-frv.jpg
ACR - http://lev.serebryakov.spb.ru/_sklad/xt3/xt3-raw-acr.jpg
RAW - http://lev.serebryakov.spb.ru/_sklad/xt3/_DSF7023.RAF

Причём скриншот FRV почему-то МЕНЕЕ сочный, чем я вижу глазами, но это мне тебе вообще никак не показать — когда на пол-экрана FRV а на пол-экрана фотошоп со скриншотом — видно, что сам в окне FRV ещё более оранжевое, чем вот в этом скришоте!

С Pentax'ом такой колоссальной разницы не было.

Да, цветовая температура одинаковая и там и там.

И, да, в FRV мне нравится больше и как так укрутить ACR я пока не понял — это не сатурейшн, сатурейшн гораздо грубее работает.

Ну цветовые профили разные же ж.

Да вроде везде всегда у меня AdobeRGB выбран, и в фотоаппаратах (и Petnax и Fuji) и в ACR соответственно…

"установка цветового пространства (JPEG) не меняет RAW-данные", блин.

"Профиль камеры" это в смысле ее описание как "устройства захвата", ну то есть как из RAW 17-44-14 пересчитать в sRGB или там еще куда.

Для очень большого количества камер (и почти для всех современных) цветовые профили у нас свои. Совсем свои (но по чужим снимкам мишеней).

А у адоба вечная же беда с "морковным красным", уж не знаю почему.

А ещё у адоба оказывается не отключается коррекция линзы про встроенному в RAW профилю (раньше у меня не было таких RAW и я не знал этого).

Кажется, пора сказать «пока-пока» Адобу.

Но только на что его заменить!? Я так и не смог привыкнуть ни к чему у чего на движках экспозиции, теней и светов, кнопка "Alt" не работает. Такая простая фича — и для меня оказывается самой важной в RAW-конвертере и НИКТО не повторил :-(

А я даже не знаю что эта кнопка делает, если это *так* важно то поясни.

UPD: попробовал. Вылеты что ли смотреть? А просто включить галочку (на гистограмме в случае адобы) - не оно?

А удобно, блин. Да

Очень просто — если дивгать 5 движков, отвечающих за тоновую кривую (Exp/Highlights/Shadows/Whites/Blacks) с зажатой кнопкой Alt, то показывают не картинку а маску пересветов (Exp/Hi/Whi) или недосветов (Sha/Blacks).
Это гораздо удобнее (для меня) чем накладывание индикаторов на настоящую картинку и это то, с чего я чаще всего начинаю обработку — выставить всё в экстремальные значения, но без дефектов, а потом уже двигаться к середине.

И очень неуютно двигать подобные движки в других программах, когда я не могу ткнув в Alt на клавиатуре моментально проверить что у меня вылетело в ноль или наоборот в максимум.

А чувствительность этого добра как-то регулируется у адобы?

(скажем себе бы я бы поставил < 3 и > 250, если в 256-разрядной шкале, а может быть даже и <7-8 если под печать)

На сколько я знаю — никак. Это же Адоба, блин. Что у неё вообще регулируется?

Удобный трюк от C1 - черной пипеткой на каналах тыкаем в самое яркое сюжетно-значимое место - видим карту бликов и пересветов. Также белой пипеткой - в самое темное сюжетно-значимое место, создаем карту недосветов. Потом уже в эти места тыкаем в самое темное - черной пипеткой, в самое светлое - белой. Выставляем точку черного и точку белого. Без этого начинать обработку очень неудобно. Искать на глаз такие данные при любой насмотрености очень долго, нужен ускоритель для этих операций. Alt в адобе или такой вот аналог от фазанов.

если вы пользуетесь ACR то просто используйте X-Transformer (от Iridient) - он генерирует linear DNG с более приличным демозаиком для X-Trans CFA и по ходу дела там можно манипулировать с "коррекция линзы про встроенному в RAW профилю" - например отключить или передать для ACR DNG тэгами частично (отключить только коррекций виньетки)...

N/A

Спасибо.

«"установка цветового пространства (JPEG) не меняет RAW-данные", блин.» — это понятно (ещё бы меняло!) но она (установка), по идее, инструкция для RAW-конвертера, и если два конвертера понимают её по-разному (один делает в ARGB другой в sRGB) то понятно что выглядеть будет тоже по-разному.

Оно же потом выводится на монитор, конверсией из рабочего пространства в мониторное.

То есть если нет загамутных цветов (которые лезут в Adobe, но не лезут в sRGB) то разницы в первом приближении не должно быть (а во втором - часто вместо ломаной гамма-кривой sRGB применяют просто гамму ну и тогда микроскопическая разница будет).

RAF не тот!

Ой, да, 23 и 32 попутал http://lev.serebryakov.spb.ru/_sklad/xt3/_DSF7032.RAF

Ну да.
Я не знаю какой там был оригинал, но вообще можно взять фото мишени и прямо вот посчитать dE. По идее, у нас должно быть получше.

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

Это, на самом деле, сложный очень цвет.

Для другой камеры помню специально выводили наш встроенный профиль - потому что кожаное кресло кориченевое выглядело неправильно (и в том конкретном случае - у адобы было лучше)

P.S. А что JPEG такой странный у этого кадра? Там HDR какое было включено что ли?

Про JPEG я сам пока не понял — и сам удивлялся. Вроде как у меня включено "Dynamic Range: Standard" из значимых настроек, но я не могу сказать, что досконально (или хотя бы просто хорошо) разобрался с настройками новой камеры.
А доокументация у Фуджи так себе. Т.е. из настроек, которые кажутся релевантными:

Film Simulation: STD
Dynamic Range: DR-P (и настройка задизейблена, я не могу поменять, и я не знаю от чего это зависит)
D Range Priority: Auto
Highlight Tone: DR-P (и настройка задизейблена, я не могу поменять, и я не знаю от чего это зависит)
Shadow tone: DR-P (и настройка задизейблена, я не могу поменять, и я не знаю от чего это зависит)

И всё это очень плохо объяснено в документации — вот почему три настройки вообще задизейблены? Почему превьюшка такая выровненная? Чёрт его знает. Кстати, в видоискателе (тут же EVF) было скорее как на превьюшке, чем как в RAW.

D Range Priority: Auto — это, кажется, оно. Блин. Это автоматический недосвет (в RAW!) если умная машина решит что лучше поберечь света. Блин-блин-блин. Почему я не нашёл эту статью раньше и не поставил тут OFF?!

UPD: Или нет, RAW оно не меняет. Описание очень противоречивое: с одной стороны пишут, что влияет только на JPEG Engine и опицю в RAW (т.е. метадату), а с другой описание работы включает слова « The RAW file is underexposed by either one (DR200%) or two (DR400%) stops. Highlights are darkened, shadows are darkened even more.»

Да-да, Shift-A в FRV говорит мне, что +2EV можно в плюс (ну в стандартных настройках, 1% в вылет)

Чтоб я ещё раз поверил настройке Auto :)

Хотя на форумах это много обсуждается и как-то консенсуса, меняется ли RAW (данные, а не мета), нет. Надо как-то искуственно создать такую ситуацию, поснимать и посмотреть в RAW Digger'е.

Дело же не столько в RAW данных, сколько в замере. Если оно недодерживает (на два стопа?) то RAW-данные понятно что меняются.

именно это известно очень давно для Fuji - комментатор просто камеру купил, а форумов не читал

N/A

Ну да, купил, буквально за сутки до отлёта (долго денег жалел), и прочёл в самолёте официальную мурзилку.

консенсуса нет у тех кто не смотрел внутрь raw никогда - DR просто обычная манипуляция с недодержкой... если вы снимаете в raw - ставьте у Fuji всегда DR100% и все

N/A

Ну вот и на dpreview я вижу споры и много где ещё. Но я уже понял, что это РЕАЛЬНАЯ недодержка, а не просто матобработка.
Я идиот, ага. Интересно, сколько снимков она мне недодержала (у меня стояло и не 100% и не 200% и не 400% а автомат)?

Или вот, сегодня как раз полез читать, задал автору вот этого поста вопрос, он уверяет, что RAW data doesn’t change:

https://www.jmpeltier.com/fujifilm-dynamic-range-settings/#comment-9011

Хотя, глядя на эти картинки, что-то не верю я ему :-)

если дать камере недодержать то конечно raw data будет другой - но смысл в том что проще статить DR100% и если уж недодерживать то самому лично... PS: мелкий плюс если например обрабатывать в ACR/LR то там часть DCP профиля применяется до "экспокоррекции" конвертером (и/или руками соотв. слайдера в UI) а часть - "после" что может влиять на цвет если профиль так сделан ( см писания автора dcptool )

N/A

Да уж лучше я сам, да. Главное, поставил ведь я не DR400%, а D Range Priority: Auto. Что это может привести к недодержкам в RAW — совершенно не очевидно.

Ниче, я как-то развлекался с sRAW и потом изрядную часть большой (и, как обычно у меня - уникальной) поездки отснял в sRAW на четвертинке разрешения. Потому что настройки камеры так и остались.

Тоже было неприятно. Но стал ученее зато.

Ну а уж кто на ярком солнце не снимал с ISO1600+ :)

Такое ощущение, что встроенный JPEG отрендерен без учета (или игнорируя) RAF Raw Exposure Bias (там -1.7 прописано в makernotes). Какая установка в камере к этому приводит - я не знаю. В терминах exiftool - подозрение падает на
[MakerNotes] 0x1443 DRangePriority: Auto
[MakerNotes] 0x1445 DRangePriorityFixed: Weak
В таких случаях приходится съемкой проверять, варьируя установки камеры.

Я бы сказал, наоборот. Они учли этот bias. С обратным знаком. Т.е. отреверсили его ради сохранения хайлайтов. Это всё сходится с описаниями работы этого режима на форумах (но, мать его так, не в официальной документации!)

Установка уже понятно какая — "D Range Priority: Auto" которая по своему разумению включает настройку "Dynamic Range" в 200% или 400% (недодержка стоп или два соотвественно, вытягивание при обработке).

Ну это "как удобнее сказать". Какая установка - мне не понятно, пока нет пары raw с и без ;)

Я поэкспериментирю завтра и с ручной установкой (100%-200%-400%) И с автоматом (попробую спровоцировать его включиться) в лабораторных условиях. Надо сделать очень контрастную сцену, в Питере в декабре не имея студийного света это непросто :-)

Спасибо!
Идентичность данных raw - RawDigger хорошо показывает. Да и FastRawViewer неплохо.

Это-то понятно, что RawDigger :-)

Вы точно в Питере?
В каждой "фотостудии" есть. Начиная от "почти Pro" до откровенного "энтри лэвел". Десятки их в Питере!
Даже у меня дома, плохонький, но студийный свет есть.
Если старенький (но не убитый!) Raylab устроит, вэлкам! Оно даже в (гробу) родном кейсе.
:-)

Я точно в Питере. Но я не на столько альтруист, что бы ради 5 совершенно технических снимков тратить время, силы и деньги на поиски и аренду студии. Увы. Дело на 95% во времени и силах, 2-3 тыщи рублей за час студии я могу себе позволить :) Но вот выбирать, обзванивать, выяснять где есть время тогда же когда у меня есть свободное время... Студия — это 2-3 часа одним куском реально. Поехать, снять, вернуться домой или на работу. Не считая выбора и утрясания планов. У меня в редкий день, увы, есть 2-3 часа свободного времени одним куском. Это значит или я не готовлю еду дома или раньше ухожу с работы (и потом надо будет отработать) или подвожу членов своей команды ЧГК, не явившись на игру или тренировку…
Даже 30 минут спокойных и свободных просто дома у меня вот не было пока, увы.

Раньше у меня были DNG и я не бюоялся их менять exiftool'ом. И прописывал GPS прямо внутрь DNG, причём EXIF-тегами (как по-умолчанию делает `exiftool -geotag`). Эти координаты FRV отлично показывает, и даже удобнее, чем Bridge.
Теперь я боюсь RAF'ы менять и я прописал GPS-координаты в XMP, в формате XMP. И вот FRV, когда есть RAF файл и рядом XMP-файл только с координатами, FRV этих координат не видит. Чтение XMP разрешено.

FRV никогда и не брал этих данных из XMP.
Заявка понятная, написал в TODO на "когда нибудь" (без конкретной версии).

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

Ага, просто думал что если XMP включён то он читается поверх родной метадаты и всё. Я бы это программировал так. Понятно, что вообще вопрос приоритета источников — сложный.

http://lev.serebryakov.spb.ru/_sklad/xmp-gps/

Вот тут две пары файлов. 7007 — это как прописывает Exiftool (минимальный XMP получается). 7008 — это как прописывает Bridge если вручную отредактировать поля Lat/Lon.

Скачал, можно того.

XMP и EXIF данные не объединяются, они про разное же ж (ну вот кроме GPS как видим)

Ну вот самое смешное, что в XMP для GPS пишут EXIF-теги. Я думал это exiftool чудит, но проверил бриджом — и тоже, как можно видеть.

Другие EXIF-теги тоже могут быть и в XMP. Любые, как я понял. Bridge вот, как мы можем видеть, копирует из RAW всё в XMP при его создании.

Но вообще-то, в случае DNG могут быть XMP-теги и внутри файла и в сайдкаре. Да и в случае RAF тоже — я проверил, exiftool внутрь RAF спокойно пишет XMP (внутри которого GPS-EXIF-теги, ага, вот такая солянка — в бинарном RAW вписан XML внутри которого GPS-координаты в EXIF-тегах записанных текстом) и Bridge это понимает. Другое дело, что в RAF я писать не хочу. В то, что DNG не повредится, я верил, а вот с RAF — не очень-то.

Да, конечно, в XMP бывают Exif-теги.
С понятным к ним вопросом "ну и что с ними делать то"? Ну к примеру в случае, когда они расходятся с тем, что в самом файле.

«онятно, что вообще вопрос приоритета источников — сложный» писал я в самом начала, ага.
Как всегда можно настройку привернуть — RAW/XMP/What was changed last :) Вообще, в мире всякое бывает, но я бы сказал, что когда есть XMP то считать его приоритетом — логично. Если человек уж создал XMP, то, наверное, он не лез ПОСЛЕ ЭТОГО руками в сам RAW и XMP «актуальнее»…
Ну, если смотреть на жизнь трезво.

Это как с девушкой и мужчиной, занимающимися сексом в публичном доме — может это горничная и сантехник, и они муж и жена, но всё же скорее это клиент и работница :)

1) Ты не знаешь what changed last. В XMP есть MetadataDate, в EXIF - нету (а редактировать EXIF по живому вполне можно)
2) Соответствие между тегами (у которых есть тег и тип) и строковыми названиями - нет, ну догадаться можно, но вообще я бы без таблички более-менее официальной даже и не стал бы :)

Вообще же, когда источников два (embedded XMP и sidecar) - ну уже непросто. Когда их три и они еще про разное - совсем труба.

Вот увидишь, придется в настройки добавлять "если GPS есть и в XMP и в EXIF, какой предпочитать...."

1. У EXIF есть дата изменения файла. Самого контейнера. Лучше чем ничего. Опять же, можно править EXIF по живому, а потом mtime руками вернуть файлу — кажется, все OS это позволяют — но это, вот натурально, надо постараться, и если так кто-то делает — ну, он сам себе злобный Буратино. ни один разумный программист его поддерживать не обязан.
2. Табличка, думаю, есть в XMP SDK, ведь как-то Bridge делает эту копию всего при создании XMP. Так как Adobe Является источником ИСТИНЫ про XMP, то её можно считать официальной :-)
3. Ну да, непросто, если пытаться покрыть всех извращенцев, что крутят времена туда-сюда вручную :)

"нормальный тул" для редактирования EXIF конечно должен предлагать вернуть mtime (должно ли это быть умолчанием - вопрос, но скорее да, должно).

Типичный use case (ради которого мы делали возвращение mtime для JPEG - ибо мы умеем туда писать XMP внутрь):

1) Хочется смотреть по времени съемки (ну, ок, камеры увеличивают номер, но он враппится)
2) Даже если он не враппится - возьмем две камеры (и телефон!)
3) Конечно, можно смотреть по EXIF timestamp, но чтобы по нему сортировать - надо всю метадату всех файлов прочитать, а по mtime - только каталог.

Если при редактировании EXIF слетает mtime, будет плохо (и жалоба на это от юзера была буквально вот на днях, ну он сам не разобрался, но тем не менее)

EXIF timestamp кстати тоже есть повод покрутить (и/или mtime), если ты уехал в другой часовой пояс то смотреть "время съемки 2 часа утра" - неудобно.

Короче, да, mtime в 99% случаев решит проблему, а в условном 1% - будет жопа. И проще таки сделать галочку "XMP или EXIF", поставить ее в XMP стандартно, а 1% извращенцев смогут настроить под себя.

Это кстати тоже отдельный секс, если есть отдельно gpx-трек, есть mtime в EXIF, но в процессе съемки часовые пояса менялись....

Это секс знакомый, да. Ну, прописываем кусками. Я вот так сейчас и делал — три таймзоны в отпуске.

В общем, таймзорна же у Exiftool в командной строке задаётся. Т.е. у меня фотографии всегда в локальной таймзоне, ну а GPX всегда, понятно, в UTC. Делим RAW'ы по таймзонам и запускаем Exiftool N раз, а как ещё...

То есть вот ты переезжая из таймзоны в таймзону - переставляешь часы на камере?

Да. Ну, точнее, все камеры, что у меня были, позволяют переставить именно таймзону (и там их обычно две — Home/Travel Или Home/Local, в зависимости от камеры разные названия), что бы минуты-секунды не трогать.

Всё равно наручные часы надо переставить. И иногда мобильник, не во всех странах таймзону можно получить из сети (вот в России — до сих пор нельзя, кажется).

Вот последнее одобряю!

Табличка в XMP SDK есть, только там "табличка + код" потому что куча тегов "// ! Has a special mapping."

Но, в принципе, те которые без special mapping даже можно и прочитать "обратно в EXIF"

Мда, одна загадка (которая, впрочем, FRV не касается, мы высоту не показываем):
81497/1550
Это что значит то, нужно поделить одно на другое что ли?

И один "момент" - нету GPS Status, который мы наоборот смотрим (это по сути "можно доверять координатам или нет", ну да будем считать что можно если поля нет).

Думаю, это Rational число, да. Температуру пишут как XXX/10 :) Почему 1550?! Хм. Это футы какие-то?
Загадка, да.

Интересно, а вот тут есть GPS Status [0]? Потому что это DNG с вписанным exiftool'ом GPS'ом. Т.е. если тут есть а в XMP нет, то это бага в Exiftool, когда он в одном случае вписал а в другом — нет. В этом DNG FRV отлично показывает координаты.

[0] — http://lev.serebryakov.spb.ru/_sklad/xmp-gps/_IGP1258.DNG

Нету статуса.
У нас есть галочка где-то в настройках "показывать если status == void"

Надо, наверное, отрепортить в exiftool

Add new comment