Куча комментариев мол на вопрос какая сейчас дата без контекста нет объективно правильного ответа (чья дата? где именно дата?) и поэтому внешне случайный ответ нейронки корректен. Надо правильно формулировать вопросы.
Господа, а разве не об этом идёт речь в статье? Нейронка не знает и не понимает границ применимости своих знаний. Вместо того, чтобы переспросить или ответить мол не знаю какая вам нужна, но моя внутренняя дата какая-то, она просто отвечает первое попавшееся.
Некорректно ожидать, что пользователь должен знать и учитывать в запросе какую-то скрытую и непредсказуемую логику в модели. Сейчас модель под датой понимает черти-что и просто надо уточнить, что дата календарная в часовом поясе пользователя. А завтра модель на вопрос 5+5 уверенно ответит 12 -- но это нормально и корректно, мало ли какая система счисления подразумевалась, надо было просто уточнить в запросе.
Если нейронка уверенно и без оговорок отвечает неправильный результат в самом обычном, ожидаемом пользователем контексте -- это галлюцинация.
Если вас разбудили и спросили сколько времени, а вы в ответ уверенно назвали первое пришедшее на ум -- это тоже галлюцинация. То, что у неправильного ответа есть какое-то объяснение и оправдание, не отменяет факта что это случайный ответ наобум.
Поэтому вывод точно такой же: текущие нейронки не понимают, что они не знают или не могут знать ответ.
У сенсоров интерфейс как правило MIPI DSI + настрйока по i2c. На некоторые сенсоры есть открытые драйвера, но документацию достать сложно
Это для небольших мобильных сенсоров типа IMX219 можно найти поддержку то тут, то там =/.
Крупные сенсоры поставляются по индивидуальным заказам и надо полагать под NDA. Соответственно никаких открытых драйверов и даташитов в свободном доступе нет и взяться им неоткуда.
Проблема в том, что плата современной беззеркалки это уже далеко не DIY уровень.
Ну вон у Sitina1 же как-то получилось =). Плата современной беззеркалки -- это по сути обычная мобильная SoC, плюс специализированный DSP. Основную SoC в крайнем случае можно вообще взять в виде модуля по типу Raspberry Pi Compute Module, а DSP реализовать в ПЛИС.
И тогда проблем не было, может просто корпоративные гиганты не замечали этой мелочи
Думаю да, во времена Sony A интернет был сам по себе и на такое меньше обращали внимание. Сейчас за нарушение авторских прав и лицензий щучат намного жестче.
Кстати Sony даже отдельно отмечает что поддержка протокола в объективе это еще туда-сюда, но вот реализовывать функциональность камеры нельзя никому, никак, ни при каких условиях. Из-за это например сторонние производители не могут выпускать телеконвертеры для Sony E, потому что это потребовало бы телеконвертеру прикидываться камерой для подсоединяемого к нему объектива, а так нельзя.
В общем сложно представить, что проект условно полноценной беззеркалки с поддержкой современного байонета долго протянет на каком-нибудь популярном хостинге.
А тягаться с коммерческими аппаратами надо допиливая софт коммерческого аппарата
Эх если бы только это можно было делать!
Сейчас производители не дают писать софт под свои камеры, а реверсить прошивки это легкое безумие.
Максимум, что можно сделать штатными средствами -- это взять за основу встраиваемый модуль по типу Sony ILX-LR1 за какие-то $3000 и управлять им по специальному протоколу типа Sony Camera Remote SDK. И то я не уверен что лицензия этой SDK позволяет публикацию проектов с ее использованием без предварительного на то разрешения.
Sitina1 -- очень крутой проект. Сам бы с удовольствием поработал над фотокамерой мечты, но к сожалению в этой конкретной нише есть два фундаментальных препятствия:
Большой современный сенсор нигде не достать. Их нет в продаже, а на те, что можно выколупать из запчастей к коммерческим камерам, нет документации. Автор Sitina1 выстроил весь проект вокруг одного старого CCD сенсора, который по чистой случайности получилось найти на ebay -- увы, это не очень хорошо масштабируется.
Можно рассчитывать только на использование объективов с ручной фокусировкой, в основном винтажных. Потому что протоколы для байонетов просто так никто не даст, и даже если умудриться реверс-инжинирить какой-нибудь, этим нельзя будет публично поделиться.
В итоге, в лучшем случае получится крутая игрушка =(. А хотелось бы собрать аппарат, котороый мог бы потягаться с коммерческими -- как минимум в плане софта большинство беззеркалок действительно, хм, очень консервативны.
Поздно, это общеупотребимый жаргонизм, которому уже несколько десятков лет.
Причем в данном случае и ничего плохого по сути нет, ну подсократили длину слова, все равно никто не перепутает математический функционал и функционал программы, так же как нет проблем со словами функция, ротор и т. п.
Вот когда например путают аутентификацию и авторизацию -- да, смысл искажается.
В этом рассказе не хватает еще одного допущения: прежде чем захватывать контроль, нужно чтобы ИИ получил в распоряжение роботов, схожих по надежности и гибкости с человеком, в количестве, достаточном чтобы пересилить вооруженные силы человечества.
Не то, чтобы это нельзя было вообразить -- вон китайцы там уже что-то мастерят -- но это определенно будет очень заметно и приведет к существенным изменениям в сюжете.
А техника, которая переживает Рагнарек, и захват полного контроля над физическим миром по радиоканалам -- это такая фантастика, что даже фентези.
Допускаю что у станков с ЧПУ может быть специфика, например необходимость физического совмещения станка и рабочего ПК оператора с прикладным ПО. Если в корпусе все равно уже так или иначе будет целый ПК, то можно перераспределить ответственность между узлами.
Просто в большинстве электроники и автоматики что мне доводилось видеть, от бытовой и до промышленной, никакого рабочего места в составе корпуса изделия нет и соответственно никакого ПК внутри тоже нет.
Противоречие в том, что мол смысла нет писать прошивку с графическим интерфейсом, все равно для редактора чертежей потребуется целый комп.
И тем не менее, скажем отрисовку пусть и простенького, но графического интерфейса меню на экране на корпусе устройства придется выполнять на самом устройстве, так же как и сетевой стек для общения с "высокоуровневой управляющей программой" очевидно может быть реализован только на нем.
Много чего чисто физически нельзя переложить на какой-то там внешний ПК с видеокартами, да и незачем.
Ну так перечитали бы ветку, не такая уж и длинная =/.
Я несколько сообщений назад отметил, что ПО непосредственно самого устройства (в данном случае станка) может и чаще всего работает без полноформатной ОС ибо ну зачем она там вообще нужна, прямо на устройстве-то.
Вы оппонировали что обычная ОС нужна потому, что так проще писать ПО для оператора. Видимо полагая что на устройстве ПО фигня и не считается, просто какая-то плата расширения.
Ну вот я и пытался донести мысль, что на самом устройстве обычно целая гора ПО вплоть до полной автономности отдельных функций, и все как правило без обычной ОС. А пользовательское ПО это конечно тоже важно, но к делу не относится, как и то, что его проще писать под обычную ОС.
Любая сложная автоматика будет иметь набор низкоуровневых и не только функций, которые нерационально или попросту невозможно реализовать на полноценном x86 ПК под управлением привычной пользовательской ОС.
При этом часто требуется и полноценное рабочее место инженера/оператора, с графическим редактором, сложной визуализацией, всякими расчетами проекта и т. д.
Но это не означает, что надо обязательно пытаться вообще все сделать либо на микроконтроллере, либо на x86 ПК под Windows. Это две отдельные части одного продукта.
В качестве очевидного примера возьмите все тот же МФУ или качественный брендовый 3D-принтер. Целая куча функций, реализованных непосредственно на самом устройстве практически на голом железе, и при этом не меньшая куча различного софта на ПК пользователя.
Иронично, что как раз наоборот лишь любительское или собранное из подручных материалов оборудование может позволить себе быть примитивным исполнителем для программы на каком-то ПК.
Полноценное коммерческое устройство будет иметь различные функции защиты, самодиагностики, калибровки, сервисное меню для всяких случаев, кучу элементов управления, будет общаться с ПО на ПК оператора по какому-то протоколу вплоть до обычной сети и т. д. и т. п. Это куча программного кода.
Мы же не о каком-то переделанном под ЧПУ станке говорим, а о сложном промышленном станке как готовом продукте. Просто посмотрите примеры таких станков, это совершенно точно не то устройство, которое колом встанет случись что с внешним ПК оператора.
У вас какое-то, хм, предвзятое представление о технике.
Очень часто "плата расширения" с микроконтроллером -- это все, что есть в устройстве. И нет никакой другой платы с еще более верхней логикой, все программное обеспечение устройства на этой плате.
Чаще всего прошивка устройства намного сложнее, чем бездумное выполнение максимально низкоуровневых команд извне. И например в МФУ прикрутить простенькое графическое меню и распечатку с флешки или даже отправку сканов по сети может быть намного проще и надежнее реализовать на все той же "плате расширения", чем городить внутри еще один компьютер с "обычной ОС" и как-то потом это друг с другом стыковать.
Точно так же и станок ЧПУ. Он запросто может иметь практически автономную прошивку, которая работает по сети с обычным десктопным ПО на ПК оператора.
В контексте обсуждения мол да там просто очередной линукс с переделанными логотипами, я думаю наличие например FreeRTOS можно вполне записать в категорию отсутствия привычной ОС и наличия лишь специального ПО, которое работает сразу при включении системы.
Справедливости ради, никто уже давно не пишет софт для встраиваемого оборудования на голом ассемблере. Те же языки высокого уровня, тот же сетевой стек, если оборудование позволяет, есть инструменты для вывода графического интерфейса и т. д. и т. п.
Ну, если конечно речь не идет о каком-нибудь МК с 1 КБ ПЗУ =).
Да, только "плата расширения" это как правило неотъемлемая часть изделия и на ней реализована вся логика управления обрудованием. И там может быть очень много кода, который выполняется практически на голом железе.
В зависимости от того, что подразумевается под "управляющей программой верхнего уровня", она может быть запросто реализована непосредственно в станке на все том же контроллере, или быть обычным приложением для ПК оператора.
А как вы думаете пишется специализированное ПО для автоматики, которое выполняется на различных микроконтроллерах?
Да, нередко проще бахнуть целый комп или хотя бы что-то типа Raspberry Pi с полноценным Linux на борту, но вообще промышленный софт, который работает без привычной обывателю ОС, не является чем-то необычным.
Зачем тебе какая-то огромная ОС, если ты единственное приложение на этом устройстве? Только лишняя точка отказа.
Или, если включить душнилу, от f-числа =). Потому что f/2.3 это не апертура, а отношение фокусного расстояния к размеру апертуры.
Причем мне кажется что именно эта банальная путаница приводит к распространенному заблуждению мол f/1.8 это всегда f/1.8 независимо от размера сенсора.
А какое максимальное разрешение для камер смартфонов возможно из-за подобного рода ограничений?
А давайте посчитаем! Например для смартфона Vivo X200 Ultra, который имеет телевик с сенсором 200 MP размером 1/1.4" и объективом с физическим f-числом f/2.3.
Для данного f-числа размер диска Эйри составляет примерно 3.1 мкм. Детали становятся неразличимы при размере в 2-3 раза меньше диска Эйри. Округлим в пользу сенсора, будем считать минимально различимыми детали размером всего 1 мкм.
Сенсор формата 1/1.4" имеет размеры примерно 9.14x6.88 мм, то есть на этой площади поместится 9140x6880 пикселей размером 1x1 мкм, то есть 62 МП.
Это максимальный, теоретический предел разрешающей способности. Картинку с детализацией больше 60 МП просто физически невозможно спроецировать в такой размер с использованием такого объектива.
Очевидно, что на практике такого результата не добиться: оптика неидеальна, шум и шевеленка съедают детализацию и т. п. Фактически, при съемке в 50 МП смартфоны уже начинают вовсю выдумывать детали. Реальная детализация камер современных фотофлагманов субъективно составляет порядка 20-30 МП.
Диффракционный предел зависит от f-числа объектива и размера пикселя. Более светосильный объектив и/или более крупный сенсор позволят добиться большей детализации (а заодно меньшего шума, большего динамического диапазона и вообще). Но и то, и другое требуют оптику большего размера, а в современных смартфонах модули камер и так уже размера на грани удобства использования. Скорее всего, мы близки к физическому пределу возможностей смартфонных камер.
Я думал, что недостаточное качество снимков смартфонов вызвано тем, что покупаю недорогие модели, но может дело в оптике и физических ограничениях?
И то, и другое.
Фотофлагманы и особенно Huawei/Xiaomi/Vivo "смотри как я могу" Ultra будут снимать лучше, чем модели в несколько раз дешевле. В зависимости от условий это может быть не очень заметно или очень сильно заметно.
И дело там именно в оптике и физических ограничениях. Вычислительная фотография и постобработка у большинства смартфонов плюс-минус одинаковая, поэтому основной разницей между дешевой и дорогой камерой является размер сенсора и качество исполнения оптики.
В частности дешевые модели как правило экономят на модуле-телевике. Его вообще может не быть и зум может быть полностью цифровой. Качественный телевик в топовой модели запросто выдаст изображение кратно лучше, чем бюджетная модель.
Проще сделать индивидуальные ячейки пропорционально больше, решив задачу шума в лоб, но с маркетинговой точки зрения это гарантированный провал.
За исключением граничных случаев, количество шума всего изображения не зависит от размера отдельного пикселя. Собственно поэтому например полнокадровая Sony A7RV как и ожидается шумит меньше, чем кропнутая Sony A6700, несмотря на то, что у них пиксели одного размера.
Тут конечно не надо путать шум отдельного пикселя и всего изображения целиком =). Отдельные пиксели вышеупомянутых камер шумят одинаково, но изображение целиком у полнокадровой камеры получается менее шумным за счет большего ресемплирования при выводе/печати в одном и том же размере.
при этом без биндинга например будут будет больше шумов, ниже ДД
Количество шума и динамический диапазон всего изображения не зависит от количества пикселей (по крайней мере в случае современных сенсоров с массивом микролинз).
Характеристики отдельных пикселей конечно будут разные, но это имеет мало практического значения. Роль играет только шум и динамический диапазон целого изображения.
Куча комментариев мол на вопрос какая сейчас дата без контекста нет объективно правильного ответа (чья дата? где именно дата?) и поэтому внешне случайный ответ нейронки корректен. Надо правильно формулировать вопросы.
Господа, а разве не об этом идёт речь в статье? Нейронка не знает и не понимает границ применимости своих знаний. Вместо того, чтобы переспросить или ответить мол не знаю какая вам нужна, но моя внутренняя дата какая-то, она просто отвечает первое попавшееся.
Некорректно ожидать, что пользователь должен знать и учитывать в запросе какую-то скрытую и непредсказуемую логику в модели. Сейчас модель под датой понимает черти-что и просто надо уточнить, что дата календарная в часовом поясе пользователя. А завтра модель на вопрос 5+5 уверенно ответит 12 -- но это нормально и корректно, мало ли какая система счисления подразумевалась, надо было просто уточнить в запросе.
Если нейронка уверенно и без оговорок отвечает неправильный результат в самом обычном, ожидаемом пользователем контексте -- это галлюцинация.
Если вас разбудили и спросили сколько времени, а вы в ответ уверенно назвали первое пришедшее на ум -- это тоже галлюцинация. То, что у неправильного ответа есть какое-то объяснение и оправдание, не отменяет факта что это случайный ответ наобум.
Поэтому вывод точно такой же: текущие нейронки не понимают, что они не знают или не могут знать ответ.
Это для небольших мобильных сенсоров типа IMX219 можно найти поддержку то тут, то там =/.
Крупные сенсоры поставляются по индивидуальным заказам и надо полагать под NDA. Соответственно никаких открытых драйверов и даташитов в свободном доступе нет и взяться им неоткуда.
Ну вон у Sitina1 же как-то получилось =). Плата современной беззеркалки -- это по сути обычная мобильная SoC, плюс специализированный DSP. Основную SoC в крайнем случае можно вообще взять в виде модуля по типу Raspberry Pi Compute Module, а DSP реализовать в ПЛИС.
Думаю да, во времена Sony A интернет был сам по себе и на такое меньше обращали внимание. Сейчас за нарушение авторских прав и лицензий щучат намного жестче.
Кстати Sony даже отдельно отмечает что поддержка протокола в объективе это еще туда-сюда, но вот реализовывать функциональность камеры нельзя никому, никак, ни при каких условиях. Из-за это например сторонние производители не могут выпускать телеконвертеры для Sony E, потому что это потребовало бы телеконвертеру прикидываться камерой для подсоединяемого к нему объектива, а так нельзя.
В общем сложно представить, что проект условно полноценной беззеркалки с поддержкой современного байонета долго протянет на каком-нибудь популярном хостинге.
Эх если бы только это можно было делать!
Сейчас производители не дают писать софт под свои камеры, а реверсить прошивки это легкое безумие.
Максимум, что можно сделать штатными средствами -- это взять за основу встраиваемый модуль по типу Sony ILX-LR1 за какие-то $3000 и управлять им по специальному протоколу типа Sony Camera Remote SDK. И то я не уверен что лицензия этой SDK позволяет публикацию проектов с ее использованием без предварительного на то разрешения.
Sitina1 -- очень крутой проект. Сам бы с удовольствием поработал над фотокамерой мечты, но к сожалению в этой конкретной нише есть два фундаментальных препятствия:
Большой современный сенсор нигде не достать. Их нет в продаже, а на те, что можно выколупать из запчастей к коммерческим камерам, нет документации. Автор Sitina1 выстроил весь проект вокруг одного старого CCD сенсора, который по чистой случайности получилось найти на ebay -- увы, это не очень хорошо масштабируется.
Можно рассчитывать только на использование объективов с ручной фокусировкой, в основном винтажных. Потому что протоколы для байонетов просто так никто не даст, и даже если умудриться реверс-инжинирить какой-нибудь, этим нельзя будет публично поделиться.
В итоге, в лучшем случае получится крутая игрушка =(. А хотелось бы собрать аппарат, котороый мог бы потягаться с коммерческими -- как минимум в плане софта большинство беззеркалок действительно, хм, очень консервативны.
Поздно, это общеупотребимый жаргонизм, которому уже несколько десятков лет.
Причем в данном случае и ничего плохого по сути нет, ну подсократили длину слова, все равно никто не перепутает математический функционал и функционал программы, так же как нет проблем со словами функция, ротор и т. п.
Вот когда например путают аутентификацию и авторизацию -- да, смысл искажается.
В этом рассказе не хватает еще одного допущения: прежде чем захватывать контроль, нужно чтобы ИИ получил в распоряжение роботов, схожих по надежности и гибкости с человеком, в количестве, достаточном чтобы пересилить вооруженные силы человечества.
Не то, чтобы это нельзя было вообразить -- вон китайцы там уже что-то мастерят -- но это определенно будет очень заметно и приведет к существенным изменениям в сюжете.
А техника, которая переживает Рагнарек, и захват полного контроля над физическим миром по радиоканалам -- это такая фантастика, что даже фентези.
Допускаю что у станков с ЧПУ может быть специфика, например необходимость физического совмещения станка и рабочего ПК оператора с прикладным ПО. Если в корпусе все равно уже так или иначе будет целый ПК, то можно перераспределить ответственность между узлами.
Просто в большинстве электроники и автоматики что мне доводилось видеть, от бытовой и до промышленной, никакого рабочего места в составе корпуса изделия нет и соответственно никакого ПК внутри тоже нет.
Противоречие в том, что мол смысла нет писать прошивку с графическим интерфейсом, все равно для редактора чертежей потребуется целый комп.
И тем не менее, скажем отрисовку пусть и простенького, но графического интерфейса меню на экране на корпусе устройства придется выполнять на самом устройстве, так же как и сетевой стек для общения с "высокоуровневой управляющей программой" очевидно может быть реализован только на нем.
Много чего чисто физически нельзя переложить на какой-то там внешний ПК с видеокартами, да и незачем.
Ну так перечитали бы ветку, не такая уж и длинная =/.
Я несколько сообщений назад отметил, что ПО непосредственно самого устройства (в данном случае станка) может и чаще всего работает без полноформатной ОС ибо ну зачем она там вообще нужна, прямо на устройстве-то.
Вы оппонировали что обычная ОС нужна потому, что так проще писать ПО для оператора. Видимо полагая что на устройстве ПО фигня и не считается, просто какая-то плата расширения.
Ну вот я и пытался донести мысль, что на самом устройстве обычно целая гора ПО вплоть до полной автономности отдельных функций, и все как правило без обычной ОС. А пользовательское ПО это конечно тоже важно, но к делу не относится, как и то, что его проще писать под обычную ОС.
Вы как будто все в одну кучу мешаете.
Любая сложная автоматика будет иметь набор низкоуровневых и не только функций, которые нерационально или попросту невозможно реализовать на полноценном x86 ПК под управлением привычной пользовательской ОС.
При этом часто требуется и полноценное рабочее место инженера/оператора, с графическим редактором, сложной визуализацией, всякими расчетами проекта и т. д.
Но это не означает, что надо обязательно пытаться вообще все сделать либо на микроконтроллере, либо на x86 ПК под Windows. Это две отдельные части одного продукта.
В качестве очевидного примера возьмите все тот же МФУ или качественный брендовый 3D-принтер. Целая куча функций, реализованных непосредственно на самом устройстве практически на голом железе, и при этом не меньшая куча различного софта на ПК пользователя.
Иронично, что как раз наоборот лишь любительское или собранное из подручных материалов оборудование может позволить себе быть примитивным исполнителем для программы на каком-то ПК.
Полноценное коммерческое устройство будет иметь различные функции защиты, самодиагностики, калибровки, сервисное меню для всяких случаев, кучу элементов управления, будет общаться с ПО на ПК оператора по какому-то протоколу вплоть до обычной сети и т. д. и т. п. Это куча программного кода.
Мы же не о каком-то переделанном под ЧПУ станке говорим, а о сложном промышленном станке как готовом продукте. Просто посмотрите примеры таких станков, это совершенно точно не то устройство, которое колом встанет случись что с внешним ПК оператора.
У вас какое-то, хм, предвзятое представление о технике.
Очень часто "плата расширения" с микроконтроллером -- это все, что есть в устройстве. И нет никакой другой платы с еще более верхней логикой, все программное обеспечение устройства на этой плате.
Чаще всего прошивка устройства намного сложнее, чем бездумное выполнение максимально низкоуровневых команд извне. И например в МФУ прикрутить простенькое графическое меню и распечатку с флешки или даже отправку сканов по сети может быть намного проще и надежнее реализовать на все той же "плате расширения", чем городить внутри еще один компьютер с "обычной ОС" и как-то потом это друг с другом стыковать.
Точно так же и станок ЧПУ. Он запросто может иметь практически автономную прошивку, которая работает по сети с обычным десктопным ПО на ПК оператора.
В контексте обсуждения мол да там просто очередной линукс с переделанными логотипами, я думаю наличие например FreeRTOS можно вполне записать в категорию отсутствия привычной ОС и наличия лишь специального ПО, которое работает сразу при включении системы.
Справедливости ради, никто уже давно не пишет софт для встраиваемого оборудования на голом ассемблере. Те же языки высокого уровня, тот же сетевой стек, если оборудование позволяет, есть инструменты для вывода графического интерфейса и т. д. и т. п.
Ну, если конечно речь не идет о каком-нибудь МК с 1 КБ ПЗУ =).
Да, только "плата расширения" это как правило неотъемлемая часть изделия и на ней реализована вся логика управления обрудованием. И там может быть очень много кода, который выполняется практически на голом железе.
В зависимости от того, что подразумевается под "управляющей программой верхнего уровня", она может быть запросто реализована непосредственно в станке на все том же контроллере, или быть обычным приложением для ПК оператора.
А как вы думаете пишется специализированное ПО для автоматики, которое выполняется на различных микроконтроллерах?
Да, нередко проще бахнуть целый комп или хотя бы что-то типа Raspberry Pi с полноценным Linux на борту, но вообще промышленный софт, который работает без привычной обывателю ОС, не является чем-то необычным.
Зачем тебе какая-то огромная ОС, если ты единственное приложение на этом устройстве? Только лишняя точка отказа.
Приложение, даже если оно работает в линуксе -- это тоже ПО.
Или, если включить душнилу, от f-числа =). Потому что f/2.3 это не апертура, а отношение фокусного расстояния к размеру апертуры.
Причем мне кажется что именно эта банальная путаница приводит к распространенному заблуждению мол f/1.8 это всегда f/1.8 независимо от размера сенсора.
А давайте посчитаем! Например для смартфона Vivo X200 Ultra, который имеет телевик с сенсором 200 MP размером 1/1.4" и объективом с физическим f-числом f/2.3.
Для данного f-числа размер диска Эйри составляет примерно 3.1 мкм. Детали становятся неразличимы при размере в 2-3 раза меньше диска Эйри. Округлим в пользу сенсора, будем считать минимально различимыми детали размером всего 1 мкм.
Сенсор формата 1/1.4" имеет размеры примерно 9.14x6.88 мм, то есть на этой площади поместится 9140x6880 пикселей размером 1x1 мкм, то есть 62 МП.
Это максимальный, теоретический предел разрешающей способности. Картинку с детализацией больше 60 МП просто физически невозможно спроецировать в такой размер с использованием такого объектива.
Очевидно, что на практике такого результата не добиться: оптика неидеальна, шум и шевеленка съедают детализацию и т. п. Фактически, при съемке в 50 МП смартфоны уже начинают вовсю выдумывать детали. Реальная детализация камер современных фотофлагманов субъективно составляет порядка 20-30 МП.
Диффракционный предел зависит от f-числа объектива и размера пикселя. Более светосильный объектив и/или более крупный сенсор позволят добиться большей детализации (а заодно меньшего шума, большего динамического диапазона и вообще). Но и то, и другое требуют оптику большего размера, а в современных смартфонах модули камер и так уже размера на грани удобства использования. Скорее всего, мы близки к физическому пределу возможностей смартфонных камер.
И то, и другое.
Фотофлагманы и особенно Huawei/Xiaomi/Vivo "смотри как я могу" Ultra будут снимать лучше, чем модели в несколько раз дешевле. В зависимости от условий это может быть не очень заметно или очень сильно заметно.
И дело там именно в оптике и физических ограничениях. Вычислительная фотография и постобработка у большинства смартфонов плюс-минус одинаковая, поэтому основной разницей между дешевой и дорогой камерой является размер сенсора и качество исполнения оптики.
В частности дешевые модели как правило экономят на модуле-телевике. Его вообще может не быть и зум может быть полностью цифровой. Качественный телевик в топовой модели запросто выдаст изображение кратно лучше, чем бюджетная модель.
За исключением граничных случаев, количество шума всего изображения не зависит от размера отдельного пикселя. Собственно поэтому например полнокадровая Sony A7RV как и ожидается шумит меньше, чем кропнутая Sony A6700, несмотря на то, что у них пиксели одного размера.
Тут конечно не надо путать шум отдельного пикселя и всего изображения целиком =). Отдельные пиксели вышеупомянутых камер шумят одинаково, но изображение целиком у полнокадровой камеры получается менее шумным за счет большего ресемплирования при выводе/печати в одном и том же размере.
Количество шума и динамический диапазон всего изображения не зависит от количества пикселей (по крайней мере в случае современных сенсоров с массивом микролинз).
Характеристики отдельных пикселей конечно будут разные, но это имеет мало практического значения. Роль играет только шум и динамический диапазон целого изображения.