Автоматическая идентификация удачных изображений для пейзажной фотографии

Недавно я сделал пробный запуск проекта, чтобы сфотографировать определенную область скалолазания с разных направлений. Я сделал несколько снимков в разное время дня с одного и того же места, попробовал разные экспозиции и сделал 16 снимков с настройками, которые показались мне лучшими. Лучший кадр из лучшей сессии был этот(миниатюра ниже). Первоначально я думал, что попробую сложить изображения, но результат сложения 16 снимков выглядел хуже (меньше деталей), чем лучший отдельный снимок. Атмосферная турбулентность была хорошо видна через линзу, когда жаркое послеполуденное солнце падало на западную сторону скалы. Хотя я сделал несколько снимков утром с непрямым освещением, на них было меньше деталей из-за отсутствия теней и контраста, а также более низкого уровня освещенности. У меня нет места, откуда я мог бы получить правильный ракурс на свой объект с близкого расстояния, поэтому все мои изображения должны быть сняты с объективом 135 мм или 300 мм издалека.

Рок Такитц

Есть ли способ автоматизировать процесс поиска удачных изображений из набора таких пейзажных фотографий? Поскольку люди, делающие удачные снимки с астрономической фотографией, иногда делают сотни снимков, я предполагаю, что они каким-то образом автоматизируют это, но я не знаю, подходят ли алгоритмы, которые они используют, для пейзажной фотографии. Этот проект будет включать в себя много поездок и пеших прогулок, поэтому я был бы рад сделать сотни снимков подряд, если это может быть полезно. Я ищу решение с открытым исходным кодом, которое работает в Linux, желательно что-то, что я могу сделать из командной строки.

Или я, вероятно, получу лучшие результаты, используя видеотехнику? Впечатляющие результаты описаны здесь . Но вроде как для этого нужно уметь снимать около 10 кадров в секунду, а я так и не понял, сможет ли это сделать моя камера. (У меня Fuji x-e1.)

[РЕДАКТИРОВАТЬ] Немного покопавшись в Интернете, я думаю, что у меня есть некоторые частичные ответы на мой собственный вопрос. (1) Астрономы-любители, использующие удачные изображения, похоже, используют Windows и распространяют условно-бесплатное программное обеспечение Windows. (2) УВЕРЕН, что все астрономические методы включают в себя выбор «опорной звезды», которая считается точечным источником. Если у вас есть эталонная звезда, то довольно просто получить меру качества изображения. Распространенным является коэффициент Штреля, который представляет собой пиковую интенсивность изображения вашей эталонной звезды. Так что если эти впечатления верны, то мне может быть имеет смысл попробовать накатить собственный алгоритм выбора изображений для пейзажей.

Возможно, вам потребуется точно определить, что вы подразумеваете под словом «повезло»… Это довольно расплывчатый термин, который не имеет непосредственного отношения к каким-либо техническим характеристикам изображения… Я подозреваю, что то, что вы представляете, будет очень субъективным.
@twalberg: Я имею в виду такие вещи: en.wikipedia.org/wiki/Lucky_imaging Насколько я знаю, «удачное изображение» — это стандартный термин. Я предполагаю, что алгоритмы, используемые для выбора удачных изображений из больших наборов, действительно воплощают некоторое относительно четко определенное понятие «удачливости», но я не знаю, что это за понятие и подходит ли оно для пейзажей так же, как и для астрономии. Это по существу мой вопрос.
Ах... Я не был знаком с этим термином, так как никогда еще не погружался в пруд астрофотографии... Однако после прочтения первое, что приходит на ум, это некоторые инструменты, которые ImageMagick включает в себя для сравнения изображения - вы можете сравнить каждую пару изображений и, используя какую-то метрику (RMS или что-то подобное), сгруппировать изображения, чтобы вы могли выбрать пакет, который является «наиболее похожим» по этой метрике... Не очень автоматизировано с полки , но не должно быть слишком сложно сделать клей для оболочки или питона, чтобы собрать его вместе...
То, что я субъективно делал со своими изображениями, заключалось в том, чтобы выбрать определенную особенность скалы, которая имела резко очерченную, очень контрастную особенность, и я просто увеличивал каждое изображение и искал, какие из них показывали это изображение наиболее четко. Когда я проверил другие части изображения, мне показалось, что они непротиворечивы.
@twalberg: вы можете сравнить каждую пару изображений и, используя какую-то метрику (RMS или что-то подобное), сгруппировать изображения, чтобы вы могли выбрать партию, которая «наиболее похожа» по этой метрике Да, эта мысль пришла мне в голову, но тогда я думаю, вы могли бы обнаружить, что худшие изображения были похожи на самые худшие. Другая возможность может заключаться в том, чтобы взять БПФ и найти спектр мощности с большим количеством высоких частот, или, может быть, просто взять среднеквадратичное значение дискретного лапласиана. Но я уверен, что я не первый, кто задумался об этом, и я бы предпочел не изобретать велосипед.
Техника видео, на которую вы ссылаетесь, будет работать так же хорошо с фотографиями. Единственное отличие состоит в том, что время вычисления регистрации каждой фотографии, вероятно, будет квадратично больше, чем время вычисления регистрации каждого видеокадра (просто в силу того, что фотографии имеют гораздо более высокое разрешение, чем видео). Но техника все та же. Я не вижу необходимости снимать > 10 кадров в секунду.
Возможно, вам лучше снимать с более низкой частотой кадров. Это позволит вам иметь больше разнообразия в атмосферных условиях в течение более длительного периода времени для того же количества кадров.
@MichaelClark: 10 кадров в секунду — это не то, с какой скоростью я снимаю на самом деле. Это то, как быстро, я думаю, вам, вероятно, придется снимать, чтобы использовать видеотехнику, описанную в ссылке. Если я правильно понимаю, этот метод использует корреляцию от одного кадра к другому.
@BenCrowell Мой комментарий был ответом на комментарий Скоттбба.
Изображение, на которое вы ссылаетесь в викимедиа, выглядит не так уж плохо. Вы снимали в raw или jpeg? Кроме того, какие именно объективы вы используете?
@MikeDixon: Спасибо :-) Я сделал это в формате JPG с катадиоптрическим объективом 300 мм f/7 с расстояния 4,8 км. Единственной цифровой постобработкой была обрезка и небольшое повышение контрастности.
Я думаю, что если бы это было снято в необработанном виде и обработано лучше, вы могли бы добиться лучшего результата. Кроме того, съемка с лучшим объективом немного поможет. Как я уже говорил ранее, изображение не ужасное, но, вероятно, ему не помешало бы немного убрать дымку, сделать его четче и повысить резкость. Даже в jpeg я смог сделать его намного лучше.
Техника видео в связанной статье использует изображения, снятые с разрешением значительно меньше, чем VGA, по сравнению с разрешением 12 мегапикселей связанного кадра. Основываясь на цветовом артефакте в примере с одним цветом, он может лучше подходить для монохромного видео, чем для цветного.
@BenCrowell Я не думаю, что этот метод использует синхронизацию или корреляцию между кадрами. Даже если бы это было так, я абсолютно уверен, что эту технику можно было бы адаптировать к регистрации медианного фильтра, чтобы учесть в основном произвольную межкадровую синхронизацию (в пределах изменений контента из-за освещения под углом солнца и т. Д.). Причина, по которой я в этом уверен, заключается в том, что я написал код, который делает что-то очень похожее на связанный подход. Межкадровая синхронизация не была ограничением (источником было видео, которое имело неявное значение Δt, но оно вообще не учитывалось при расчетах).
@MichaelClark Безусловно , съемка с высокой частотой кадров имеет определенную ценность, но я не считаю, что это абсолютно необходимо. Это больше похоже на ситуацию «больше информации — это хорошо». Но со стохастической точки зрения вы можете быть правы: более длительный интервал выборки, вероятно, сгладит атмосферные колебания.

Ответы (3)

Это не окончательный ответ на мой собственный вопрос, но он слишком длинный для комментария.

Я реализовал идею использования лапласиана RMS. Идея состоит в том, что если яркость изображения представлена ​​массивом пикселей a[i,j], то в любой точке (i,j) мы имеем дискретное приближение к лапласиану L=a[i-1, j]+a[i+1,j]+a[i,j-1]+a[i,j+1]-4a[i,j]. Это измеряет резкость особенностей изображения. Например, если бы изображение было не в фокусе, значение L было бы ниже. Среднеквадратичное значение лапласиана, R, представляет собой квадратный корень из среднего значения квадрата лапласиана.

Вот мой код, который вычисляет R для входного изображения PNG:

#!/usr/bin/ruby

# To batch convert a bunch of JPGs to png:
# perl -e '$i=0; foreach $f(<*.JPG>) {$s=sprintf("%03d",$i); $c="convert $f $s.png"; print "$c\n"; system($c); $i=$i+1;}'

require 'oily_png'

# require 'hsluv'
  # http://www.hsluv.org
  # https://github.com/hsluv/hsluv-ruby
  # sudo gem install hsluv

# Sloppy and probably not physiologically valid, but fast.
# Returns an integer from 0 to 255*3.
def color_to_brightness(c)
  return ChunkyPNG::Color::r(c)+ChunkyPNG::Color::g(c)+ChunkyPNG::Color::b(c)
end


def rms_laplacian_from_file(input_file)
  image = ChunkyPNG::Image.from_file(input_file)
  n = 0
  sum = 0
  sum_sq = 0
  w = image.width
  h = image.height
  1.upto(w-2) { |i|
    ### if i%1000==0 then print "i=#{i}\n" end # show progress
    next unless i>w/3 && i<(2*w)/3 ## for efficiency, only use center of frame
    1.upto(h-2) { |j|
      next unless j>h/3 && j<(2*h)/3 ## for efficiency, only use center of frame
      next unless rand(10)==0 # for efficiency
      a = Hash.new
      (-1).upto(1) { |k|
        (-1).upto(1) { |l|
          c = image[i+k,j+l] # color, represented as a 4-byte rgba value
          a[[k,l]] = color_to_brightness(c)
        }
      }
      laplacian = a[[1,0]]+a[[-1,0]]+a[[0,1]]+a[[0,-1]]-4*a[[0,0]]
      n = n+1
      sum = sum + laplacian
      sum_sq = sum_sq + laplacian*laplacian
    }
  }
  sum = sum.to_f/n
  sum_sq = sum_sq.to_f/n
  rms = Math::sqrt(sum_sq-sum*sum)
  return rms
end

ARGV.each { |input_file|
  rms = rms_laplacian_from_file(input_file)
  print "#{input_file} -- rms=#{rms}\n"
}

Это реализовано на Ruby и работает в Linux с использованием библиотеки oily_png с открытым исходным кодом. Если кто-то заинтересован в том, чтобы попробовать его, он почти не требует модификации для работы на других платформах, если у вас установлены Ruby и oily_png.

Чтобы проверить, что он измеряет резкость, я взял первое изображение из моего набора из 16, измерил R, а затем добавил 5-пиксельное размытие по Гауссу с помощью GIMP и повторно измерил R. Результат был R = 30,8 до размытия, а R =7,8 после. Так что это, похоже, подтверждает, что он измеряет резкость.

Мои 16 изображений пронумерованы от 000 до 015. Глядя на изображения на глаз, я ранее выбрал изображение 003 как лучшее. Это было изображение, на которое я разместил ссылку в вопросе.

Я запустил свой код на 16 сделанных мной снимках и получил следующий результат:

000.png -- rms=30.809465960392004
001.png -- rms=31.215359700578606
002.png -- rms=31.909926250066476
003.png -- rms=31.83243374839454
004.png -- rms=31.310612756003305
005.png -- rms=30.353258897447564
006.png -- rms=30.61244684985801
007.png -- rms=30.882745734215135
008.png -- rms=28.667104210689384
009.png -- rms=29.862966602367973
010.png -- rms=29.72001987743495
011.png -- rms=30.51274847773823
012.png -- rms=30.84316910530572
013.png -- rms=29.21751498027252
014.png -- rms=29.067434969521976
015.png -- rms=30.831305018709617

Из 16 изображений у моего выбора было второе по величине значение R. Казалось бы, это подтверждает, что эта статистика может быть полезной в качестве альтернативы просмотру изображений и субъективной оценке их на глаз.

Моя реализация довольно медленная, и чтобы компенсировать это, я сделал некоторые вещи, чтобы улучшить ее производительность. Я проверяю только середину поля и отбираю лапласиан только в 1/10 точек. В более оптимизированной реализации эти ярлыки при желании можно было бы исключить.

Позже мне пришло в голову, что может быть гораздо более простой способ сделать это. Изображение с большей детализацией также не должно сжиматься, поэтому самый большой файл JPG может быть просто лучшим. Конечно же, выполнение ls -lS для перечисления файлов в порядке уменьшения размера дало список, который был почти в том же порядке, что и файлы, отсортированные по уменьшению R:

-rw-rw-r-- 1 bcrowell bcrowell 16970354 Oct 25 15:48 003.png
-rw-rw-r-- 1 bcrowell bcrowell 16927174 Oct 25 15:48 002.png
-rw-rw-r-- 1 bcrowell bcrowell 16903104 Oct 25 15:48 004.png
-rw-rw-r-- 1 bcrowell bcrowell 16882373 Oct 25 15:47 000.png
-rw-rw-r-- 1 bcrowell bcrowell 16861082 Oct 25 15:47 001.png
-rw-rw-r-- 1 bcrowell bcrowell 16817527 Oct 25 15:48 006.png
-rw-rw-r-- 1 bcrowell bcrowell 16816529 Oct 25 15:49 011.png
-rw-rw-r-- 1 bcrowell bcrowell 16793982 Oct 25 15:49 012.png
-rw-rw-r-- 1 bcrowell bcrowell 16786443 Oct 25 15:48 009.png
-rw-rw-r-- 1 bcrowell bcrowell 16773575 Oct 25 15:48 005.png
-rw-rw-r-- 1 bcrowell bcrowell 16771759 Oct 25 15:49 010.png
-rw-rw-r-- 1 bcrowell bcrowell 16765674 Oct 25 15:48 007.png
-rw-rw-r-- 1 bcrowell bcrowell 16764562 Oct 25 15:49 015.png
-rw-rw-r-- 1 bcrowell bcrowell 16750179 Oct 25 15:48 008.png
-rw-rw-r-- 1 bcrowell bcrowell 16732854 Oct 25 15:49 013.png
-rw-rw-r-- 1 bcrowell bcrowell 16684073 Oct 25 15:49 014.png
Хорошо сделано. Что я нахожу интересным и согласующимся с общепринятой неколичественной практикой, так это то, что изображения с первого снимка являются лучшими изображениями (по критериям). Может быть, это была просто удача. Может быть, это было просто обычное фотографическое суждение о том, когда закрыть затвор. График может помочь.
С точки зрения сжатия, большее количество случайного шума приведет к увеличению размера файлов, и этот шум может быть в одном или нескольких цветовых каналах вместо или в дополнение к каналу яркости, над которым работает алгоритм. При низких значениях ISO с хорошо освещенными объектами это вряд ли будет проблемой ... хотя выбор подходящих объектов при применении размера файла в качестве показателя резкости, возможно, является вопросом фотографического суждения.

Есть ли способ автоматизировать процесс поиска удачных изображений из набора таких пейзажных фотографий?

Насколько я понимаю, ваше определение «счастливого изображения» — это изображение, которое четче среднего. Поскольку многие камеры используют измерение резкости (области) изображения в своих механизмах автофокусировки 1 , ясно, что есть способ автоматизировать его измерение. Однако преимущества разных подходов и возможности их комбинирования являются предметом активных исследований, поэтому однозначного ответа ждать не приходится. Например , надежный алгоритм автоматической фокусировки для низкоконтрастных изображений с использованием новой меры контрастности , Jinshan Tang et. al., Sensors (2011) говорит, что

Многие меры контраста использовались для пассивной AF ... Результаты показывают, что методы 2D пространственных измерений, такие как Tenengrad, обнаружение Prewitt Edge и лапласиан, дают наилучшие результаты с точки зрения точности и одномодальности. Однако они очень чувствительны к шуму и неустойчивы к различным условиям сцены, таким как условия низкой освещенности.

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

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


1 Точнее, те, которые используют автофокусировку с определением контраста, а не автофокусировку с определением фазы. И да, я знаю, что зеркалки с просмотром в реальном времени используют PDAF с зеркалом вниз и CDAF в режиме просмотра в реальном времени.

Это, вероятно, слишком далеко, чтобы представлять большой интерес, но: лапласиан в одном измерении увеличивает содержание высоких частот, умножая спектр Фурье на квадрат частоты. (Надеюсь, я правильно понял.) Таким образом, он усиливает и шум, и сигнал. Было бы интересно посмотреть, сможет ли детектор краев выделить интересующие особенности. Учитывая конкретный детектор краев, возможно, будет интересна фотография с наибольшей общей длиной края. Это может быть просто погоня за хвостом, а может и нет?