Очень часто вложенные условия как бы уточняют друг друга и выполняют промежуточные действия:
if (data != NULL) {
response = request(data)
if (response.succeeded) {
result = process(response)
if (result.valid) {
store(result)
и т.д. и т.п.
}
}
}
Такие проверки нельзя вычислить заранее и записать в одном условии, они плохо выглядят лесенкой, но зато элементарно и наглядно записываются с использованием раннего выхода.
Как говорится, плохая аналогия подобна котенку с дверцей.
Обычная инженерная сантехника как раз унифицирована донельзя и, что самое главное, совершенно одинаковая в каждом магазине, которых по несколько штук в каждом районе.
А вот если кто-то решит собрать сантехнику в самой обычной квартире из деталей, которые в ближайших магазинах не найти и надо заказывать из-за рубежа -- это точно так же будет крайне сомнительная затея, когда в случае внезапного фиаско может действительно потребоваться некоторое время условно говоря ходить на улицу.
А компьютер, это-ж куча комплектующих которые выходят из строя и их нужно заказывать?
Во-первых, с чего это вы вдруг взяли что надо заказывать в такой же мере, как в случае с контроллерами с aliexpress? Комплектующие обычных ПК в широчайшем ассортименте доступны в целом ряде магазинов рядом с домом практически 24/7.
Во-вторых, выход из строя ПК и выход из строя системы хранения данных это все-таки разные вещи. При наличии бекапа, ПК в крайнем случае можно просто выкинуть в окно целиком и купить другой. В случае с ноутбуками/неттопами многие так и поступают. Новый NAS на 26 дисков со всеми данными за последние пятнадцать лет в DNS у дома уже не купишь.
Не ну сами то прислушайтесь, разговор не о чем, если вас пугает аппаратный raid, и у вас нет опыта им пользоваться, то не пользуйтесь.
Кто сказал, что меня он пугает?
Просто в бытовых условиях аппаратный RAID это лишняя точка отказа с потенциально катастрофическими последствиями. Зачем?
Если бы вы привели аргументы мол потому что вам нужно особое шифрование, что иначе не достичь нужной производительности или нужны особые порты и поддержка особых дисков и т. п. -- то было бы понятно.
Но пока складывается впечатление, что во всех самосборных NAS аппаратный RAID (а также всякие другие более-менее редкие или специфичные комплектующие) используется просто потому что ой да какая разница, потом разберусь если что.
Ну тут понятно конечно, что в итоге каждый собирает как ему кажется правильнее.
Что у меня вызывает некоторое недопонимание -- это уверенность людей что их текущая ситуация с комплектующими, знаниями, количеством свободного времени и т. п. никогда не поменяется.
В моменте кажется что все просто и понятно, деталей -- весь aliexpress, что может пойти не так? Все может и пойдет не так =). Когда хранилище после рестарта в полном объеме обратно не поднимется, внезапно окажется что плат расширения уже не так навалом, ближайший аналог надо ждать несколько недель с aliexpress и потом разбираться почему он работает не совсем так же.
Даже если это все воспринимается как увлекательнейшее хобби, домашние пет-проекты типа локальной сети или даже сложной электросети, автоматики, систем хранения данных имеют тенденцию эксплуатироваться долго и играть существенную роль в быту. Сейчас вы готовы потратить целую кучу времени чтобы с помощью R-Studio восстановить массив. А через несколько лет, да будучи по уши в важной работе?
Поэтому мой посыл -- подобные системы по-хорошему надо проектировать исходя в первую очередь из соображений обслуживания и ремонта.
Все остальное тоже легко найти в течении дня
Давайте будем честными, это немного шапкозакидательство. Найти в течении дня можно разве что только в интернете, до момента пока комплектующие окажутся на столе может пройти черти сколько времени.
Мне нужен raid, я знаю как бекапить с перекрытием и т.д. <...> Ну а если вам это не нужно, замените raid на плату расширения типа такой
Я конечно же не имел в виду отказываться от RAID. Для практически любого NAS нужен RAID, все знают (ну или рано или поздно узнают) как бекапить.
Я имел в виду зачем в домашних условиях использовать именно аппаратный RAID? Чтобы с большей вероятностью огрести проблем?
У меня к большинству проектов домашних NAS есть одна претензия -- частое использование нестандартных или относительно редких компонент, контроллеров и т.п.
(Не то, чтобы в данном случае было зашкаливающее количество редких компонент -- хотя бы материнская плата обычная и блок питания более-менее распространенного форм-фактора. Больше просто подискутировать.)
Личный, домашний NAS должен быть собран из максимально простых и повсеместно доступных комплектующих. Уровня "без предварительных заказов, взял и сбегал в ближайший компьютерный магазин" доступных комплектующих.
Потому что иначе в самый неподходящий момент что-то выйдет из строя и данные окажутся недоступны совершенно непрогнозируемое время, от дней до нескольких недель. Отвалился специфичный разветвитель на 6 портов -- выпало несколько дисков, массив больше недоступен и останется недоступен еще пару недель пока новый разветвитель едет из Китая. Вышел из строя RAID-контроллер -- и данные вообще пропали, потому что точно такой же больше уже не купить.
Это кстати тоже момент, меня всегда несколько удивляла любовь к аппаратным RAID-контроллерам в домашних NAS. Это же просто лишняя точка отказа. Программный RAID сильно гибче и несопоставимо ремонтопригоднее, а значит надежнее.
Да, без контроллера можно рассчитвать только на 4-6 SATA портов на самой материнской плате. Ну значит надо плясать от этого, добавляя порты с помощью самых простых карт расширения на 2-4 дополнительных порта. Не получается собрать NAS мечты из обычных комплектующих -- ну значит придется корректировать желания. Использовать ATX вместо mini-ITX, постепенно переходить на диски большего объема и т. п.
Я имею в виду что домашний сервер -- это ведь не сервер в дата-центре с заключенными контрактами на обслуживание, гарантированными сроками доступности, поставки и замены запчастей. Он должен быть в первую очередь элементарно ремонтопригодным, а остальное уж как получится. Возможность воткнуть только 8-16 дисков вместо 26 -- это так, мелочи. Потеря доступа к данным на недели или вовсе полная утеря данных -- это катастрофа.
можно взять крейт, написанный для старого edition и добавить в новый проект с edition 2024, к примеру, и собрать самым свежим компилятором
Вот тут любопытный момент, кстати. Это возможно потому что
As a result, changes found in new Rust editions tend to be 'skin deep'. All Rust code - regardless of edition - will ultimately compile down to the same internal representation within the compiler
Но в контексте стандартизации и изменений в языке речт конечно же идет не о просто новых фичах языка (это и в C++ можно легко использовать библиотеку на C++17 в проекте на C++23), а о бинарно несовместимых изменениях, когда "same internal representation" становится помехой.
Если ABI не менять, то получится точно то же самое, что и с текущим C++, коотрый тащит всю обратную совместимость и разные ошибки/неоптимальные решения в стандартной библиотеке уже не починить. А если ABI можно менять, то код в одинаковое представление уже не соберется по построению.
Это может и не быть проблемой, если, как с большинством кода на Rust сейчас, все всегда собирать с нуля одним компилятором. Но опять-таки, то же самое сработало бы и в случае C++ -- ан нет, пересборка всего всегда с нуля не вариант.
В отличие от зумов, этот сенсор используется целиком только при фокусном расстоянии 28мм. При стандартном 35мм работает примерно половина площади сенсора, при 50мм - четверть.
Ну так это и не зум, а фикс. Почему вы вдруг записываете в недостатки что он не работает как зум? Это определенный тип камер/объективов и сценарий использования, многие совершенно осознанно выбирают и снимают на фикс.
Если вам не нравится 28 мм ЭФР, у Ricoh есть модель с 40 мм ЭФР (GRIIIx, вполне вероятно, что будет и GRIVx).
Если вам не нравится ни 28 мм, ни 40 мм, ну что поделать. Возможно именно вам действительно нужна мыльница с зумом, например Sony RX100VII.
Посмотрите на ту вспышку, которую предлагают за отдельные $120 - если из нее убрать корпус, батарею и крепеж, то запросто поместится.
Конечно можно сделать корпус побольше и добавить что угодно. Но тогда это будет не настолько компактная камера, какой она задумывалась. В бесконечном списке фич, которые можно запихать в камеру, где-то придется провести черту. Очевидно, Ricoh провели ее до вспышки.
Или вы серьезно полагаете, что тут в корпусе есть хотя бы немного пустого места?
У этой мыльницы сенсор формата APS-C, что в 3.2 раза больше, чем в большинстве аналогов и тем более ультразумах, где используется матрица размером 1".
Места для встроенной вспышки, посмею предположить, не нашлось чисто физически. Да, можно сделать корпус побольше, добавить вспышку, видоискатель и т. п. и получить что-то типа Fuji X100V, но зачем ещё одна X100V?
Это будет работать только если карту памяти после установки больше никогда не предполагается вынимать или заменять.
А если так, то это получается не сменный накопитель, а скорее способ апгрейда встроенного. Что с общим удешевлением флеш-памяти (во времена появления Adoptable Storage встроенной памяти иногда едва хватало на ОС с приложениями) и популяризацией облаков перестало быть серьезным конкурентным преимуществом.
Положа руку на ногу, сейчас проще сразу взять смартфон с достаточным объемом памяти, а когда через несколько лет её перестанет хватать -- обновить весь смартфон целиком. Мотивация производителя в этом сценарии так и вовсе очевидна.
Тем же, кому слот под SD-карточку нужен именно для сменного накопителя, объединение в один диск не поможет.
Sony поддерживают карты памяти, но и позиционируют свой флагман как рабочий инструмент для фото/видео-съемки, с непредсказуемыми требованиями к дисковому пространству и необходимостью быстрой замены накопителя.
Скорость работы даже безотносительно качества исполнения карточки. Поддержка PCI-E в картах памяти появилась относительно недавно.
С эксплуатационной точки зрения карточки памяти менее надежны -- большинство наверняка смогут припомнить поломку/ошибки карты памяти у них лично или знакомых. Выход из строя встроенной памяти телефона событие экстраординарное.
При наличии съемного накопителя дисковое пространство смартфона делится на две части и становится необходимо поддерживать это на уровне ПО, а пользователям -- постоянно путаться что куда должно сохраняться.
При этом абсолютному большинству пользователей в первую очередь надо чтобы работало и желательно как можно проще и надёжнее. Поэтому со временем и прогрессом в объемах флеш-памяти пользователи просто стали выбирать модели со все большей и большей встроенной памятью пока наконец необходимость в съемном носителе не стала нишевой.
Среди флагманов поддержка SD-карты и 3.5 мм джека есть только в Sony Xperia.
В среднебюджетном сегменте слот для SD-карты есть только у нескольких моделей Samsung.
В бюджетном сегменте да, ещё можно найти. Наверное это обусловлено тем, что там карточка нужнее -- встроенной памяти ставят меньше, чем в более дорогие модели.
Можно переводить нормальные американские USD со счёта на счёт.
Но ведь нельзя же, в этом и вся закавыка. Мы же про РФ говорим и про регулирование криптовалют в РФ, а не про абстрактные переводы из США в ЕС между людьми с "правильными" паспортами.
Вообще обсуждаемые CCD/CMOS сенсоры не совсем так работают =). Чем больше размер пикселя, тем больше его электрическая емкость и тем больше заряда он может накопить. То есть один фотон для маленького пикселя или четыре для большого увеличат заряд пикселя пропорционально одинаково, условно 1/100 для маленького и 4/400 для большого.
При этом ЦАП разумеется рассчитан на преобразование всего диапазона от минимального до максимального значения, включая предварительное аналоговое усиление сигнала, знакомое нам как ISO.
Но это все конечно сугубо гипотетические крайности. Единицы фотонов на пиксель это такое малое количество света, что там уже по другой причине не важно какого размера пиксели -- сигнал/шум всего изображения все равно получается слишком низким для какого-либо практического применения. Для съемки в таких условиях используют сенсоры на однофотонных лавинных диодах (SPAD, single-photon avalanche diode), которые буквально подсчитывают отдельные фотоны.
Размер пикселя напрямую влияет на соотношение сигнал/шум. <...> Сенсор на 200мп работает более менее только благодаря бинингу.
Размер пикселя влияет на сигнал/шум и динамический диапазон отдельного пикселя, но не изображения целиком, вот в чем закавыка.
И биннинг тому как раз подтверждение: четыре мелких пикселя имеют вчетверо худшие характеристики, чем один большой, но в сумме получается одно и то же.
То есть если например в изображении какой-то объект занимает условно 1 мм² сенсора или 100x100 пикселей, то и при использовании более крупных пикселей (1 мм², 50x50), и более мелких (1 мм², 200x200) -- сигнал/шум, динамический диапазон и т. д. этой одной и той же занимаемой объектом области изображения будет один и тот же. Потому что при всех прочих равных на одну и ту же площадь сенсора упадет то же самое количество света, а захваченные сенсором фотоны это и есть тот самый сигнал/шум.
Когда говорят про то, что более крупные пиксели захватывают больше света и потому шумят меньше, имеют более высокое значение сигнал/шум и т. п., часто упускают что это большее количество света или сигнала еще надо откуда-то взять.
Когда-то очень давно мелкие пиксели действительно захватывали меньшую долю света в сумме из-за неоптимального конструктивного исполнения. Но все современные сенсоры уже достаточно долгое время имеют приблизительно одну и ту же квантовую эффективность.
Также самая Sony, когда хотела сделать камеру с безумными ISO, сделала A7S, где всего 12мп на полный кадр
Sony A7SIII использует 48 МП сенсор с автоматическим биннингом 2x2.
Особенные характеристики этой линейки обусловлены не разрешением и/или размером пикселя, а оптимизированными под конкретный сценарий использования порогом Dual ISO и алгоритмом шумоподавления.
Типа у камер с бОльшим сенсором задний отрезок пытаются сохранить таким же? А зачем?
Все пытаются сделать оптику наиболее компактной, и короткий рабочий отрезок каким-то образом позволяет проектировать более компактные объективы -- этот момент упоминался производителями во времена перехода к беззеркальной конструкции. В частности все бренды сократили рабочий отрезок своих байонетов с 35-45 мм до 16-20 мм.
Кроме того, большинство современных байонетов рассчитаны на использование как полнокадровой, так и кропнутой оптики.
С практической точки зрения нет разницы попадет ли 4x света на один большой пиксель по 1x света на четыре маленьких.
Суть в том, что некоторая часть изображения формируется определенным количеством света. На сколько частей вы это количество света раздробите -- на один, четыре или еще больше пикселей -- не повлияет ни на шум, ни на динамический диапазон, ни даже на чувствительность в случае современных сенсоров с массивом микролинз.
Если вы возьмете пиксели большего размера, но оставите и оптику, и размер сенсора тем же самым, то вы получите точно то же самое количество света, то же самое количество информации на единицу площади изображения и в итоге ту же самую картинку, просто меньшего разрешения.
На светочувствительность и ДД влияет размер пикселя, а не сенсора. Плюс технология.
А вот и нет, при всех прочих равных важен общий размер сенсора, а размер пикселя практически не играет роли.
Например, полнокадровая фотокамера Sony A7RV показывает ожидаемые для полного кадра шум и динамический диапазон, хотя ее пиксели такого же размера, как и у кропнутой Sony A6700. Или даже повеселее, мобильный сенсор Samsung HP2 размером 1/1.4" и разрешением 200 МП имеет просто комично маленькие пиксели (буквально порядка длины волны видимого света), но при этом дает такие же снимки, как и любой другой 1/1.4" сенсор.
Заблуждение про размер пикселя скорее всего уходит корнями в популярную забаву рассматривать снятое фото в так называемом "100% масштабе", то есть грубо говоря отдельные пиксели. Но наверное сложно найти что-то более бесполезное, чем сравнивать фотографии попиксельно. Шумность и емкость отдельного пикселя не позволяют оценить примерно ничего.
Сравнивать можно только изображения в одном физическом размере, например 27" монитор или 20x30 распечатка.
А для всего изображения целиком важным оказывается только общее количество света, которое было впитано сенсором в процессе экспозиции. Размер и количество пикселей начинает играть роль когда их катастрофически не хватает и дискретизация начинает быть заметной -- что нынче уже большая редкость.
нет. чем больше сенсор - тем меньше аббераций при тех же технологиях изготовления объектива.
В теории или лаборатории -- да. На практике оптику стараются сделать компактной и расположить как можно ближе к сенсору. Кроме того байонет тоже нередко оказывается бутылочным горлышком.
Все это приводит к тому, что задним элементам оптической схемы оказывается необходимо спроецировать картинку под весьма пологим углом -- и чем больше сенсор, тем более пологим. А это усугубляет целую кучу проблем, например виньетирование и неравномерности других аберраций.
Многие производители даже занимаются исследованиями и периодически патентуют идеи того, как бы сделать сенсор вогнутым чтобы свет от заднего элемента объектива падал на него наиболее перпендикулярно по всей площади.
В интернетах периодически можно видеть обсуждения а не добавить ли в C механизм defer? И там тоже половина воспринимает идею в штыки, мол не надо в наш простой и понятный C тащить всякие неявные defer, есть же goto.
И вот представляется мне как разработчики на Go смотрят на это и думают, вот чудные, такой простой, понятный и удобный механизм не хотят использовать. А потом переключаются на соседнюю вкладку и критикуют синтаксический сахар обработки ошибкок, мол не надо в наш простой и понятный Go тащить всякие неявные try, есть же if =).
На это смотрят разработчики например на Rust и думают, вот чудные, такой простой, понятный и удобный механизм не хотят использовать. А потом переключаются на соседнюю вкладку и...
Хотел было бегло проверить правильно ли я поставил артикли, и вдруг
Вот такие вот нейросети =/.
ChatGPT и GigaChat от Сбера справились.
Очень часто вложенные условия как бы уточняют друг друга и выполняют промежуточные действия:
Такие проверки нельзя вычислить заранее и записать в одном условии, они плохо выглядят лесенкой, но зато элементарно и наглядно записываются с использованием раннего выхода.
Как говорится, плохая аналогия подобна котенку с дверцей.
Обычная инженерная сантехника как раз унифицирована донельзя и, что самое главное, совершенно одинаковая в каждом магазине, которых по несколько штук в каждом районе.
А вот если кто-то решит собрать сантехнику в самой обычной квартире из деталей, которые в ближайших магазинах не найти и надо заказывать из-за рубежа -- это точно так же будет крайне сомнительная затея, когда в случае внезапного фиаско может действительно потребоваться некоторое время условно говоря ходить на улицу.
Во-первых, с чего это вы вдруг взяли что надо заказывать в такой же мере, как в случае с контроллерами с aliexpress? Комплектующие обычных ПК в широчайшем ассортименте доступны в целом ряде магазинов рядом с домом практически 24/7.
Во-вторых, выход из строя ПК и выход из строя системы хранения данных это все-таки разные вещи. При наличии бекапа, ПК в крайнем случае можно просто выкинуть в окно целиком и купить другой. В случае с ноутбуками/неттопами многие так и поступают. Новый NAS на 26 дисков со всеми данными за последние пятнадцать лет в DNS у дома уже не купишь.
Кто сказал, что меня он пугает?
Просто в бытовых условиях аппаратный RAID это лишняя точка отказа с потенциально катастрофическими последствиями. Зачем?
Если бы вы привели аргументы мол потому что вам нужно особое шифрование, что иначе не достичь нужной производительности или нужны особые порты и поддержка особых дисков и т. п. -- то было бы понятно.
Но пока складывается впечатление, что во всех самосборных NAS аппаратный RAID (а также всякие другие более-менее редкие или специфичные комплектующие) используется просто потому что ой да какая разница, потом разберусь если что.
Ну тут понятно конечно, что в итоге каждый собирает как ему кажется правильнее.
Что у меня вызывает некоторое недопонимание -- это уверенность людей что их текущая ситуация с комплектующими, знаниями, количеством свободного времени и т. п. никогда не поменяется.
В моменте кажется что все просто и понятно, деталей -- весь aliexpress, что может пойти не так? Все может и пойдет не так =). Когда хранилище после рестарта в полном объеме обратно не поднимется, внезапно окажется что плат расширения уже не так навалом, ближайший аналог надо ждать несколько недель с aliexpress и потом разбираться почему он работает не совсем так же.
Даже если это все воспринимается как увлекательнейшее хобби, домашние пет-проекты типа локальной сети или даже сложной электросети, автоматики, систем хранения данных имеют тенденцию эксплуатироваться долго и играть существенную роль в быту. Сейчас вы готовы потратить целую кучу времени чтобы с помощью R-Studio восстановить массив. А через несколько лет, да будучи по уши в важной работе?
Поэтому мой посыл -- подобные системы по-хорошему надо проектировать исходя в первую очередь из соображений обслуживания и ремонта.
Давайте будем честными, это немного шапкозакидательство. Найти в течении дня можно разве что только в интернете, до момента пока комплектующие окажутся на столе может пройти черти сколько времени.
Я конечно же не имел в виду отказываться от RAID. Для практически любого NAS нужен RAID, все знают (ну или рано или поздно узнают) как бекапить.
Я имел в виду зачем в домашних условиях использовать именно аппаратный RAID? Чтобы с большей вероятностью огрести проблем?
У меня к большинству проектов домашних NAS есть одна претензия -- частое использование нестандартных или относительно редких компонент, контроллеров и т.п.
(Не то, чтобы в данном случае было зашкаливающее количество редких компонент -- хотя бы материнская плата обычная и блок питания более-менее распространенного форм-фактора. Больше просто подискутировать.)
Личный, домашний NAS должен быть собран из максимально простых и повсеместно доступных комплектующих. Уровня "без предварительных заказов, взял и сбегал в ближайший компьютерный магазин" доступных комплектующих.
Потому что иначе в самый неподходящий момент что-то выйдет из строя и данные окажутся недоступны совершенно непрогнозируемое время, от дней до нескольких недель. Отвалился специфичный разветвитель на 6 портов -- выпало несколько дисков, массив больше недоступен и останется недоступен еще пару недель пока новый разветвитель едет из Китая. Вышел из строя RAID-контроллер -- и данные вообще пропали, потому что точно такой же больше уже не купить.
Это кстати тоже момент, меня всегда несколько удивляла любовь к аппаратным RAID-контроллерам в домашних NAS. Это же просто лишняя точка отказа. Программный RAID сильно гибче и несопоставимо ремонтопригоднее, а значит надежнее.
Да, без контроллера можно рассчитвать только на 4-6 SATA портов на самой материнской плате. Ну значит надо плясать от этого, добавляя порты с помощью самых простых карт расширения на 2-4 дополнительных порта. Не получается собрать NAS мечты из обычных комплектующих -- ну значит придется корректировать желания. Использовать ATX вместо mini-ITX, постепенно переходить на диски большего объема и т. п.
Я имею в виду что домашний сервер -- это ведь не сервер в дата-центре с заключенными контрактами на обслуживание, гарантированными сроками доступности, поставки и замены запчастей. Он должен быть в первую очередь элементарно ремонтопригодным, а остальное уж как получится. Возможность воткнуть только 8-16 дисков вместо 26 -- это так, мелочи. Потеря доступа к данным на недели или вовсе полная утеря данных -- это катастрофа.
Вот тут любопытный момент, кстати. Это возможно потому что
Но в контексте стандартизации и изменений в языке речт конечно же идет не о просто новых фичах языка (это и в C++ можно легко использовать библиотеку на C++17 в проекте на C++23), а о бинарно несовместимых изменениях, когда "same internal representation" становится помехой.
Если ABI не менять, то получится точно то же самое, что и с текущим C++, коотрый тащит всю обратную совместимость и разные ошибки/неоптимальные решения в стандартной библиотеке уже не починить. А если ABI можно менять, то код в одинаковое представление уже не соберется по построению.
Это может и не быть проблемой, если, как с большинством кода на Rust сейчас, все всегда собирать с нуля одним компилятором. Но опять-таки, то же самое сработало бы и в случае C++ -- ан нет, пересборка всего всегда с нуля не вариант.
Ну так это и не зум, а фикс. Почему вы вдруг записываете в недостатки что он не работает как зум? Это определенный тип камер/объективов и сценарий использования, многие совершенно осознанно выбирают и снимают на фикс.
Если вам не нравится 28 мм ЭФР, у Ricoh есть модель с 40 мм ЭФР (GRIIIx, вполне вероятно, что будет и GRIVx).
Если вам не нравится ни 28 мм, ни 40 мм, ну что поделать. Возможно именно вам действительно нужна мыльница с зумом, например Sony RX100VII.
Конечно можно сделать корпус побольше и добавить что угодно. Но тогда это будет не настолько компактная камера, какой она задумывалась. В бесконечном списке фич, которые можно запихать в камеру, где-то придется провести черту. Очевидно, Ricoh провели ее до вспышки.
Или вы серьезно полагаете, что тут в корпусе есть хотя бы немного пустого места?
У этой мыльницы сенсор формата APS-C, что в 3.2 раза больше, чем в большинстве аналогов и тем более ультразумах, где используется матрица размером 1".
Места для встроенной вспышки, посмею предположить, не нашлось чисто физически. Да, можно сделать корпус побольше, добавить вспышку, видоискатель и т. п. и получить что-то типа Fuji X100V, но зачем ещё одна X100V?
Это будет работать только если карту памяти после установки больше никогда не предполагается вынимать или заменять.
А если так, то это получается не сменный накопитель, а скорее способ апгрейда встроенного. Что с общим удешевлением флеш-памяти (во времена появления Adoptable Storage встроенной памяти иногда едва хватало на ОС с приложениями) и популяризацией облаков перестало быть серьезным конкурентным преимуществом.
Положа руку на ногу, сейчас проще сразу взять смартфон с достаточным объемом памяти, а когда через несколько лет её перестанет хватать -- обновить весь смартфон целиком. Мотивация производителя в этом сценарии так и вовсе очевидна.
Тем же, кому слот под SD-карточку нужен именно для сменного накопителя, объединение в один диск не поможет.
Sony поддерживают карты памяти, но и позиционируют свой флагман как рабочий инструмент для фото/видео-съемки, с непредсказуемыми требованиями к дисковому пространству и необходимостью быстрой замены накопителя.
Потому что большой объем памяти это в первую очередь про удобство. Про надёжность хранения -- это бэкапы и прочее резервирование.
Карты памяти тут ничего фундаментально не меняют. Собственно поэтому большинству достаточно просто большого объема встроенной памяти в смартфоне.
Там много факторов на самом деле.
Скорость работы даже безотносительно качества исполнения карточки. Поддержка PCI-E в картах памяти появилась относительно недавно.
С эксплуатационной точки зрения карточки памяти менее надежны -- большинство наверняка смогут припомнить поломку/ошибки карты памяти у них лично или знакомых. Выход из строя встроенной памяти телефона событие экстраординарное.
При наличии съемного накопителя дисковое пространство смартфона делится на две части и становится необходимо поддерживать это на уровне ПО, а пользователям -- постоянно путаться что куда должно сохраняться.
При этом абсолютному большинству пользователей в первую очередь надо чтобы работало и желательно как можно проще и надёжнее. Поэтому со временем и прогрессом в объемах флеш-памяти пользователи просто стали выбирать модели со все большей и большей встроенной памятью пока наконец необходимость в съемном носителе не стала нишевой.
Среди флагманов поддержка SD-карты и 3.5 мм джека есть только в Sony Xperia.
В среднебюджетном сегменте слот для SD-карты есть только у нескольких моделей Samsung.
В бюджетном сегменте да, ещё можно найти. Наверное это обусловлено тем, что там карточка нужнее -- встроенной памяти ставят меньше, чем в более дорогие модели.
Ещё Sony Xperia, там у флагмана даже 3.5 мм до сих пор есть. Но то самураи, у них нет цели, только путь.
Но ведь нельзя же, в этом и вся закавыка. Мы же про РФ говорим и про регулирование криптовалют в РФ, а не про абстрактные переводы из США в ЕС между людьми с "правильными" паспортами.
Вообще обсуждаемые CCD/CMOS сенсоры не совсем так работают =). Чем больше размер пикселя, тем больше его электрическая емкость и тем больше заряда он может накопить. То есть один фотон для маленького пикселя или четыре для большого увеличат заряд пикселя пропорционально одинаково, условно 1/100 для маленького и 4/400 для большого.
При этом ЦАП разумеется рассчитан на преобразование всего диапазона от минимального до максимального значения, включая предварительное аналоговое усиление сигнала, знакомое нам как ISO.
Но это все конечно сугубо гипотетические крайности. Единицы фотонов на пиксель это такое малое количество света, что там уже по другой причине не важно какого размера пиксели -- сигнал/шум всего изображения все равно получается слишком низким для какого-либо практического применения. Для съемки в таких условиях используют сенсоры на однофотонных лавинных диодах (SPAD, single-photon avalanche diode), которые буквально подсчитывают отдельные фотоны.
Размер пикселя влияет на сигнал/шум и динамический диапазон отдельного пикселя, но не изображения целиком, вот в чем закавыка.
И биннинг тому как раз подтверждение: четыре мелких пикселя имеют вчетверо худшие характеристики, чем один большой, но в сумме получается одно и то же.
То есть если например в изображении какой-то объект занимает условно 1 мм² сенсора или 100x100 пикселей, то и при использовании более крупных пикселей (1 мм², 50x50), и более мелких (1 мм², 200x200) -- сигнал/шум, динамический диапазон и т. д. этой одной и той же занимаемой объектом области изображения будет один и тот же. Потому что при всех прочих равных на одну и ту же площадь сенсора упадет то же самое количество света, а захваченные сенсором фотоны это и есть тот самый сигнал/шум.
Когда говорят про то, что более крупные пиксели захватывают больше света и потому шумят меньше, имеют более высокое значение сигнал/шум и т. п., часто упускают что это большее количество света или сигнала еще надо откуда-то взять.
Когда-то очень давно мелкие пиксели действительно захватывали меньшую долю света в сумме из-за неоптимального конструктивного исполнения. Но все современные сенсоры уже достаточно долгое время имеют приблизительно одну и ту же квантовую эффективность.
Sony A7SIII использует 48 МП сенсор с автоматическим биннингом 2x2.
Особенные характеристики этой линейки обусловлены не разрешением и/или размером пикселя, а оптимизированными под конкретный сценарий использования порогом Dual ISO и алгоритмом шумоподавления.
Все пытаются сделать оптику наиболее компактной, и короткий рабочий отрезок каким-то образом позволяет проектировать более компактные объективы -- этот момент упоминался производителями во времена перехода к беззеркальной конструкции. В частности все бренды сократили рабочий отрезок своих байонетов с 35-45 мм до 16-20 мм.
Кроме того, большинство современных байонетов рассчитаны на использование как полнокадровой, так и кропнутой оптики.
С практической точки зрения нет разницы попадет ли 4x света на один большой пиксель по 1x света на четыре маленьких.
Суть в том, что некоторая часть изображения формируется определенным количеством света. На сколько частей вы это количество света раздробите -- на один, четыре или еще больше пикселей -- не повлияет ни на шум, ни на динамический диапазон, ни даже на чувствительность в случае современных сенсоров с массивом микролинз.
Если вы возьмете пиксели большего размера, но оставите и оптику, и размер сенсора тем же самым, то вы получите точно то же самое количество света, то же самое количество информации на единицу площади изображения и в итоге ту же самую картинку, просто меньшего разрешения.
А вот и нет, при всех прочих равных важен общий размер сенсора, а размер пикселя практически не играет роли.
Например, полнокадровая фотокамера Sony A7RV показывает ожидаемые для полного кадра шум и динамический диапазон, хотя ее пиксели такого же размера, как и у кропнутой Sony A6700. Или даже повеселее, мобильный сенсор Samsung HP2 размером 1/1.4" и разрешением 200 МП имеет просто комично маленькие пиксели (буквально порядка длины волны видимого света), но при этом дает такие же снимки, как и любой другой 1/1.4" сенсор.
Заблуждение про размер пикселя скорее всего уходит корнями в популярную забаву рассматривать снятое фото в так называемом "100% масштабе", то есть грубо говоря отдельные пиксели. Но наверное сложно найти что-то более бесполезное, чем сравнивать фотографии попиксельно. Шумность и емкость отдельного пикселя не позволяют оценить примерно ничего.
Сравнивать можно только изображения в одном физическом размере, например 27" монитор или 20x30 распечатка.
А для всего изображения целиком важным оказывается только общее количество света, которое было впитано сенсором в процессе экспозиции. Размер и количество пикселей начинает играть роль когда их катастрофически не хватает и дискретизация начинает быть заметной -- что нынче уже большая редкость.
В теории или лаборатории -- да. На практике оптику стараются сделать компактной и расположить как можно ближе к сенсору. Кроме того байонет тоже нередко оказывается бутылочным горлышком.
Все это приводит к тому, что задним элементам оптической схемы оказывается необходимо спроецировать картинку под весьма пологим углом -- и чем больше сенсор, тем более пологим. А это усугубляет целую кучу проблем, например виньетирование и неравномерности других аберраций.
Многие производители даже занимаются исследованиями и периодически патентуют идеи того, как бы сделать сенсор вогнутым чтобы свет от заднего элемента объектива падал на него наиболее перпендикулярно по всей площади.
В интернетах периодически можно видеть обсуждения а не добавить ли в C механизм defer? И там тоже половина воспринимает идею в штыки, мол не надо в наш простой и понятный C тащить всякие неявные defer, есть же goto.
И вот представляется мне как разработчики на Go смотрят на это и думают, вот чудные, такой простой, понятный и удобный механизм не хотят использовать. А потом переключаются на соседнюю вкладку и критикуют синтаксический сахар обработки ошибкок, мол не надо в наш простой и понятный Go тащить всякие неявные try, есть же if =).
На это смотрят разработчики например на Rust и думают, вот чудные, такой простой, понятный и удобный механизм не хотят использовать. А потом переключаются на соседнюю вкладку и...