В плане установки дополнительных проводных выключателей в уже жилой квартире — вы когда-нибудь штробили бетонную стену? Даже если это делать хорошим штроборезом с подключенным пылесосом — мелкая противная пыль будет везде. Кроме того, чтобы восстановить нормальный вид стены штробу надо будет штукатурить, ждать высыхания несколько часов, потом шпаклевать, ждать еще несколько часов, потом шлифовать (еще пыль), грунтовать, опять ждать высыхания, и только потом клеить обои/красить/что там было до этого. И хорошо если место куда нужно тянуть провод находится в стене, до которой можно доштробиться (на самом деле часто нельзя), а если нет, и окажется что нужно еще вскрывать натяжной или еще хуже гипсокартнный потолок, чтобы добраться до распаячной коробки? Даже если все это окажется дешевле радиовыключателей — многие ли захотят терпеть такой дестрой у себя дома, причем несколько дней?
Альтернатива — Z-Wave устройства, если идти по «бюджетному» варианту, то какой-нибудь силовой модуль zipato будет стоить 3500, если брать fibaro — то от 6000. Может работать и как силовой блок, и как просто «пульт». Ставится обычно в подрозетник. Если надо накладной выключатель-пульт на батерейках чтобы не портить стены — ценник от 5000. Итого стоимость «комплекта силовой модуль + выключатель на скотче» 8500, ценник ноолайта на этом фоне очень даже гуманный.
Ваши слова "50мм на кропе не становится портретником, им по прежнему нельзя отделить лицо от фона?" я воспринял именно так. Если неправильно понял — извиняюсь.
Ну и по собственному опыту — 50мм на кропе на открытой диафрагме очень даже позволяют отделить объект съемки от фона. Более того, в процессе спора с одним знакомым на тему эквивалентности фокусных/грип и т.п. пробовали снимать с одного ракурса и расстояния один и тот же объект на кроп 1.5 при 50/2.0 и на полный кадр при 75/2.8 — фото были идентичны плюс-минус шумы и цветопередача разных матриц.
По вашему лицо от фона можно и нужно отделять только "размытием в хлам"? Ну-ну...
UPD. Ну и как бы портрет — это не только лица крупным планом на длинном фокусном.
Согласен, но опять же — после усредненения многомегапиксельная матрица будет скорее всего не хуже, а без усреднения даст больше свободы (да, при наличии прямых рук/хорошего света/оптики/...).
Есть мнение, что если взять и усреднить эти 100500 мегапикселей до 12 (при одинаковом размере и техпроцессе матриц), то по шумам результат будет эквивалентен съемке на те же 12 мегапикселей сразу. Зато при хороших условиях съемки 100500 мегапикселей могут дать профит в плане качества и/или возможности кропа.
Если кропить — то действительно можно и на фишай, только тогда резко уменьшается эффективный размер матрицы. Проще говоря — будет как на мыльницу. А геометрические искажения в первую очередь зависят не от размеров матрицы, не от фокусного расстояния объектива, а от расстояния до снимаемого объекта. Если точнее — от отношения расстояния до объекта к размеру самого объекта. Все остальное — вторично.
Как мне показалось — статья наоборот о том, что не надо, извините, задрачиваться на характеристики камеры, метаться между никоном и каноном, накупать тонну дорогущей оптики — а брать то, что по карману и идти снимать уже.
Нормальное шифрование решает эту проблему. Более того, в том же wifi от перехвата пакетов защищает только шифрование, а «закрыться шторкой» там тем более не поможет. Так что тут еще вопрос что более приватно.
Это уже вопрос разумности использования, шаблоны — это просто один из инструментов. В вашем примере с матрицами и большой функцией вероятно да, шаблоны могут привести к раздуванию кода. С другой стороны, в статье ссылку на которую я кинул приводятся примеры использования шаблонов для GPIO вместе с ассемблерными листингами того, что получается на выходе, и получается очень компактно.
Дико извиняюсь за предыдущий комментарий, забыл про тег source, а исправить это месиво не успел (
Если переменные-объекты, для которых не вызываются конструкторы объявлены как глобальные или статические внутри классов или функций, и вы работаете с тулчейном arm-none-eabi-gcc, то вполне возможно вы используете ld-скрипт и startup-код, который не поддерживает вызов конструкторов глобальных переменных. Если вкратце — компилятор кладет список адресов конструкторов в секции .preinit_array и .init_array, поэтому чтобы оно заработало нужно:
1) добавить в ld-скрипт соответствующие секции
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
for( func_t * f = &__init_array_begin; f != &__init_array_end; ++f )
(*f)();
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.
Если переменные-объекты, для которых не вызываются конструкторы объявлены как глобальные или статические внутри классов или функций, и вы работаете с тулчейном arm-none-eabi-gcc, то вполне возможно вы используете ld-скрипт и startup-код, который не поддерживает вызов конструкторов глобальных переменных. Если вкратце — компилятор кладет список адресов конструкторов в секции .preinit_array и .init_array, поэтому чтобы оно заработало нужно:
1) добавить в ld-скрипт соответствующие секции
.init_array: {
. = ALIGN(4); init_array_begin = .;
KEEP ((.init_array)) init_array_end = .;
} >rom
2) сделать доступными указатели на начало и конец секции в коде, например так:
typedef void (func_t)();
extern func_t init_array_begin;
extern func_t init_array_end;
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
for( func_t f = &init_array_begin; f != &__init_array_end; ++f )
(f)();
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.
Только мне показалось, что на фото Riva 128 на микросхеме кроме логотипа nVidia стоит еще и логотип ST Microelectronics, тех самых, которые сейчас клепают довольно популярные микроконтроллеры?
Ну и по собственному опыту — 50мм на кропе на открытой диафрагме очень даже позволяют отделить объект съемки от фона. Более того, в процессе спора с одним знакомым на тему эквивалентности фокусных/грип и т.п. пробовали снимать с одного ракурса и расстояния один и тот же объект на кроп 1.5 при 50/2.0 и на полный кадр при 75/2.8 — фото были идентичны плюс-минус шумы и цветопередача разных матриц.
UPD. Ну и как бы портрет — это не только лица крупным планом на длинном фокусном.
Если переменные-объекты, для которых не вызываются конструкторы объявлены как глобальные или статические внутри классов или функций, и вы работаете с тулчейном arm-none-eabi-gcc, то вполне возможно вы используете ld-скрипт и startup-код, который не поддерживает вызов конструкторов глобальных переменных. Если вкратце — компилятор кладет список адресов конструкторов в секции .preinit_array и .init_array, поэтому чтобы оно заработало нужно:
1) добавить в ld-скрипт соответствующие секции
2) сделать доступными указатели на начало и конец секции в коде, например так:
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.
1) добавить в ld-скрипт соответствующие секции
.init_array: {
. = ALIGN(4);
init_array_begin = .;
KEEP ((.init_array))
init_array_end = .;
} >rom
2) сделать доступными указатели на начало и конец секции в коде, например так:
typedef void (func_t)();
extern func_t init_array_begin;
extern func_t init_array_end;
3) в startup-коде (обычно это reset-handler) перед вызовом функции main но после обнуления секции .bss и загрузки секции .data добавить что-то вроде:
for( func_t f = &init_array_begin; f != &__init_array_end; ++f )
(f)();
Разумеется то же самое нужно сделать для секции .preinit_array, и если вы хотите, чтобы вызывались деструкторы, то и для .fini_array, только деструкторы вызывать после main. Это если вкратце. А если подробно, то вдумчиво читать документацию про то, как пишутся ld-скрипты, и изучать примеры, например в libopencm3 вся эта инициализация есть, исходники можно на гитхабе посмотреть.