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

И, да, в FRV мне нравится больше и как так укрутить ACR я пока не понял — это не сатурейшн, сатурейшн гораздо грубее работает.

Сделаешь - хорошо, не сделаешь - тоже хорошо. Во втором случае, наверно, надо в инструкции написать, что есть такой эффект. Я, вот, поскольку RD пользуюсь пару раз в год, постоянно забываю, что есть такой дурацкий эффект.

Ага, да, понятная проблема (и наверное надо что-то с ней сделать конкретно для сонек/compressed).
Пока не сделали, лечение такое:
Диггер - Preferences - Over/Underexposure
Overexposure detection: by histogram
Auto OE Offset: -0.1EV (-0.05 тоже сойдет, но там шаг 0.1, а 0.05 надо руками вбивать)

А можно как-то напомнить суть проблемы?

Ну то есть да, они ведут себя по разному (в частности, у FRV точность карты экспозиции - 1/10 стопа, если не запамятовал; кроме того FRV показывает же с примененной "адобовской коррекцией", если по умолчанию), но в принципе обе программы можно настроить чтобы показывали близко.

Чисто технически ДА. А вот с практической точки зрения, частенько просят помягче делать. Что бы резкость и детализация не очень в глаза лезла. Но для архива однозначно подходит.

Получилась узкопрофессиональная опция, для предметчиков и для репродукционной съёмки.

"народ на пентаклубе" пишет какую-то вообще непонятную херню:

"из ACR на мой взгляд получается картинка лучше, может еще не понял как и что) "

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

Но вообще, да, у PixelShift (для этой утилиты) высочайшие требования к не-смазу и к качеству оптики (во всяком случае, в случае сони).

Но брать надо 1579, в 1578 косяк с XMP

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

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

Спасибо за труды! На днях пытался настроить Qt creator чтобы собрать приложуху под старый планшет Android 4.0.1 И... на ноутбуке тупо не хватило емкости накопителя под все эти тулзы)). Но интересно, конечно. На работе по вашей статье попробую)

В такой ситуации latency же а не bw. А latency у этих HEDT как бы не похуже?

(ну и графы эти будут в кэшах конечно ж)

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

Ну и поскольку у меня Core 9700 на столе, а Core-X 7960x под столом и частоты у них, так получилось, одинаковые (9700 чуть придушен по TDP, а Core-X разогнан) и базовые частоты памяти одинаковые (3200), вот про прочие тайминги памяти не знаю - то я, получается, периодически сравниваю (в уме, не бенчмарками) 8 и 16 ядер (и 2/4 канала памяти).

Сравнивать их впрямую непросто, потому что на 9700 у меня макос, а на 7960x - винда. Т.е. даже банальная скорость компиляции несравнима (clang/microsoft). Блендеров и синебенчей не гонял (и не проси, не буду)

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

И всякая простая многопоточность, вроде OpenMP (и подобного: QtConcurrent) - на очень многих ядрах не блистает.

Я не знаю как сделан блендер/синебенч, но вообще заглянуть в профайлер на 16-24-32 физических ядрах было бы очень полезно. Просто тупо посмотреть на wait в VTune (это можно и на бинарнике без символов). Совершенно не исключено, что там есть огромные резервы.

И возвращаясь к первому абзацу и к твоему вопросу: я бы сказал, что очень мало задач, где 16 ядер прямо вот вдвое быстрее чем 8. Их, скорее, нет, таких задач. Амдал не дает. Соответственно в среднем по больнице нагрузка на память у 16ядер/4 канала - как бы не меньше (но это не значит что 16 ядер/2 канала памяти не будут тормозить)