FastRawViewer 2.0 (beta1-2)

Это продолжение, лучше сначала прочитать начало :)

Мы работаем по заявкам, если вдруг что-то неудобно, чего-то не хватает - вы пишите, мы прочитаем и сделаем ("сделаем" не обещаю, конечно).

В этом обновлении FastRawViewer 2/beta1 (build 1812):

  • Shift-Click на кнопках "копировать в главное окно", "обменяться с главным окном" многооконого режима будет еще и копировать параметры обработки RAW (экспокоррекция, контраст, баланс белого).
    Пока так. Если этот режим будет сильно востребован - сделаем или отдельный shortcut для такого, или настройку (копировать ли параметры).
    Если в двух окнах открыт один и тот же файл, то кнопка "копировать параметры" работает быстрее, чем "вернуть файл в главное окно" потому что происходит только применение параметров (и запись XMP), а не полный цикл открытия файла.
  • В описании новых фич беты не была описана галочка Enable History в (расширенном) диалоге переименования файлов.

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

Ссылки быстро устаревают, пользуйтесь поиском по рубрике FastRawViewer и берите из самой свежей публикации

Comments

Я почитал про переименование. У меня МНОГО вопросов и пожланий к этой фиче (я активно пользуюсь такой фичей в FAR3 с помощью стороннего плагина RESearch и я активно именно для картинок пользуюсь подобной фичей с помощью exiftool из командной строки).

Хочу в списке токенов все теги, что умеет Image::EXIFTool :) Например, я часто переименовываю в "префикс_${shuttercount}.ext".

Ещё было бы круто если бы вы выбрали для токенов не разделители пути а привычные любому кто писал скрипты ${var} или что-то подобное. Новичку одинаково понимать новые концепции, а хоть чуть-чуть знакомым с программированием привычнее.

Из документации неочевидно сработает ли /yyyy/ без dd и mm.

Жалко, что время нельзя (но это тоже к "все теги").

И, да, каталоги создавать можно? Можно ли переименовать всё в \target\/yyyy/-/mm/-/dd/\/Fn/?

Кстати, смотри чем плохи /токены/ если поддерживать каталоги — кошмар же а не строка. То ли там проэскейплено что-о то ли что. Ну и на MacOS ведь / это именно разделитель каталогов, нет?

/token/ выбран именно по той причине, что / в имени файла быть не может (ни в macos, ни в винде).
"всех тегов что поддерживает exiftool" точно не будет, используйте exiftool.
/yyyy/ не сработает, список токенов (пока?) закрыт.

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

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

(1) В документации: «/ddMMyy/, /MMddyy/ и так далее – EXIF timestamp (точнее только дата) файла в указанном
формате (dd – день, MM – месяц, yy/yyyy – двух/четырехзначный номер года)» — при словах, что список токенов закрытый, мне не очевидно, можно ли /yyyymmdd/ — единственный формат, который имеет смысл в имени файла. С дня начиная? С месяца? ЗАЧЕМ?! Сортировка же будет какая попало! И отсуствие разделителей тоже огорчает — мне как-то удобнее читать 2021-12-01 чем 20211201. А вам нет? Тут есть такая идея: сделать /date/ и отдельную настройку формата date ЧУТЬ ГИБЧЕ, чем порядок полей. Это не позволит ввести две даты в одно имя в разных форматах (сейчас такое теоретически возможно), но как по мне, это ещё более экзотика чем /ISO/ и точно не нужно вамим пользователям. А вот привычный формат даты – нужен.

(2) Все теги, конечно, не нужны. Но вот отсутствие времени И shutter count — это прямо больно. Поясню почему: фотоаппараты считают свой 4-х значный счётчик в имени файла. Если он в середине дня перевалил за 9999 в 0000, то невозможно держать файлы одного дня в одном каталоге в правильном порядке БЕЗ времени и БЕЗ shutter count. Мне кажется, это совершенно человеческая проблема, никак не связанная с гиками, нердами, фриками и тестировщиками камер.

Это общий ответ на все три ваших.

Shutter count - хорошая вещь. В кэноне - нету. В Sony - не инкрементируется если электронный затвор.

Ответ на вопрос "можно ли yyyymmdd" легко найти, если посмотреть на выпадающий дропдаун

Ну и да, "держать файлы в правильном порядке" FRV умеет и без их переименования.

И это, кстати, решает задачу нужной тебе нумерации без shutter count

В случае с датой - оказалось проще отдаться, чем уговаривать (тем более, что гибкий формат даты конечно кому-то нужен). /Dformat/ - дата в текущей локале, /DIformat/ - дата в International (английской то бишь) locale.
Со всеми понтами, которые поддерживает Qt'шный strfrtime (QDateTime::toString().

https://blog.lexa.ru/2021/05/30/fastrawviewer_20_beta1_3.html

Круто!
Мне кажется, это та гибкость, которая многим пригодиться (в отличие от /ISO/ и ./Aperture/, да, тут я с вами согласен).

Ну я среагировал на то, что yyyy-MM-dd действительно нужен, а делать еще и эти вариации в стандартной менюшке - ну такое, проще сунуть в тот (не наш) код, который ровно для этого

Я такой вариант как раз не предлагал (хотя в голове, конечно, держал, я помню про strftime) потому что он уж слишком программистский :-)

Поскольку в Qt оно сделано по человечески, без %, а прямо ddMMyyyy - то оно прям хорошо вышло.

Угу, такой подробности я не знал.

И спасибо за DI. Многие подобные фичи забывают об I. Видимо, потому что делают их американцы.

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

Ну чтобы "язык интерфейса" - в случае Qt нужно приложить чуть усилий (все выводимые строки обложить tr( )) ну и собственно трансляцию сделать.
Мы не делаем, слишком трудоемкое.

Я не про это жалуюсь, что у вас нет а про то, что тулкиты косячат.

Если авторы сделали, то QT косячит на винде с определением, что выбрать. И GTK косячит.
Они оба выбирают по Locale а не по MUI. У меня английский интерфейс и русская локаль - и все unix-портированные программы мне показывают русский. Хотя в терминах POISX грубо говоря у меня LC_MESSAGES английские. А у некоторых нет выбора вручную, приходится искать файлы с переводами и удалять. Я даже на консольные такие нарывался, типа gpg. А с GUI - ну любая, не на Win32 API так себя ведёт.

Мне Qt-шный Unix way поперек горла в другом месте
1) Некоторые вещи регулируются (и это, в ряде случаев, единственный метод) через переменные окружения
2) некоторый софт, перенесенный на винду, инсталлятором пишет эти параметры в глобальные переменные окружения.

Эффекты бывают, да.
(кстати, не исключено что в для Qt-программ локаль можно задать так втч и под виндой...)

Вдогонку хочется сказать следующее: за несколько лет существования Monochrome2DNG (и там еще несколько таких же утилит с именованием выходного файла по желанию) - реально пожелание пользовательское было одно, что-то в духе "кроме ddmmyyyy сделайте yyyymmdd".

То есть вот в реальности пользователи называют файлы по смыслу, это правда, а по /Aperture/ или там /ISO/ - только тестеры камер.

И еще вдогонку, да, скорее другим читателям, чем тебе.
У нас есть задача - удовлетворить процентов 90 пользователей. Выйдет 95 - ну вообще прекрасно.
Удовлетворить 100 (да и 98) процентов конкретно в этом месте невозможно - есть несколько процентов фриков, которые хотят странного (вроде "всех тегов exiftool"). По счастью, они, если точно знают чего хотят - уже точно знают как их задача решается другим софтом, а дублировать возможности даже нескольких продвинутых ренеймилок - ну у нас нет столько ресурсов (потому что всякие "Advanced rename pro" - всю душу вкладывают именно в переименование, а для нас - побочная задача).

Кроме того, есть unsafe вещи, вот к примеру "переименование с одновременным перемещением" - одна из них, так файлы и теряются (не знаю во что переименовал, не помню куда засунул - как искать то). И unsafe вещи мы стараемся не делать - потому что нам потом же поддерживать все это.

"Advanced rename pro" — это рак, как по мне. Очень “UNIX way” (тут я жалею, что не сделать кавычки 144-ым кеглем), конечно, в одном софте переименуем, во втором звёздочки расставим а в третьем ключ-слова пропишем. Только вот на деле это не UNIX way, UNIX way — он в первую очередь про Composability, именно ради этого «one tool for one task», а все эти Advanced rename pro никак между собой, FRV, Bridge и Photoshop не compose, увы. Никто не придумал как сделать Composability в GUI так, что бы этим могли люди а не инопланетяне пользоваться, увы.

Add new comment