blog.lexa.ru

У одного моего друга есть Acronis Workstation (v11.7, в покупке более новых смысла пока не увидел).

Этот бэкапер умеет пофайловый инкрементальный бэкап.

НО.

СУКА.

1. Допустим, у вас есть d:\folder\project и вы поставили ему галочку бэкапить
2. Но там есть подпапки debug, release, .vs (в которых, соответственно, debug-сборка, релизная, файлики от Intellisence)
3. Поэтому вы зашли в настройку бэкапа и сняли с них галочки.
4. После этого (нецензурно)
   • Если в d:\folder\project были добавлены новые файлы или там папки
   • То галочка на них как бы и не стоит
   • И они, соответственно, не бэкапятся.

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

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

И, в принципе, логика то в таком поведении есть. Хотя я бы предпочел другую логику: если не исключено явно, то таки бэкапить.

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

Либо наведенный морок, либо память подводит, но не нашел комментария, где меня ругают за weak https ciphers на blog.lexa.ru. А точно помню что он был, с месяц назад или около того.

Тем не менее, звезды сошлись, добрался до этого места (потратил, как водится, изрядно времени) и теперь тут так:

Имею сказать всякое:

1. Публикую не чтобы похвастаться, а отладки для: если что-то сломалось, сообщите pls.
2. TLS 1.0
...

А вот возьмем к примеру одну и ту же кривую (редактирования) и нарисуем ее в разных координатах (по обеим осям, конечно, одинаково):

(по клику будет чуть побольше).

В EV-координатах мы, понятно, не можем нарисовать от нуля, размер квадратика 10 стопов (и по X и по Y), на остальных картинках диапазон "0-1".

Эффект ожидаемый и понятный: в случае EV-кривой мы имеем больше места для редактирования теней (полутона, 3 стопа от насыщения, это правые/верхние 3 клеточки из 10). В случае линейной кривой - можем прямо вот идеально вывести света (полутона и тени - это чуть больше одной левой нижней клеточки). В случае гаммы - у нас середина примерно в середине, ну с какой-то точностью (почти точно будет для L* т.е. для эффективной гаммы около 2.5).

Но возникает ведь и другой вопрос: если кривая "в гамме", то в какой? Вот к примеру кривые для Adobe RGB (2.2) и ProPhoto (1.8) не будут одинаковыми (посмотрите как теневой хвостик отличается на картинке)

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

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

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

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

Новые фичи

• Новая настройка Touchscreen - White Balance dialog size
  Позволяет увеличить диалог ручной установки баланса
...

Обновился RawDigger 1.4 и стал Release Candidate, брать на английском сайте

В сравнении с предыдущим анонсом, добавилась поддержка камер:

• Canon EOS M200
• Nikon Z50
• Panasonic S1H
• Sony A9-II

И, вроде бы, более ничего