FastRawViewer 1.4.4-1167 (beta2)

lexa - 14/Сен/2017 10:11

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

Comments

deejjjaaaa - 07/Сен/2017 22:29

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

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

Z / V

lexa - 07/Сен/2017 22:39

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

lexa - 08/Сен/2017 17:47

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

deejjjaaaa - 09/Сен/2017 05:19

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

Z / V

lexa - 09/Сен/2017 09:55

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

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

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

deejjjaaaa - 09/Сен/2017 22:25

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

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

Z / V

lexa - 10/Сен/2017 08:03

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

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

lexa - 10/Сен/2017 10:14

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

lexa - 10/Сен/2017 14:06

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

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

lexa - 11/Сен/2017 18:34

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

lexa - 13/Сен/2017 12:01

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

Archer - 10/Сен/2017 12:24

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

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

lexa - 10/Сен/2017 13:02

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

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

deejjjaaaa - 12/Сен/2017 19:43

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

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

Z / V

lexa - 12/Сен/2017 20:37

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

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

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

deejjjaaaa - 13/Сен/2017 06:13

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

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

Z / V

lexa - 13/Сен/2017 07:26

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

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

deejjjaaaa - 13/Сен/2017 16:03

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

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

Z / V

lexa - 13/Сен/2017 20:55

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

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

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

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

shadowfoto - 13/Сен/2017 17:16

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

lexa - 13/Сен/2017 20:44

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

shadowfoto - 13/Сен/2017 21:13

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

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

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

lexa - 13/Сен/2017 22:43

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

shadowfoto - 13/Сен/2017 23:14

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

lexa - 13/Сен/2017 23:39

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

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

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

shadowfoto - 13/Сен/2017 23:41

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

lexa - 14/Сен/2017 08:17

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

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

shadowfoto - 14/Сен/2017 15:00

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

lexa - 14/Сен/2017 15:10

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

Archer - 13/Сен/2017 23:48

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

Archer - 16/Сен/2017 15:36

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

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

lexa - 16/Сен/2017 15:53

То и значит:
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)

Archer - 16/Сен/2017 17:33

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

lexa - 16/Сен/2017 17:38

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

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

lexa - 16/Сен/2017 17:50

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

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

lexa - 16/Сен/2017 18:06

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

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

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

lexa - 17/Сен/2017 18:57

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

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

deejjjaaaa - 16/Сен/2017 23:19

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

Z / V

lexa - 16/Сен/2017 23:48

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

deejjjaaaa - 17/Сен/2017 07:45

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

да !

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

Z / V

lexa - 17/Сен/2017 09:11

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

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

deejjjaaaa - 18/Сен/2017 15:28

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

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

Z / V

lexa - 18/Сен/2017 15:40

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

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

Archer - 18/Сен/2017 00:50

Выбор по 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-й... т.е. от последнего ранее когда-то руками отмеченного, хоть в данный момент на нём нет галочки.

lexa - 18/Сен/2017 07:16

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

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

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

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

hardy - 13/Окт/2017 01:19

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

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

Спасибо!

lexa - 14/Окт/2017 11:11

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

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

hardy - 14/Окт/2017 21:32

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

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

lexa - 14/Окт/2017 21:47

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

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

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

hardy - 14/Окт/2017 22:09

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

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

lexa - 14/Окт/2017 22:47

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

hardy - 15/Окт/2017 01:51

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

hardy - 15/Окт/2017 20:43

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

"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."

lexa - 15/Окт/2017 20:55

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

hardy - 15/Окт/2017 21:37

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

hardy - 16/Окт/2017 17:22

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

"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 - уже здорово.

lexa - 16/Окт/2017 17:31

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

hardy - 16/Окт/2017 18:29

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

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

lexa - 16/Окт/2017 18:33

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

hardy - 16/Окт/2017 19:23

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

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

lexa - 16/Окт/2017 19:49

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

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

hardy - 16/Окт/2017 22:25

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

lexa - 16/Окт/2017 23:11

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

hardy - 16/Окт/2017 23:16

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

hardy - 16/Окт/2017 23:28

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.
---

Пока так.

lexa - 16/Окт/2017 23:40

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

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

hardy - 16/Окт/2017 23:46

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

hardy - 17/Окт/2017 01:24

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

Цитата:
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.

lexa - 17/Окт/2017 07:07

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

hardy - 17/Окт/2017 12:37

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

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

hardy - 17/Окт/2017 17:16

3-4 ответа были по делу.

https://discuss.pixls.us/t/darktable-and-lr-fast-raw-viewer-xmp-files/5369