Свежие комментарии

У меня Canon 100 macro не-L, в принципе проблема масштаба/яркости только на самых мелких объектах в полный рост встает, то есть на минимальных дистанциях фокусировки объектива. Если бы пришлось снимать объектив, как в этом посте, то уже незаметен был бы этот эффект, можно пренебречь. А с такими экстремальными фокусными перспектива наверно неприятная получится, плоскотня)
Content Aware как алгоритм хоть и гениально начал работать в последних версиях (бывает обращаюсь к нему когда нужно где-то целостность плавного градиента восстановить, руками такое дорисовать, с учетом естественного шума на фото - замучатся можно) но там, где детали и так есть свои, пусть фш будет добр доставать по-честному. Без выравнивания яркости вообще не знаю что бы делал (у меня мощность вспышек гуляет сильнее, чем от самого объектива, при проявке хоть на глаз подгоняю, но идеально не сделать), зебра получалась бы наверно если Zerene не правила сама

Что в фотошопе править легче очень сомневаюсь, не знаю как сейчас, но если в процесс ретуши, как раньше, представляет из себя переключение слоёв и редактирование готовых масок, то это крайне неловко. В zerene процесс ретуши очень удобен, одна рука на мышке - рисует кистью, которая проявляет детали, другая рука на клаве - выбирает слой, с которого берётся детализация, клавишами вверх/вниз. В хеликоне думаю тоже как-то по-умному должно быть, специализированный софт всё-таки обязан давать фору. А судя по результату сшивки в этом посте, фотошоп не айс до сих пор. Я уже привык к тому, что можно получать склейку, которая вообще не требует доработки, никаких заблюров, и это на полном автомате, нажатие одной кнопки у меня получается в Zerene, с настройками Хеликона в своё время не разобрался, поленился и быстро сдался, наверняка и там можно хорошо делать.

2-я галка в фотошопе - 'Content aware fill', она как раз про придумывание деталей, а seamless - про выравнивание яркостей.

Обе глючат

надо еще помнить что у DxO графики по Ssat ISO, a у клаффа по номинальному... и он упорно отказывается уравнятъ... так что сравнивая разных производителей у клаффа (да и мб разные модели одного и того же в некоторых случаях) надо помнить что по горизонтали там не одно и тоже...

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

Я вот приспособился по шкале у Batis - там DOF динамически пересчитывается от диафрагмы, но сбивается временами.

Ну таки да. С одной стороны.
С другой стороны - список этот конечен. И с точки зрения т.н. "маркетинга" разумно растянуть его лет на 15.

Вот по первой ссылке пишут: We added linker checks, so that mismatching VS 2010+ major versions will trigger hard errors at link time,

Вот что я могу сказать: v120_xp + v100 (смешаны именно "библиотеки", т.е. .obj) - полет нормальный.

Но и с чисто сишным интерфейсом снаружи (но ++ внутри) вот я бы боялся, что clang-овский тулсет захочет clang-овского же рантайма для всех этих std:: (и аналогично v120_xp не совместим в этом месте v100)

А интерфейс у библиотек при этом - C++ с использованием STL, или чистый C? Во втором случае - чего бы ему не работать? А вот в первом - вроде бы не должно быть совместимости.

autoconf, пожалуй, еще похуже будет.

Я использую qmake как мета-описатель процесса сборки, но
а) тоже не подарок
б) это никоим образом не замена cmake/autoconf, автоконфигурации там вовсе нет (но мне и не надо, наоборот!)

Ну решили что оверхед меньше 50% - не оверхед :)

Спасибо. Я пока оставил в претендентах 950-960 самсунг и M8PeY :-) (правда ещё соблазняет по сходной цене почти новый Intel 750). После чтения обзоров беспокоит нагрев и возможный троттлинг, особенно у M8PeY. У меня пока главные критерии выбора - скорость записи на уже заполненном ssd и производительность при смешанной нагрузке. Хочу ещё посмотреть как, L2ARC освобождает место под новые записи после полного заполнения. Заметил у тебя пишет и читает в среднем почти по 128kB, значит пишет в основном данные. А у меня слабое место промахи метадаты. Вот и родилась идея загнать всю её L2ARC :-). Получается если будет сжатие, то средний размер записи может быть сильно меньше.

Не было проблем. Но эта штука покупалась ровно под L2ARC, никаких других файловых систем там нет и не планировалось. Загрузка тоже не с нее.

"на что обратить внимание" я, честно говоря, не знаю, потому что у меня это вот единственный nvme под FreeBSD, он сразу завелся и стало хорошо.
Я выбирал из следующих соображений
- скорость чтения (!) - особо высокая не нужна, я все едино по 10G туда хожу, т.е. гигабайт с копейками - более чем. Скорость записи - ну тем более.
- "гарантированный объем записи" - с учетом того, что в реальности он много больше, чем заявляет производитель - особо на этот параметр не смотрел.
- и с учетом первого момента - выбрался Patriot Hellfire. Он сильно медленнее других моих NVME-шек (числом два: 950-й самсунг "под систему" и плекстор M8Pe "под локальные файлы), но и сильно дешевле, раза в полтора.
Смотрел еще на Intel 600p (еще дешевле), но он еще медленнее и уже медленее 10G.

Эксплуатация - ну скажем месяца три активных (минус лето, когда на эти тома никто не писал), за это время записано - 10Tb (т.е. 20 раз перезаписан). Заявленный ресурс - кажется 400Tb, то есть даже формального ресурса хватит, при таком же использовании, на ~10 лет.

Новые файлы.

Вот надо таки прочитать исходники zfs-mon, тогда будет понятно какие переменные оно так обзывает