Sigma Dp0/Dp1/Dp2/Dp3/SD/SD-H Quattro. Основы работы с камерами, их сравнение. Объективы для SDQ/SDQ-H. Особенности обработки X3F (RAW)

Ну и небольшой перевод второй части (сравнение изображений с Q и M)
(http://philservice.typepad.com/Sigma_Merrill_vs_Quattro/2_Image_Comparison/Sigma_Merril_vs_Sigma_Quattro_2_Image_Comparison.pdf)
[quot]5.1. Сравнение «больших» изображений
Эти сравнения говорят сами за себя и не требуют излишних комментариев. Изображения Quattro явно превосходят (Merrill - пер.) в деталях, по меньшей мере в пяти из шести парных тестов. В целом, изображения Quattro имеют гораздо лучшую визуальную передачу поверхностей скалы, коры и древесных волокон.
В Сцене 4 («Лишайник и ...») изображение Merrill-а показывает чрезвычайно плохой результат на пятнах лишайников в середине изображения. Я думаю, что только в Сцене 3 ("Кактус") можно признать лучшим изображение с Merrill-а. В частности, он лучше показывает тонкие поверхностные вариации кактусовых подушечек в верхнем правом и нижнем левом углах. Тем не менее, небольшие шипы вдоль поля большой площадки (в центре справа) намного более четкие на изображении с Quattro.
Учитывая, что изображения Merrill-а были подвергнуты выборочному увеличению для сравнения в «большом размере», эти результаты не особенно удивительны. Вполне возможно, что какой-то другой метод увеличения изображений был бы лучше, но маловероятно, достаточным чтобы полностью оправдать разницу в результатах. Следует также отметить, что тени в изображениях Quattro обычно более «открыты» и имеют более четкие детали. Это согласуется с предыдущими тестами, показывающими, что датчик Quattro имеет более широкий динамический диапазон.

5.2. Сравнение «маленьких» изображений
Когда изображения Quattro уменьшены в размерах до размеров изображений с Merrill-а, эти два датчика выглядят очень сопоставимо. Во многих случаях отдача предпочтения одному или другому будет являться в основном вопросом личного вкуса.
Мелкие детали в изображениях Merrill кажутся немного более «укусными», или, возможно, микроконтрастными. Тонкие же детали в изображениях Quattro кажутся более тонкими или «деликатными». С точки зрения того, кто предпочитает рендеринг Quattro, детали в изображениях Merrill могут показаться немного грубыми. Аналогично, любитель Merrill посчитал бы изображения Quattro немного мягкими, а детали недостаточно «ударными».
В целом, я думаю, что у меня сложилось очень небольшое предпочтение к изображениям Merrill по сравнению с изображениями с Quattro, которые были уменьшены в размерах для сопоставимости. Хотя это мнение может измениться, если уменьшение размера (Quattro - пер.) производить с помощью другого метода понижающей дискретизации или другой последующей обработки. В частности, в этом случае изображения Quattro наверное можно улучшить с помощью разумного применения слайдера Clarity в ACR.
Одна вещь, в которой Quattro последовательно выигрывает у Merrill это передача теней, как это было и в случае с «Большими» изображениями.

5.3. Другие соображения и выводы
В соответствии со спецификацией, dp1Q оснащен другим объективом - не таким же, как в dp1M: есть очевидные различия в искажениях между изображениями, снятыми из одного и того же места. И, помимо искажений, неясно, как различия в объективах влияют на сравнение изображений (сцены 1 - 4). Кроме того, я не знаю, есть ли оптические различия между dp2Q и dp2M (сцены 5 - 6).
Основываясь на представленных результатах, я не вижу убедительных доказательств того, что датчик Quattro уступает Merrill в способности фиксировать очень мелкие детали и тонкие нюансы текстуры.
Изображения Quattro явно превосходят изображения Merrill, в случае их увеличения до размеров Quattro. Кроме того, изображения Quattro, как правило, лучше сбалансированы между цветовыми каналами и обладают более широким динамическим диапазоном. Они гораздо менее проблематичны при обработке в SPP (хотя сам SPP остается мучительно медлительным).
Было бы огромным преимуществом для пользователей Merrill и Quattro, если бы Sigma и Adobe могли объединить усилия, чтобы обеспечить совместимость X3F с с Lightroom / ACR[/quot]

Цитата:

от: walker999
Интересный ресурс: http://philservice.typepad.com
Статьи - в pdf, что очень удобно.
Ну и, может кому-то пригодится: http://www.stv.ee/~donq/sigma.htm

Спасибо!!!! Вынесу вечерком в шапку. Бегло просмотрел - много приличной инфы и замеров, сделанных не по г@внофоткам, а по колорчекеру в разных режимах и с использованием рав-диггера.
Результаты/фактура вынесены в таблицы - все читабельно и понятно. Если проблемы с английским - ставьте хром, там есть автоматический перевод. Английский почти классический - переводит понятно. Выводы вынесены отдельно - можно их только просмотреть. Есть сравнения мерилов и кваттр, и для нас интересны, в первую очередь, кваттровые сенсоры. Выводы помещать тут не буду - источник открыт - все прекрасно читается. Можно и выше глянуть - пост bnxvs (если есть возможность, плиз, можно шрифт поболе сделать в переводах?)

http://www.sigma-global.com/jp/download/cameras/sigma-photo-pro/

Цитата:

от:Жарик

http://www.sigma-global.com/jp/download/cameras/sigma-photo-pro/

Подробнее

Спасибо!!! Обновлю вечерком шапку... Сейчас в жуткой запаре...

ОЗУ 16.0 ГБ

при этих параметрах из папки рабочего стола(18 файлов X3F SDQH) открывает за 10 сек. записывает туда же JPEG за 5 сек.

Обновить данные об объективах!

Мак-оводы, не торопитесь.



p.s. Мля, когда уже сигмовские программеры руки из ...опы вынут наконец? (риторический вопрос).

p.p.s. 2 srgs
Цитата:

от: srgs
если есть возможность, плиз, можно шрифт поболе сделать в переводах?

Сделано! Пойдет?

Цитата:

от: bnxvs
....
p.p.s. 2 srgs
Сделано! Пойдет?

Норм.... спасибо!!!

Обновил шапку: SPP 6.5.2
Что нового:
It has improved the noise reduction during the RAW development from the X3F files of dp Quattro series and sd Quattro series.
It has improved the processing speed when the GPU Acceleration Mode is activated in the environmental setting (based on the computer environment, the effect may vary).
It corrects the phenomenon that some operational errors occur in specific computer environments, when GPU Acceleration Mode is activated.
It corrects the phenomenon that depending on a computer environment, an error occurs during RAW development, when the GPU Acceleration Mode is activated and multiple images are selected.

* Since SIGMA Photo Pro ver. 6.5.0, it has changed the system requirements to equivalent to Intel Core 2 Duo Processor or more (equivalent to Intel Core i series is recommended) and 3GB or higher RAM (8GB or more is recommended). In addition, it is not possible to use the functions of printing, slideshow and multiple displays of Review Windows in the 32bit OS system. To use these functions, please use SIGMA Photo Pro 6.4.1. Please download from here - http://www.sigma-global.com/common/download/cameras/sigma-photo-pro/data/SPP_6.4.1_setup.exe
* For customers who cannot use the GPU Acceleration Mode, please refer to this webpage.

Обновил список литературы в шапке (спасибо камрадам walker999 за поиск литературы и bnxvs за перевод выводов - выше по форуму )

Протестил на своем компе новый SPP 6.52 по сравнению со старым SPP 6.51... Для этого собрал в папку 15 X3F от Sigma DP0Q и пакетно конвертировал их в режиме АВТО в 16-ти битные tif'ы (каждый по ~ 117 мб на выходе). Результаты:
SPP 6.51
без GPU - 4 мин 31 сек
с GPU - три кадра обработал и софт завис - результат = 0
SPP 6.52
без GPU - 4 мин 52 сек
c GPU - 2 мин 16 сек
c GPU + использовать доп. память для ускорени - 1 мин 39 сек

По крайней мере для моего компа работу с GPU починили и ускорение в два раза )). Без GPU малость тормознее стало, хотя один фиг...
Конфигурация компа: Win10/64, 64 гига DDR4, видео - Palit GeForce GTX 1080 1746Mhz PCI-E 3.0 8192Mb, SSD (на нем обрабатывались файлы) серверный Intel 3610 (средний по скорости), проц. i7 (Kaby Lake)

Цитата:

от:srgs


* Since SIGMA Photo Pro ver. 6.5.0, it has changed the system requirements to equivalent to Intel Core 2 Duo Processor or more (equivalent to Intel Core i series is recommended) and 3GB or higher RAM (8GB or more is recommended). In addition, it is not possible to use the functions of printing, slideshow and multiple displays of Review Windows in the 32bit OS system. To use these functions, please use SIGMA Photo Pro 6.4.1. Please download from here - http://www.sigma-global.com/common/download/cameras/sigma-photo-pro/data/SPP_6.4.1_setup.exe
* For customers who cannot use the GPU Acceleration Mode, please refer to this webpage.
)

Подробнее

Ну что, я подозревал, что это время настанет. Сигма сочла мой проц очень старым (AMD Phenom II X4 965@3,9 ГГц AM3, 16 Гб, DDR3 1600, AMD FirePro V4900). Последний СПП вылетает с ошибкой. Спасибо тебе, любимая компания, за то, что разрешила хоть версией 6.4 пользоваться! Я надеялся увидеть тот момент, когда наконец SPP 6 начнёт отрисовывать эскизы с папке с фотографиями быстрее и скроллить можно будет без лагов. Увы!

Так что там с 6.5.2, как скорость?

Скорость как и в 6.5.1 при стандартном функционале. Подлатали косяки и разогнали обработку при использовании GPU. Тогда все летает (смотрите мой маленький тестик чуть повыше по ветке). На Dpreview - https://www.dpreview.com/forums/post/59411292 радуются уменьшению количества косяков и увеличения скорости при подключении GPU.

Конечно, сигмовцы они такие сигмовцы... да и подверждение тому, что кваттровый сенсор требует "тяжелой" математики. К сожалению, это штатная ситуация для слишком закрытых компаний, особенно при наличии слабых команд аналитиков и разработчиков софта, не умеющих эффективно оптимизировать код. К тому же, при отсутствия апгрейда внутрикамерного железа - процессоров, им приходится дополнительно переносить основные задачи по обработке равов на вычислительную мощность компьютеров пользователей. Такая-же тема была несколько лет назад и с DxO - они доказывали (при моих запросах к ним) - нам не нужен 64-битный релиз нашего софта и писали всякую чушь на эту тему, пока не появились равы с Nikon 800/800e. Тут они цинично забыли про то, что писали и сразу перевели весь софт на 64-битный код - все юзеры с 32-битными операционками пошли сразу лесом.

Хотя, с AMD уже такие пролеты были (и не только с сигмой), например известная проблема с виртуализацией и пр. Поэтому (не только) в нашей конторе корпоративной политикой запрещена и покупка и использование компов с AMD процессорами. Также обстоит дело и с маками, т.к. централизованная управляемость их в больших централизованных структурах (у нас, например, сейчас больше 3000 персональных компьютеров и больше сотни серверов)... ну крайне неудобна.

Придется вам апгрейдить персональный комп ((

Вопрос относительно памяти в настройках SPP остаётся... Лучше подключать дополнительную или нет?

Цитата:

от: vovash
Вопрос относительно памяти в настройках SPP остаётся... Лучше подключать дополнительную или нет?

Сначала попробуйте включить GPU.... Если прокатит - уже потом включаем дополнительную память (потребуется перезапуск SPP) и тестим. Так делал...

Если с GPU понятно, а то, что они подразумевают под дополнительной памятью - фиг его знает (повышают приоритет процессов и пр.?), т.к. и по-умолчанию 64-битный приклад и операционка 64-битная работает со всем объемом памяти компа, в отличие от 32-битной системы и приклада. Смотрел, как задействованы ядра проца при обработке - фигово они задействованы, нагрузка неравномерная, но это проблемы грамотности айтишников, а у Сигмы они.... ээээ... похоже, слабоваты.

Цитата:

от:srgs
Скорость как и в 6.5.1 при стандартном функционале. Подлатали косяки и разогнали обработку при использовании GPU. Тогда все летает (смотрите мой маленький тестик чуть повыше по ветке). На Dpreview - https://www.dpreview.com/forums/post/59411292 радуются уменьшению количества косяков и увеличения скорости при подключении GPU.

Подробнее

У меня дома в запасе есть энергоэффективная система на сокете АМ1 от амд опять же. :D Проц Athlon 5350 - свежак. Завтра там поставлю 6.5.2, попробую. Спасибо за мини тест!
Цитата:

от:srgs

Конечно, сигмовцы они такие сигмовцы... да и подверждение тому, что кваттровый сенсор требует "тяжелой" математики. К сожалению, это штатная ситуация для слишком закрытых компаний, особенно при наличии слабых команд аналитиков и разработчиков софта, не умеющих эффективно оптимизировать код. К тому же, при отсутствия апгрейда внутрикамерного железа - процессоров, им приходится дополнительно переносить основные задачи по обработке равов на вычислительную мощность компьютеров пользователей. Такая-же тема была несколько лет назад и с DxO - они доказывали (при моих запросах к ним) - нам не нужен 64-битный релиз нашего софта и писали всякую чушь на эту тему, пока не появились равы с Nikon 800/800e. Тут они цинично забыли про то, что писали и сразу перевели весь софт на 64-битный код - все юзеры с 32-битными операционками пошли сразу лесом.

Подробнее

Да, действуют по обстановке!
Но возвращаясь к скорости отрисовки эскизов в окне SPP. В ROSA linux 8.1 через wine 1.7 ставил SPP 5.5.3. Отрисовка эскизов в папке с 200+ x3f просто летает. Под вин 8.1/10 тупит страшно. Смешно, правда?
Цитата:

от:srgs

Хотя, с AMD уже такие пролеты были (и не только с сигмой), например известная проблема с виртуализацией и пр. Поэтому (не только) в нашей конторе корпоративной политикой запрещена и покупка и использование компов с AMD процессорами. Также обстоит дело и с маками, т.к. централизованная управляемость их в больших централизованных структурах (у нас, например, сейчас больше 3000 персональных компьютеров и больше сотни серверов)... ну крайне неудобна.

Придется вам апгрейдить персональный комп ((

Подробнее

Дома кругом амд :D
Комп апргрейдить не буду - всё шустро. Есть ещё один системник. Но удобства в работе поубавится. Файлы с кватры обрабатываем на одном компе, мерилл на другом))).
Хотя друзьям собирал последние 2 компа на интеле...

Что-то мне подсказывает, что отрисовка эскизов - это тупое извлечение джипегов из x3f c их уменьшением и последующим кешированием. Поэтому это не обработка, как таковая, X3F. Извлечение эскизов не годится для оценки скорости работы SPP.

Цитата:

от:srgs
Что-то мне подсказывает, что отрисовка эскизов - это тупое извлечение джипегов из x3f c их уменьшением и последующим кешированием. Поэтому это не обработка, как таковая, X3F. Извлечение эскизов не годится для оценки скорости работы SPP.

Подробнее

А это часть функционала программы, определяющая удобство использования.
Загрузил SPP, выбрал папку с фотографиями. Чем быстрее они скешировались, неважно каким способом, тем быстрее я выбрал фото для редактирования. Выбрал, сохранил в jpeg/tiff в той же папке. Закрыл окно редактирования и перешел к кэшированным эскизам - они начинают перерисовываться заново, ведь о чудо, в папке появился новый файл. Юзер ждёт.
Может записать видео, может у меня одного такие претензии, а у всех всё норм? :)

Цитата:

от:ZPeter
А это часть функционала программы, определяющая удобство использования.
Загрузил SPP, выбрал папку с фотографиями. Чем быстрее они скешировались, неважно каким способом, тем быстрее я выбрал фото для редактирования. Выбрал, сохранил в jpeg/tiff в той же папке. Закрыл окно редактирования и перешел к кэшированным эскизам - они начинают перерисовываться заново, ведь о чудо, в папке появился новый файл. Юзер ждёт.
Может записать видео, может у меня одного такие претензии, а у всех всё норм? :)

Подробнее

Так и есть... Скорее всего кеширование держится на сессию, потом кэш вычищается при ее закрытии и все по-новой. Это-же не проф. просмотрщик типа ACDSEE и пр., где эскизы держатся и индексируются в родной/отдельной базе и на постоянной основе. Иначе разработчикам SPP пришлось-бы подключать бесплатны движок баз данных - либо фоксовый, либо mysql, либо mssql express, а это им доп. гемор в разработке. Они и так не успевают полировать основной функционал.

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

Цитата:

от:bnxvs
Спасибо за ссылку. Ну что сказать - логика мне пока не отказала
[quot]In 2010, Foveon marketed a 15.4 million-pixel sensor. In 2014, another sensor of the same company, Quattro, made use of a slightly different scheme. The first photodiode layer, near the surface, is very dense (with a step of 4.35 μm), while the two deeper layers have a double step of 8.7 μm. The signal is reconstructed by taking advantage of the high resolution of the first layer, the same way as carried out in satellite imagery, by enriching the spectral channel of high resolution informations of the panchromatic channel. The Quattro offers twenty million pixels in the topmost layer and five in each of the two other layers. The reconstruction of 3 × 20 million pixels is done by image
processing, on the one hand to separate the chromatic components from quite saturated raw signals, on the other hand to resample the three channels with the same step.[/quot]

К сожалению остается неясным алгоритм этого самого "The reconstruction of 3 × 20 million pixels is done by image", как раз там самое интересное (RGB/LAB/Etc.). Но то, что верхний слой однозначно "L" канал это таки ДА ;)

p.s.

Имхо, вот здесь собака и порылась, на мой взгляд. Вы видели воочию эту саму тестовую сцену DPR? Я нет. Сказать куда и как должны штрихи ложиться можно только по многочисленным семплам с байеров - а кто сказал, что это на самом деле так?
Я довольно критично отношусь к этим ДПРевьюшным сценам. Проще самому сравнить, на чем-то очень знакомом и распространенном - к примеру рублевых купюрах. ;)

Подробнее

Это попытка использовать верхний слой в качестве L канала. Но, поскольку чувствительность верхнего слоя резко падает в красном и зеленом, получаем узнаваемые кватровские шумы в умеренных тенях. Второе, детализация в красном и зеленом за счет L-канала конечно вырастет, но не достигнет детализации самого L-канала.

Наверное, я не прав в своем излишнем доверии к SPP, в части использования синего как единственного канала для формирования ч/б представления. Проверю другим софтом.

Цитата:

от: Nicholaes
... поскольку чувствительность верхнего слоя резко падает в красном и зеленом, получаем узнаваемые кватровские шумы в умеренных тенях.

Имхо, все эти шумы есть плод "кривоватой математики". Как я понимаю, понятие "цветной светофильтр" не применимо к фотодиоду матрицы Фовеон в принципе. Посмотреть бы еще на его строение "в разрезе"... может стало бы чуть-чуть понятнее. Картинки с т.н. "цветными слоями" на мой взгляд имеют мало общего с реальной структурой матрицы - не более чем виртуальное схематичное представление.
Короче надо Сигме дуру не валять - отдать спеки в Open source сообщество. Имхо, опять же.

Цитата:

от:bnxvs
Имхо, все эти шумы есть плод "кривоватой математики". Как я понимаю, понятие "цветной светофильтр" не применимо к фотодиоду матрицы Фовеон в принципе. Посмотреть бы еще на его строение "в разрезе"... может стало бы чуть-чуть понятнее. Картинки с т.н. "цветными слоями" на мой взгляд имеют мало общего с реальной структурой матрицы - не более чем виртуальное схематичное представление.
Короче надо Сигме дуру не валять - отдать спеки в Open source сообщество. Имхо, опять же.

Подробнее

Разумеется, картинки со слоями - идеализированное представление. В реальности все гораздо хуже уже хотя бы потому, что где-то надо размещать проводники от пикселей. Но принцип-то описан точно: поглощение разных длин волн на разной глубине кремниевой пластины. И спектральные характеристики слоев фовеона публиковались еще во времена SD10. Они могли поменяться количественно, если меняли толщины слоев, но они не могли поменяться качественно. И этой качественной характеристики достаточно, чтобы говорить о сомнительной целесообразности попыток использования синего канала в качестве L.