FastRawViewer 1.4.4-1167 (beta2)

Текст устарел, вот новый: FastRawViewer 1.4.4 Release Candidate 1

Comments

> если выделены несколько файлов и текущий файл в группе выделенных

А хорошо ли это... раз выделил то выделил для операций... не важно какой там текущий уже... хотя если цель совместимость с массовым сознанием = LR и там так оно и есть, то в этом есть смысл

N/A

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

См билд 1161 (и выделено красным в тексте) - это место стало регулироваться.

душевно... а вот еще - я не знаю как другие пользователи... но я испорчен UI в других программах где по больше части - текущий файл он же и selected автоматически... никак нельзя заполучить опцию чтобы выбор (обе операции select/de-select) файла в FRV его бы автоматом делал и текущим при этом ? т.е. чтобы текущий файл не болтался где-то там сам по себе хрен знает где (раз уж он у вас не считается selected по умолчанию)...

N/A

Ну "select/unselect' в том смысле что "покрасить его красным и добавить в список выбранных" - это плохая идея т.к. если мы сначала текущим файлом попали на уже selected (с галочкой), а потом перешли на следующий - нам что ли галку снимать? Или завести там некий tri-state (выбран явно, выбран переходом)... ну это сильно усложнит все внутри.

Поэтому то что вы хотите надо делать иначе, добавлением третьей опции к этому выпадающему новому списку вариантов (на кого действуют хоткеи/пункты меню/кнопки на панелях): current+selected (в добавление к имеющимся current, selected).
Это потребует переделок унутре больше чем в 1-2 местах, но количество переделок поддается осмыслению.

Остается единственный вопрос: контекстные меню (на selected файлах), через которые можно сделать все то же самое.
Если мы оставляем их как есть, а именно контекстные меню работают только на selected (но зато и в single view режиме, т.е. на Filmstrip), то я пожалуй поддерживаю всю идею с третьим вариантом в настройках (т.е. я вот контекстные меню вовсе не хочу трогать - они сейчас все еще работают и не сломались и хочу и дальше не менять им логику)

> а потом перешли на следующий - нам что ли галку снимать?

я про операции select/deselect, а не про выбор текущего (на котором "фокус")... например у меня текущий файл "А" где-то далеко там и я сделал ctrl-click мышкой (select/deselect) на другом файле "B" (или попал ему в чекбокс в углу просто кликом) - и текущим сразу стал этот файл "B" ... это никак не отменяет ситуации возможной в FRV что текущим может опять стать другой файл "C" без того чтобы он стал selected (например мы в него просто кликнули мышкой, но не попали в чекбокс или сказали через меню/клавиши "(De)Select and move to next")...

N/A

Ну да, у нас осознанно разнесена отметка (select) и перемещение.

Я там задал другой же вопрос, ну да ладно уже.

Да, Ctrl-Click или чекбокс не делают файл текущим

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

Вот так и оставим.

А 1063 - правит ошибку в первом режиме.

А 1066 наводит еще больше общей красоты (особенно на маках)

В LR удобный инструмент для кропа/выравнивания. Но LR тормозит...
В C1 кроп ужасно неудобный, и раздельный с выравниванием.

А может этот функционал добавить в FRV? Он же независим от камеры и цвета, и пишется в XMP?
На основании того, как выглядит картинка в кропе, можно делать выбор. У меня в LR отбор кадров первым проходом всегда связан с кропом и горизонтом, реже - с цветом или экспозицией. Потому что последнее можно вытянуть, а композицию - уже нет...

Кроп/выравнивание запланированы на версию 1.5

Там не все так просто, как хотелось бы т.к. адобовский "полный кадр" и наш отличаются (наш чуть побольше, поля не оставляем), но для ~700 актуальных камер (из 1000 поддержаных) решим вопрос.

> Кроп/выравнивание запланированы на версию 1.5

т.е. даже не v2 ? а вот тогда вопрос - например режим (опционально) отображения thumbnail's с учетом этого и например ББ выбранного (ну это где-то сидит например в sidecar'ах) ?

N/A

Может и на 2
Как пойдет. То есть теория гласит что сделать просто.

WB - мы пробовали. Распрямить JPEG, поправить WB, загнуть обратно гамму - получается жопа.

Я хотел UniWB-шные жопеги так править в нормальные.

> Я хотел UniWB-шные жопеги так править в нормальные.

было бы хорошо с такой опцией... а thumbnail'ы генерировать постепенно из raw (медленно и кэшировать где-то как bridge например) совсем не кошерно в будущем ?

N/A

Их надо хранить тогда.

И это превращает FRV в бридж

>>> И это превращает FRV в бридж

но на стероидах же ... и почему собственно плохо быть бриджем в этом случае ? зато thumbnail's ближе к ...

N/A

FRV (пока) хорош тем, что делает ровно то, про что его просят (+ небольшой префетч). Что ценно, например, если работать от батарейки.

То есть сохранять *только* превьюшки от того, что мы явно отрендерили - это не нарушает вышеуказанное благолепие, но на самом деле (я еще немножко вперед в TODO заглядываю) этого недостаточно.

А рендерить в фоне все (да даже и все видимое) - это довольно накладно по ресурсам.

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

вопрос привычки, мне LRовский кроповорот противен и нелогичен, а в C1 он таки сделан в виде единого инструмента где-то в районе 9 версии.

Куда смотреть? В 10-й версии вынесенные на верхнюю строку Crop/Rotate/Keystone - на мой личный взгляд совершенно и невероятно чудовищны..... Но наверное я смотрю не то.

не смотреть - включать crop tool, кропать и пользоваться. кручение в комплекте.

keystone - возможно, но я им редко пользуюсь в силу специфики съемок.

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

Crop tool - это же кнопка C (кручение - R)?
Или я вовсе не туда смотрю?

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

Тогда я не понял в чем прикол.

В ACR (а значит и в лайтруме?) работает - в смысле принципа действия - в точности так же. Покропаное можно покрутить (прямо сразу, ничего не переключая никуда).

Ну разве что в C1 сетка, что несколько удобнее в смысле горизонт того.

в разной механике работы оных инструментов, подозреваю.

А, то что крутится картинка и вы видите как оно будет?

Вот это да, возможно.

ну видно и там и там - но грубо говоря в C1 ты двигаешь рамку, а в руме - картинку.

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

В лайтруме crop/rotate как-то приятнее сделан, imho.

Странные какие-то числа (расходится количество фоток с суммарным количеством XMP Rating)
https://1drv.ms/i/s!AribPYni9kAoi0jCGLHAYLNELf20

Что значит "Metadata unread"?

То и значит:
2841 Файл всего
2194 - метаданные (включая XMP) не читали
У тех у кого читали:
569 - нет рейтинга
78 - единичка
2194 + 569 + 78 = 2841, сумма сходится.

А если о сути, то:
- метаданные (включая XMP) не читаются, если они не нужны. Если вы, к примеру, поставите галочку "покажи мне только одну звезду" - тогда прочитает все 2841 файл. Это если при стандартных настройках.

Если нужно прочитать однократно для каталога - кнопка recycle (стрелки по кругу) и там "Forced full metadata read"
Если нужно читать всегда (вам такой ленивый режим не нравится), то Preferences - File Handling - группа "sorting & filtering" - снять галку "Lazy metadata read"
Ну и другой вариант чтобы читало метадату всегда - сортировать по ней (например, по EXIF timestamp)

А если я к этому моменту уже поставил рейтинг для ~200 файлов, это не считается (показывает 78)?

Остальные 130 - в метадате тех файлов, которые не прочитали??

Прочитайте таки все, я написал как

То есть история такая
- если вы поставили 200 файлам рейтинг
-и не уходили в другой каталог (и не закрывали программу)
То оно все помнит.
А если сессия прерывалась - то помнит только то что прочитали
А если уходили в другую папку - то кэш метаданнных могло почистить.

По тому что я вижу в вашем скриншоте - я не вижу никаких противоречий, сумма сходится.
А метаданные (всей папки) читаются целиком - в описанных выше (в предыдущем ответе) случаях.
Ибо если они не нужны - нахрена их читать то, диск дергать.

Ага, поигрался еще.
Значит там в некоторых случаях при установке рейтинга - оно мимо кэша делается, сразу в XMP.

То есть хотите видеть в этом месте корректные цифры - включите один из режимов который требует метаданных явно
- сортировка по EXIF (рейтингу, метке)
- фильтрация по чему хотите (кроме Selected, понятно)
- или выключить Lazy read

Я тот случай когда мимо кэша - конечно тоже починю к релизу 1.4.4

Вот в 1170 это место улучшено.
Если вы в большой папке (много файлов) сделаете Select All и поставите всем рейтинг, то metadata unread не будет.

Это по делу ни на что не влияет (потому что как только вы реально начинаете метадату использовать для сортировки/фильтрации - она прочитается), но выглядит аккуратнее.

я конечно может в последнее время много отмечал... и могу быть mentally impaired... но, a почему thumbnail который соотв. raw с меньшей экспозицией в FRV визуально более bright чем тот который соотв. raw в большей экспозицией ? может я что-то, где-то не так настроил ? xnviewmp например все показывает культурно ...

N/A

Без примера ничего не могу сказать (кроме того, что не включили ли вы часом автояркость для thumbnails?)

> не включили ли вы часом автояркость для thumbnails?

да !

а каков там алгоритм работы если не секрет - и нет ли места оному быть лучше ? таки странно все же что менее экспонированный raw выглядит более экспонированным... ладно бы ~таким-же по яркости в thumbnail, так ведь выглядит на 1+ более ярким... сцена если что - та же, менее экспонорованный он на ~2.5 стопа менее...

N/A

Он включается не сразу, а только если там есть 1.5 стопа пустоты в светах (в JPEG-иконке, не в raw)

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

> Давать туда еще и настройки

зачем настройки - не проще ли все выравнивать вправо (даже если меньше 1.5 в JPEG) и все ? ну это так, некритично...

N/A

Там одного ETTR недостаточно, если сильный недодер, нужно и гамму менять.

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

Выбор по Shift-Click не работает так, как это привычно во всех других программах.

К примеру, есть десять файлов. FRV только что запущен, никаких действий с файлами ранее не производилось.
Кликаю мышкой на 5-й. Потом Shift-click на 7-й. Ожидается, что выберутся файлы 5, 6 и 7. На самом деле выбираются с 1-го по 7-й.

Усложняем. Ставлю мышкой галочку на 5-м файле (или сочетанием Ctrl-/, или Ctrl-click). Файл выбирается. Потом Shift-click на 7-й - выбираются файлы с 5-го по 7-й. Снимаем все галочки (Ctrl-D). Кликаем мышкой на 7-й, потом Shift-click на 10-й - выбираются файлы с 5-го по 10-й... т.е. от последнего ранее когда-то руками отмеченного, хоть в данный момент на нём нет галочки.

Потому что click и ctrl-click в FRV - это разные действия.

Причина этого проста: в стандартной selection model (Explorer, Finder, да все программы) случайный клик не туда сносит всю выборку. Чудовищно же бесит. Соответственно, или клик в галочку, или Ctrl-Click.

Что касается второго момента, то при стандартных настройках Shift-Click отмечает диапазон от Last-Control-Clicked до Shift-Clicked. Это так и в Explorer (проверил даже в очередной раз в десятке), даже если выделение снималось перед этим через Select none.

Поведение ShiftClick может быть настроено скрытой настройкой ShiftClickSelectionMode (см. мануал, искать по этой строке)

Вот и я дозрел до работы с FRV - после полугода чтения всего, что смог найти на этом, англоязычном и смежных сайтах. Последней каплей было несколько постов Ильи в теме об идеальных конверторах на DPR.
Если могу ... пара глупых вопросов.

1) Как именно декодируются Raw файлы в текущей (или ожидаемой) версии FRV
2) Есть ли разумный способ использования XMP файлов после каких-то моих коррекций в FRV, если я не пользуюсь LR? Очень хотелось бы просто продолжить с того же места в следующей программе.

Спасибо!

Мне непонятен первый вопрос. Ну LibRaw (+RawSpeed + Adobe DNG SDK) декодируются.

2: пока "следующей программы" (нашего производства) не существует. Когда и если будет, будет конечно жрать XMP от FRV.

Спасибо, уточню вопрос: какой алгоритм применяется?

По поводу XMP: если продолжать работу после просмотра в FRV, то где, если не LR? Пока я нашел только всевозможные ограничения при открытии и использовании XMP, созданных на предыдущем шаге в других программах.

Алгоритм чего? Постпроцессинг свой, очень простой.

XMP: сейчас пишутся параметры в формате Adobe и в своем формате (libraw:...). Мы бы писали и в других форматах (C1, DXO, итп) но непонятно что писать, никто ничего не документирует.

Кроме XMP умеем писать еще .rpps-файлы для RPP (только экспопоправка /яркость/ и ББ)

XMP: сейчас пишутся параметры в формате Adobe и в своем формате (libraw:...). Мы бы писали и в других форматах (C1, DXO, итп) но непонятно что писать, никто ничего не документирует.

Нет шансов что-то сделать вместе с darktable for Win?

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

Спрошу! А вдруг ...

Беседа началась с этого:

"Edits made in fast raw viewer will not be read by darktable, except for possibly star ratings, keywords, and other very common metadata fields. Things like exposure adjustments, curves, and other editing tools will not carry over."

Дык что надо написать и куда, чтобы will be read....?

Детали обсуждения здесь https://discuss.pixls.us/t/darktable-for-windows/4966/132
Вопрос задан. Посмотрим.

Не могу проверить, так ли это, тем не менее - наиболее содержательный ответ:

"If some other software Y uses the exact same XMP scheme/tags/whatever as the lightroom, then you could use darktable’s rudimentary lr importer1 to partially mimic some of lr settings. And i do mean it, the conversion is not and never will be 1:1. Otherwise, no luck."

Ссылка на этот рудиментарный импортер: https://github.com/darktable-org/darktable/blob/master/src/develop/light...
Другие детали в ветке выше.

Можно ли проверить, насколько полезно то, что сейчас делает darktable в ограниченном объеме? Если, к примеру, читается и используется столько же, как и в случае с RPP - уже здорово.

Я опять не понимаю вопроса. что такое "можно ли проверить"?

- если не сложно. Вы знаете, что там искать.

Если можно сравнить вход импортера darktable и возможности FRV в плане записи - отлично.
Вы это, насколько я понимаю, уже проверяли с RPP (что там обрабатывается, что нет).

Я совершенно не понимаю что значит их исходник, тут надо контекст программы понимать.

Хорошо. Если исходника импортера XMP недостаточно, я попробую сделать два-три теста в FRV и посмотреть, как это выглядит в darktable - c/без XMP. Скорее всего, я увижу не все, но говорить от имени darktable я, естественно, не берусь.

Последний вариант darktable был опубликован месяц назад, это еще даже не бета. RPP я пользоваться не могу, LR у меня нет.

Я предполагаю, что дело кончится сообщением "не лайтрумовый XMP"

(да, глобально кооперация с dt для меня выглядит каким-то безнадежным предприятием, они очень странные по мне; при этом если у них есть какие-то sidecars /документированные, естественно/, пусть и не в XMP-формате, то поддержать их в FRV было бы не безумно сложно. То есть речь не о кооперации, а об использовании их "документированных фич")

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

я как-то мало интересовался dt, уж больно маргинальная вещь (тем более под виндой), но каких-то следов sidecar у них не видел (подозреваю что все в базе)

Очень может быть, версия под Win - совсем свежая. Но даже альфа как-то работает.

1) Вводные: darktable uses both XMP sidecar files as well as its fast database for saving metadata and processing settings. All Exif data is read and written using libexiv2.

http://www.darktable.org/about/features/

2) То, что в опубликованном руководстве:

http://www.darktable.org/usermanual/ch02s02s07.html.php
http://www.darktable.org/usermanual/ch02s02s08.html.php

3) Плюс, конечно, исходники: https://github.com/darktable-org/darktable

4) И последнее, что сейчас сказали: I’d just open up an XMP file and have a look. Darktable uses its own name space and the XML elements in XMP file are pretty self explanatory.
---

Пока так.

The FreeBSD kernel is very well documented, unfortunately it's all in `C'

По исходникам - пусть кто еще разбирается, я не буду.

Надеюсь, что там есть хоть что-то на естественных языках.

Честность - лучшая политика. Ответ мне понравился. Осталось провести эксперимент.

Цитата:
darktable on windows is still in early stages. If you’re having a problem please report it. The developers rely on users of their respective platforms to do the testing.

It seems that you’d want to export a LR XMP from FRV then try and import that into darktable. All these theoretical questions about compatibility can be solved by just trying it. Who has tested it on windows? I don’t know, I haven’t seen anyone report it as not working. No news is good news.

Не, я не понимаю. Причем тут windows? Читалка XMP общая же для всех платформ?

входит ли то, что описано в руководстве (в разделе про XMP), в версию для Win, и кто ее тестировал.

Как я понял ответ: не знаю / не знаю, проверяй, не работает - пиши.
Все это на случай. если не читать исходники.

Add new comment