DOFCalc v0.1

Как и обещал, публикую первую свою программу для мобильников, написанную на Qt+QML.

Конечно, я никому не могу посоветовать ставить .apk (да вам и не даст, пока сами не включите "ставить из недоверенных источников"), собирайте сами, если надо :)

На самом то деле, я собирался (и собираюсь, ну то есть сделаю) сделать DOF-калькулятор для Tilt-Shift оптики, причем именно в том виде, в котором оно мне близко. Напечатанные таблицы

  • Постоянно гнутся, мнутся и теряются.
  • Если честно - то не очень удобны, поскольку всякий раз приходится думать лишнего.
  • Не позволяют ввести четвертое измерение (высота штатива над землей), от того думать приходится еще больше.
  • В-общем, мне кажется, что мне понятно, как будет удобно мне - осталось сделать и попробовать.

Но прежде чем браться за более сложную штуку, начал с более простой и более очевидной и сделал ее так, как мне нравится

  • "приборный" интерфейс, три ручки, три индикатора.
  • Никаких ненужных мне пищалок и свистелок, в частности кружок нерезкости задается (тупо) в микронах (умолчание - 25, как у нынешнего цейсса на FF), а из каких соображений (формат кадра, формат печати, итп) вы эти микроны задаете - ваше дело.

В процессе выяснилось всякое странное, например то, что есть несколько шкал диафрагмы с шагом 1/3 и 1/4 (для 1/2 вроде бы нет разночтений) и ни одна из этих шкал не подходит под теорию "логарифмически равномерный шаг + округление". Посмотрев на это - сделал как у Секоника (и, таки да, эти шкалы заданы таблицей в программе).

В том же процессе выяснилось, что я хочу в таком же примерно интерфейсе калькулятор для focus stacking. Ну, скую.  Наверное до T-S-калькулятора, потому что focus stacking интерфейсно кажется проще.

А в сумме - мне понравилось. Законченное приложение - меньше 600 строк кода до добавления копирайтов (правда я прилагал дополнительные усилия к компактификации) и тем не менее - уже полезно.

Comments

Жесть как непривычно видеть не-Java\Kotlin код под андроид :)

А зато оно собирается и работает
- под виндой (и я попробовал на Surface - т.е. с тачскрином - все ок)
- под андроидом
- должно и на маке/ios, но я не пробовал: мак у меня без тачскрина (т.е. интерфейс не зайдет), а i-devices нету

Несколько огорчает отсутствие #ifdef в QML-коде, но наверное как-то решается тоже.

Т.е. вообще нет ни одного слова про андроид в коде (есть про винду - потому что я быстро не придумал как правильно выбор размера шрифта стартовый делать и для full-screen и для окошка)

Но, понятно, тащит за собой большой рантайм, десятки мегабайт.

Ну да: QML is not compiled but interpreted at run time, so preprocessor directives can't be used directly by QML.

А жаль

http://glubina_rezkosti_obektiva_tilt_shift_24mm/

какая-то неочевидная ссылка под словами "оно мне близко"

Спасибо, исправлено.

Где-то рука дрогнула когда писал (и эту ссылку не прокликал)

> На самом то деле, я собирался (и собираюсь, ну то есть сделаю) сделать DOF-калькулятор для Tilt-Shift оптики, причем именно в том виде, в котором оно мне близко.

А это вот очень здорово - буду в очереди первый :)

Пока из мобильных приложений нашел и использую вот http://www.lumariver.com/#LumariverDOF но там подход к TS немного своеобразный (хотя к нему можно привыкнуть)

Ну вот я вижу так пока (с удовольствием обсужу до того как делать)
1) Мы, типа, пейзажные фотографы, т.е. плоскость резкости нам надо "в плоскости пейзажа", от ног и до бесконечности. (Возможно) под каким-то углом от ног вверх. Вот по этому скетчу: https://blog.lexa.ru/sites/blog.lexa.ru/files/images/sketch1.png

2) Эти углы мы можем даже измерить (дальномером/инклинометром), ну или оценить на глаз. Без этой оценки - задача не решается, IMHO, потому что не знаем чего хотим.

3) Подвижек оптики у нас две, тильт (вниз) и шифт (вниз-вверх). Шифт влияет, понятно, на углы поля зрения.

4) Еще есть высота установки штатива и угол наклона задней стенки камеры.

5) Еще есть фокусное расстояние (на самом деле из списка - и пока я планирую делать "под Кэнон", но наверное как-то можно будет сделать расширяемое), апертура и дистанция фокусировки.

Это *уже* дает 7 переменных (6, если мы зафиксировали оптику), что как-то несколько дофига, но и урезать ничего не хочется.

Может быть вообще надо танцевать от обратной задачи: вот есть две крайние точки на пейзаже (ближний план на земле, высокое дерево на расстоянии L и видимое под вертикальным углом альфа) - и значит решите нам задачу.
Не пойму пока, надо делать и пробовать вживую.

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

Да примерно так все. Углы "от ног до высокого дерева" измерять можно и телефоном наверно - если датчик есть (правда не сильно аккуратно но все же).

Люмариверское я купил - другого просто нет нигде, но с тилтом пока не опробовал (жду объектив из сервиса).

Для вертикальных углов можно взять банальный горный компас. Для горизонтальных - тем более.

Я, правда, купил лазерный дальномер с инклинометром (для стрельбы из лука),в принципе хорошая штука, но на ярком свету там скорее 200м максимальный диапазон, а не заявленные 1000.

Что-то типа Nikon Forestry Pro?

Люмариверский апп к примеру что то там с телефонным датчиком наклона делает, но насколько точно я не проверял пока.

Bushnell Scout 1000 Arc, вот нашел его и опробовал, на весеннем московском освещении 500м уверенно, летом будет меньше.

Посмотрел на современные цены - заколдобился, я покупал меньше чем за 200, правда 10 лет назад.

Стандартный датчик имеет точность 3600 долей от окружности. Вот и считайте.
Не думаю, что за несколько лет их разрешение улучшили. По крайней мере для тех, что "в смартфонах".

Ну и - разве надо больше чем 0.1 градуса?

... но стрелять из лука на 1000м..!
или я неверно понял?

Тилт/шифт объективы, они же про параллельность параллельных прежде всего.
Наклонная плоскость фокусировки, это из древнего БФ - "какбы" другая задача.

Про шифт вместо наклона - это шифт. А наклонная плоскость фокусировки - тилт.

"...тильт (вниз) и шифт (вниз-вверх)..." ;-)

Я даже подозреваю, что поставив камеру вертикально мы получим "тильт (влево) и шифт (влево-вправо)". :-)

Можно даже камеру оставить в покое, а соотв. место у объектива развернуть.

Во вчерашнем посте я имел ввиду, что уже давно основное предназначение тильт/шифт оптики - архитектура (параллельность стен зданий и пр. ) А резкость от собственных пяток до восходящей Луны - скорее бонус.

У БФ аж две тильт/шифт плоскости. И этим пользовались ещё до Революции. (ссылку на байку про восхищение австрийской царственной особы русским фотографом найти не могу).

В каком смысле "уже давно"?

Вот Кэнон, похоже, не в курсе и их свежие тильт-шифты еще и макро...

Что за бред - архитектура это только одно из приложений. Да Вам любая книжка по БФ (поскольку Вы на книжки любите ссылаться ну скажем вот такая https://www.amazon.com/gp/product/1138295531) даст кучу примеров использования подвижек для контроля перспективы (как для исправления искажений так и для внесения оных) и/или поля резкости.

Я очень давно не снимал, но сразу вспомнил проблему. Как я вижу. Тут есть не просто плоскость резкости, а этакий клин, с "высотой", зависящей от диаметра кружка нерезкости (что понятно). Мне кажется, что нужно считать не по центру, не по макс. резкости, а по нижней плоскости клина. На земле могут лежать камни и проч. объекты, имеющие какую-то высоту, и они запросто не попадают в резкость. Это сильно заметно, если снимать понорамной техникой, или по макс. экономить дырку.

Ну конечно клин.

И мы можем хотеть положить его на землю как серединой, так и нижней поверхностью (так и пустить под углом)

, но то, что в этой утилите именно кружок нерезкости выставляется произвольно - огромный плюс!
В зависимости от своих сиюминутных потребностей его можно задать почти от 0 до почти бесконечности (в пределах матрицы).
Если понимаешь, зачем ты выбрал именно это конкретное значение, утилита - супер.
Если в ТЗ и экспу выбранный КН не вписывается, с её помощью нетрудно оценить степень потерь по каждому параметру.
ВЕЩЬ! ... ну почти.

1. Открываем тебю, 3 пункта всё ОК.
2. Заходим в сеттингс, ОК.
3. Открываем тебю, по пункту сеттингс идёт полоса в 1 пиксель.
4. Переворачиваем в альбом, полоса исчезает, переворачиваем в портрет полоса появляется.
5. Заходим в Эбаут, полоса пропадает.
Опять проявляется при следующем входе в сеттингс.

Тёмная иконка на тёмном фоне, тяжела к восприятию....

Из хотелок:

При дистанциях до 1м, предел в см а не в м.

Вы гляньте в исходники, в отрисовке меню (да и вообще в отрисовке) я не властен. "ну вот такая она".

Переходить автоматом в сантиметры (миллиметры, микроны, километры, световые годы) - в принципе, разумная идея, при случае.

Вот чтобы не быть голословным, ну вот весь верхний тулбар

ToolBar{
    Rectangle{ anchors.fill: parent; color: "#404040"}
    RowLayout {
        anchors.fill: parent
        WhiteText { text: " DOFCalc"; font.pixelSize: tbar.height*0.5; color: "#a0a0a0";  horizontalAlignment: Text.AlignLeft;  Layout.fillWidth: true}
        ToolButton {text: qsTr(":"); onClicked: appmenu.open(); font.pixelSize: tbar.height*0.5;
            Menu { id: appmenu
                MenuItem { text: "About"; onTriggered: aboutDialog.open();}
                MenuItem { text: "Settings"; onTriggered: settingsDialog.open();}
                MenuItem { text: "Quit"; onTriggered: root.close();}
            }
        }
    }
}


Тут, как понимаете, нет никакой "полосы" и средств ее убрать - тоже нет.

Иконку слепим, я лепил за 10 секунд, что было...

Обычные объективы раньше рассчитывались на дистанции от 50 (?) фокусных и дальше. Шкалы ГРИП, в том числе.
В макро всё стрёмнее.
Если хочется точных формул, рекомендую "антикварную" книжку:
http://soul-foto.ru/knigi_po_fotografii/%D0%AD%D1%80%D0%BB%20%D0%9C%D0%B...
страница 78.

Владельцу этого блога стоит просмотреть и стр. 72. (там речь именно о его хотелках).
Вообще вся Глава 5 именно обо всё об этом.

А можно я буду читать Мерклингера, а не Митчелла?

Нужно - он точно лучше на практике :)

Даже у современного крутого Цейса кружок нерезкости всего лишь 0.025мм?!
У обсираемого всеми Кэнона (старый стандарт) 0.033 или 0.035.

"Из каких соображений задаёте" - это правильный ход!
Забодали уже всяко-разно калькуляторы со странными критериями :
- в одних "старые" 0.03;
- в других "размер пиксела";
- в третьих вообще не пойми что.
И ведь часто это даже не декларируется явно! - в мануалах ковыряться нужно - сколько оно в конкретной проге.

А забавнее всего, что ещё в 1999 году, ЕМНИП, вышла программная (и широко цитировавшаяся (в узких кругах) ) статья о том, что существующий критерий надо уменьшить раз в 7.

Так что возможность явно задать этот параметр, это здорово!

Кружок нерезкости задается же не исходя из "крутости" объектива, а исходя из размера печати/дистанции просмотра.