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

Title	Comment
я в компиляторном коде ни	я в компиляторном коде ни разу dpps не видел Использовать DPPS всегда (на любой микроархитектуре) неоптимально.
pixel =	pixel = _mm_sub_ps(pixel,black); // вычли pixel = _mm_max_ps(pixel,zero); // в zero - 4 нуля, если после вычитания получилось отрицательное число, то станет 0 А так же эффективно сделать это же для 16-битного представления - компилятор не может, даже если цикл развернуть и фигачить по два пикселя. Ну, или я неправильными компиляторами пользуюсь. PSUBUSW (aka _mm_subs_epu16) сделает это в одну команду!
Если вы обратили внимание, то	Если вы обратили внимание, то зеленые каналы немножко разные (максимумы - отличаются). Глобально же - ну домножены у никонов B и R на небольшие константы. Можно даже прикинуть на какие. Ничего хорошего в этом нет, но глобально ничего не испорчено, при желании делится обратно.
Вообще, компилятору сложно распознавать более-менее сложные	Вообще, компилятору сложно распознавать более-менее сложные паттерны. Ну, к примеру, умножение вектора на матрицу. Или даже просто скалярное произведение векторов - я в компиляторном коде ни разу dpps не видел. Не говоря уже о более сложных паттернах.
Зачем бы RAW-конвертору	Зачем бы RAW-конвертору повторять процессинг dcraw?
По счастью, imaging - счастливое исключение, там данные сгру	По счастью, imaging - счастливое исключение, там данные сгруппированы естественным образом. Или почти естественным, каналов в RGB три, а компонентов в векторе - 4.
>> Ну то есть ручной SSE-код быстрее везде, где применимо SS	>> Ну то есть ручной SSE-код быстрее везде, где применимо SSE. Во, наверное, тут ключевая фраза. ПМСМ, сгруппировать данные под SSE для компилятора - задача архитрудная.
Ну ведь это же рав-конвертор	Ну ведь это же рав-конвертор будет с плавучкой и "правильным" выходным результатом, неиспоганенный профилями и шустро работающий(вместо тугого и неюзабельного RPP)?
Разный максимум по каналам	Разный максимум по каналам автоматически означает, что камера явяется мыльницей, потому что у неё отсуствует настоящий RAW. (одинаковые зелёные каналы означают, что это именно пародия на фотошоп, а не разные АЦП)
Можно еще пипетку иметь для	Можно еще пипетку иметь для закрашивания восстановленных участков, в идеале для каждой зоны (по желанию) отдельно. То же угадывание тона в РПП - вполне полезно.
Особо отвратительные места в LibRaw давно оптимизированы,	Особо отвратительные места в LibRaw давно оптимизированы, т.е. там особых каких-то потерь нет. Все размазано тонким слоем. Просто 16-битные данные не приспособлены к эффективной векторизации. Вот, к примеру, вычитание уровня черного при работе с плавучкой - это две SSE-команды на пиксель: pixel = _mm_sub_ps(pixel,black); // вычли pixel = _mm_max_ps(pixel,zero); // в zero - 4 нуля, если после вычитания получилось отрицательное число, то станет 0 А так же эффективно сделать это же для 16-битного представления - компилятор не может, даже если цикл развернуть и фигачить по два пикселя. Ну, или я неправильными компиляторами пользуюсь. Про матричное преобразование цвета я полтора года назад написал серию постов: http://blog.lexa.ru/2011/08/27/o_legacy_i_formatakh_dannykh.html http://blog.lexa.ru/2011/09/11/o_vektornom_umnozhenii_final.html http://blog.lexa.ru/2011/09/13/o_vektornom_umnozhenii_vtoroi_final.html Естественно, я ручками закодировал 6 SSE3-команд, но никакой компилятор так не сделает. Ну то есть ручной SSE-код быстрее везде, где применимо SSE. Медленными же остаются а) гистограмма (с которой ничего хорошего сделать нельзя и б) накладывание sRGB-кривой в виде curve[linear-data], с которой возможно и можно что-то сделать, но 75ms на 9 мегапикселей по мне - и так приличный результат. А, да, распаковка Lossless JPEG D800 занимает ~250ms и что с ней делать - непонятно, там все уперто в "битовый буфер". Т.е. понятно что делать глобально, но не с одним файлом.
Интереснее, где в реале получается бОльшая часть потерь в C-	Интереснее, где в реале получается бОльшая часть потерь в C-коде.
Скорее бы уж!	Как бальзам на душу, читать про такие оптимизации во время разработки софта. Не терпится уже узнать, что же за бомба такая выйдет для фотограферов вскорости. :)
В-принципе, DNG (обычные, не	В-принципе, DNG (обычные, не linear) - имеют те же данные внутри и, в теории, от XE1 должны жраться. Но я не пробовал, может быть там есть какие-то несовместимые с жизнью вещи. DNG Converter 7.3 вроде бы XE1 поддерживает.
Понятно. Печалька :( Шибко	Понятно. Печалька :( Шибко хотелось поглядеть чего у них там внутри RAW на самом деле, а то результаты тестов на dpreview (особенно по шуму) вызывают ощущение некоторого обалдения.
XE-1 не поддерживается. И в	XE-1 не поддерживается. И в следующей версии, вероятнее всего, тоже не будет поддерживаться (но не будет и падать). Что-то там с форматом наворотили, разобраться пока не могу.
проблема с открытием RAW с Fuji X-E1	RAW файлы с Fuji X-E1 взятые здесь http://www.dpreview.com/previews/fujifilm-x-e1/10 а именно: http://movies.dpreview.com.s3.amazonaws.com/fujifilm_xe1/DSCF4209.RAF.zip http://movies.dpreview.com.s3.amazonaws.com/fujifilm_xe1/DSCF4214.RAF.zip http://movies.dpreview.com.s3.amazonaws.com/fujifilm_xe1/DSCF4218.RAF.zip не открываются совсем :) При попытке открыть, минуты 4 жрем на 100% ресурсы одного core, а потом "давай до свидания". Все остальные RAW (Nicon, Canon, Pentax, Olympus, Leica) открываются без проблем. Ниже все что в логах остается (Винды 7 x64) Faulting application name: RawDigger.exe, version: 0.9.13.171, time stamp: 0x50a219b9 Faulting module name: librawf.dll, version: 0.0.0.0, time stamp: 0x50a2199a Exception code: 0xc0000005 Fault offset: 0x00000000000419e0 Faulting process id: 0xcbc Faulting application start time: 0x01cddb3d6b7a6c0f Faulting application path: C:\Program Files\LibRaw\RawDigger\RawDigger.exe Faulting module path: C:\Program Files\LibRaw\RawDigger\librawf.dll Report Id: 7b39546c-4731-11e2-bba0-506313c650a9
До 10.8 так и было. Даже если	До 10.8 так и было. Даже если ядро Mac OS работало в 32-х битном режиме, то 64-х битные программы можно было запускать как в 64-х битном режиме (по умолчанию), так и в 32-х битном. Для этого в свойствах 64-х битных программ была даже опция-переключатель на работу в 32-х битном режиме. Иногда Фотошоп приходилось переключать в 32-х битный режим из-за того, что не все сторонние плагины были 64-х битными. Так что ядро и программы могли работать каждое в своей битности. И системные кексты тоже были разные, некоторые могли работать в обоих режимах, некоторые только в 32-х битном. Например, драйвера для старых встроенных интеловских видеокарт, например, GMA3100, после 10.6.2 были только 32-х битные, поэтому систему лучше было запускать в 32-х битном режиме, хотя сам процессор (Core2Duo) был 64-х битный. Иначе видеокарта работала в VGA-совместимом режиме (не уверен что в данном случае этот режим называется именно так, но суть думаю понята). Ну, а в 10.8 систему сделали только 64-х битной, и кексты теперь тоже только 64-х битные. Хотя сами программы работают как 32-х битные, так и 64-х битные. Хотя когда смотришь Activity Monitor, то видишь насколько 32-х битных программ стало меньше по сравнению с временами 10.6 например. В 10.6 надпись Intel (64 bit) в колонке Kind программы была скорее исключением, а в 10.8 наоборот программа без приставки (64 bit) уже смотрится исключением.
Если ввести в гугл inpainting, то можно узнать что задача во	Если ввести в гугл inpainting, то можно узнать что задача восстановления изображения внутри области по данным на границах имеет относительно простые, и вместе с тем не пугающие глаз решения. Применить её к пересветам - другая задача. Можно попытаться восстановить цветовую информацию по значениям на границе, и дальше если есть значения хоть в одном канале, можно восстановить остальные два. Я писал о том, что нужно сначала восстановить пересвет (не важно, каким образом, да хоть бы везде где есть клиппинг хоть одного канала в белое) и лишь потом умножать на матрицу, а не наоборот.
Ну, это будет соответствовать поведению нашего зрения, котор	Ну, это будет соответствовать поведению нашего зрения, которое вполне себе обесцвечивает яркие света.
Скорость - вопрос второй, пока неинтересно обсуждать. Вопр	Скорость - вопрос второй, пока неинтересно обсуждать. Вопрос все одно в цвете. Вот придумался такой пример: оконная рама, расписанная под хохлому, а в ней - окно, полностью пересвеченное. Мы эту самую хохлому - экстраполируем дальше в окно? Вот в том примере, который в посте: справа от пересвета оконная рама или что-то подобное (желтое), снизу - зеленый листик, вот прямо вот зеленым и желтым все и зальем? По мне, так дефолтным поведением должно быть что-то ACR-о-подобное, если и восстанавливаем света, то нейтралью. Иначе уж совсем плохо.
Многокадровая работа (включая	Многокадровая работа (включая сюда и два кадра за раз, как в S5Pro) - это отдельная история, хотя и очень интересная. Но пока вопрос в том, что делать с одним кадром. И ничего лучшего, чем -- а) резать б) если восстанавливать - то обесцвеченное -- я пока не вижу. Экспериментировать надо, да.
Главная задача тут, видимо, избежать паразитной хроматики. М	Главная задача тут, видимо, избежать паразитной хроматики. Можно после шага 2 разложить картинку на яркость и хроматику, например, в YCbCr, это довольно быстро. Затем в пикселах, где хоть один канал ушел в пересвет, отказаться от собственных CbCr и взять их интерполяцией из соседних, оставить лишь собственную яркость. Затем вернуться обратно в RGB. Но это будет прямо медленно.
Тут 2 очевидных псевдонаучных	Тут 2 очевидных псевдонаучных варианта: 1. Посмотреть, как это "решают" различные вендоры (и выбрать то, что наиболее приемлемо для ...). 2. (и это уже БЫЛО!) Делать "предварительное экспонирование" - гарантированно без насыщения ни в одном из каналов - чтобы понять что делать с пересветами (даже во всех каналах (и это НЕ HDR!!!)). PS. Наплевать, если картинка "уехала" между экспозициями: "II" как-нибудь сопоставит.
Да, большинство камер не идут	Да, большинство камер не идут ни в какое сравнение с S5Pro :-(
Если вы уведете блики (и, тем	Если вы уведете блики (и, тем более, источники света в кадре) в воспроизводимую область (путем уменьшения экспозиции) - вы потеряете весь остальной снимок.
Артефакты - это то, чего не	Артефакты - это то, чего не было перед камерой. Они являются или браком, или творческим замыслом. P.S. К плёночному фетишизму это тоже относится.
Потеря информации до	Потеря информации до обработки не может быть браком обработки. Неправильное определение выдержки - это тоже не вина обработки.
Еще раз - увод канала в	Еще раз - увод канала в насыщение - это не артефакты, это особенность поведения цифрового сенсора (с резким насыщением). Блики - в большинстве случаев будут давать насыщение, контровик - во многих случаях. А дальше - возникает проблема правильной обработки этого дела. Ну то есть информация (частично) утеряна, можно дальше резать и ту, что еще не утеряна (ACR, Default), можно что-то придумывать на этом месте.
Вот и я так думаю.	Вот и я так думаю.

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

Pages