вы треть тысячи долларов заплатили только ради того, чтобы сказать, что у вас принтер от HP (и картриджи к нему неизвестного состава). В чем смысл?
Ну в то время, когда я его покупал, это было единственное приемлемое по цене предложение за дуплекс принтер формата А3. А цветной лазерник такого формата стоил каких-то невменяемых денег. В принципе я им доволен, он неприхотливый, достаточно компактный и на хорошей бумаге очень прилично (для офисного принтера) печатает.
Это из разряда "как отъять максимально возможное количество денег у покупателя, притом так, чтобы он был свято уверен, что ему это выгодно".
Вот смотрите, у меня дома МФУ HP Office Jet 7720, куплен осенью 2019, ему почти пять лет (53 месяца, если быть точным). Отдал я за него 180 евро по какой-то акции-распродаже. Картриджи 953XL оригинальные нынче на амазоне стоят 180(!) евро. Я беру неоригинал за тридцать (он их вполне принимает после даунгрейда). Сейчас установлен пятый комплект картриджей, суммарно расходы 180+30*5 = 330 евро за пять лет. Отечатано на нём по счётчику 3718 листов, это в среднем 70 страниц в месяц. Мне предлагают план за 17 долларов, и это будет 17*53 = 901 доллар, почти втрое дороже. Кроме того, нагрузка у него очень неравномерная, он может пару-тройку месяцев вообще почти не использоваться, а может неделю интенсивно (в основном он нужен детям-гимназистам и супруге - она учитель рисования). Доставка картриджа на следующий рабочий день — вообще смешно, если надо что-то срочно напечатать, а у меня всегда лежит запасной.
Только я хотел написать, что бабочка - это насекомое, а не животное, а оказалось — таки да, animals.
Кстати, для того чтобы снабдить консольное приложение интерфейсом, можно Nuklear воспользоваться. Это очень лекговесная и простая штука, но там можно много чего сделать.
Монорепозиторий - это в том числе про управление зависимостями. Насколько он применим - зависит в общем от структуры проектов. Я использовал такой подход ещё с конца девяностых, где-то до 2007 года. Тогда мы хранили код, используя Microsoft Visual SourceSafe, была такая штука (ни TFS ни Git в то время не было, они где-то в 2005 появились). Так вот в SourceSafe была такая фишка, которая называлась "Линки". У меня проекты были основаны на плагин-архитектуре. В монорепозитории эти плагины хранились все скопом, а вот для каждого отдельного проекта заводилась виртуальная папка, куда необходимые модули линковались из монорепозитория. Если там были файлы, специфические для конкретного проекта, то в монорепозиторий они не попадали. Это было очень удобно. Я мог посмотреть как историю по отдельным проектам, так и по монорепозиторию целиком. Когда я забирал из репозитория код проекта, то на диске у меня появлялиь лишь файлы, исполользованные в проекте и ничего лишнего. Важно было то, что отдельные модули были вообще никак не связаны, технически все вызовы отправлялись в микроядро, а межмодульные вызовы были строго запрещены. Общались модули между собой, устанавливая соединение в рантайме через именованные очереди. Модулей было около трёхсот, а проектов -где-то полтора десятка, какой-то проект мого использовать 50-70 модулей, а какой-то - 20-30, из из модулей проекты собирались как из кубиков Лего. Ну и когда добавлялся новый функционал, то это само собой автоматом распространялось на все проекты, в которых этот модуль использовался. Всё бы ничего, но MS VSS проект был закрыт, на смену пришёл TFS. И компания решила напрочь выпилить линки, потому что мало кто их использовал и вообще это "плохая практика". Это действительно может быть плохой практикой, устроив ад из зависимостей, но при слабой связанности - было самое то. Короче, была куча дискуссий, и в ответ производитель TFS лишь писал - ну нет проблем, сделайте линки на вашем диске, на клиентской стороне. Так можно, конечно, но это абсолютно неудобно. Мы перебросили код в TFS и как-то выкрутились, но линки жаль, у меня теперь весь монорепозиторий валяется на диске и при работе с конкретными проектами я постоянно натыкаюсь на "ненужные" мне в данный момент артефакты. Конкретно сейчас мы переезжаем с TFS в Git, надо будет разобраться, как там.
Ещё в качестве примера программирования без переменных можно привести графическое программирование, основанное на парадигме потоков данных (Data Flow).
Предположим я хочу вычислить (x+y)*z. Можно сделать вот так, заведя переменные (так обычно не делают, но тем не менее), в LabVIEW вот так:
Но можно выкинуть все переменные, оставив лишь потоки данных (так обычно и делают)
Ну и поскольку имена переменных имеют лишь номинальное значение, а мы всё равно в хабе "ненормальное програмирование", а с фантазией у нас не очень, то можно обойтись одним именем "а", и сделать вот так:
И если в вашем мозговыносящем примере, слегка поднапрягшись, таки ещё можно сказать о результате выполнения кода, то в данном случае, глядя на код, уже невозможно наверняка утверждать, какой получится результат, не запустив его. Конечно, статический анализатор вывалит кучу предупреждений, но формально этот код вполне себе валиден. По большому счёту при программировании на "потоках данных" переменные — вообще зло, они "разбивают" потоки данных и в этом смысле сродни оператору GoTo.
Я не являюсь профессиональным вирусологом или микробиологом, чтобы утверждать это наверняка, без сомнений, хотя я полюбопытствовал, даже скачав геном этого вируса и био софт и стараясь разобраться в статьях про белки и всё такое (в карантин было нечем заняться) но там требуется поднять довольно большой пласт знаний, а я физик по образованию. Для себя я сделал вывод, что эта штука похожа на маленького робота, в её устройстве в общем неплохо разобрались. Меня зацепили два факта - это началось очень резко, и хотя коронавирусы известны давно, но ярких вспышек там и сям я как-то не припомню, а они, вероятно, с постепенными мутациями, должны были предшествовать большой пандемии. Ну и помимо того, что это столь лавинообразно началось, так это случилось прямо возле биолаборатории, вот ведь как им с местом не повезло. А с летучими мышками-носителями заражёнными места там тоже есть, да, но вроде чуть отдалённее. Так что я за пробирку, хотя это просто моё ничем не подкреплённое субъективное мнение, которое тем не менее имею право высказать. Тесть мой, ещё не старый, этой штукой заразился - полторы недели в реанимации и нет его.
у людей, у которых хватает интеллекта чтобы работать в 1 из 2 лабораторий в мире и собрать вирус по техзаданию, не хватает интеллекта, чтобы отъехать в другой населённый пункт дабы поселить его in vivo.
Я считаю, что кто-то просто грохнул пробирку по неосторожности, не соблюдая ТБ, потом сходил на рынок купить покушать и приехали. Но истины мы скорее всего уже не узнаем.
Спасибо! У меня, правда есть некоторые специфические требования, типа проекты с идентификаторами и "активность" (так как я это в SAP потом забиваю), но это всё решаемо. Я сейчас просто в Excel учёт веду, и далеко не всё мне нравится.
У меня, читая это, сразу родился план тайм трекера. Надо будет попробовать, там допилить всего ничего. Тайм трекеров куча, в том числе для Обсидиана, но что-то в этом подходе есть.
А в каких сценариях реального использования может пригодится такой функционал?
Как пример — предположим у меня есть ПЛК, наружу из него торчит Modbus TCP, и я разрабатываю десктопное приложение, которое с ним общается. Держать ПЛК на столе неудобно, соответственно программа выступает "заглушкой", к которой я и подсоединяюсь вместо настоящей железки. Ну и когда я что-то пишу, то сразу вижу чего и в какой регистр записалось (на самом ПЛК это смотреть опять же не всегда удобно), ну и вручную могу какие-то регистры установить и их читать. Логики там не надо, просто статические регистры. Этакий примитивный "эмулятор". Ещё вот был случай, когда соединение разрывалось по таймауту, и чтобы определить, какая сторона "глючит", такая "независимая" программа была бы кстати.
В принципе, конечно, разные, хотя это не мешает и их сравнивать. Modbus с Profibus тоже в общем сравниваются с некоторой натяжкой. Я просто общий тренд в промышленной автоматизации имел ввиду.
Мне в LabVIEW комменты нравятся, поскольку это графическое программирование, то и комменты можно картинками разбавлять (кстати, удобно, когда формулы и графики), но там также и анимированные гифки можно вставлять (они при компиляции удаляются).
Profibus обеспечивает более скоростную связь, чем Modbus.
К этой фразе можно придраться, тем более вы сами ниже про Modbus пишете, что "До 19,2 Кбит/с в последовательном режиме, выше в TCP/IP". В теории фреймы Modbus можно и через гигабитную сетку гонять, лишь бы устройства с обеих сторон поддерживали.
Вообще я в данный момент наблюдаю массовый переход на Profinet и OPC UA, уже много лет ни в одной новой системе мы что Profibus, что Modbus не использовали.
Муж моей двоюродной сестры смог за короткий срок (для Германии) зарегистрировать фирму, без которой мы не имели бы право стартовать.
Любопытно, а просто зарегистрироваться как Selbständig (что занимает 20 минут в Ратуше и 20 евро) было в данном случае недостаточно (теоретически ведь могло бы прокатить из разряда "Freie Berufe" со всякими wissenschaftliche бла бла бла) или нет?
Я не из радиологии, но из радиографии, причём промышленной. По существу вопроса имею сказать следующее — на волне хайпа в ИИ многие производители промышленного оборудования утверждают "да у нас тут ИИ в полный рост". На поверку же оказывается мягко говоря не совсем так. Типичный пример — батареи для электромобилей/планшетов/смартфонов, их сейчас иногда проверяют рентгеном, делая томографию (частичную или полную), и проверяют геометрию катодов и анодов с точки зрения перехлёста, деформации и т.п. Так вот когда начинаешь дотошно выяснять — тут оказывается Canny, там Sobel, а потом классическая аналитическая геометрия и ни намёка на машинное обучение. Очевидно, что классическое ML тут задача нетривиальная, хотя бы в том, что батареи все разные, набрать хоть сколько-нибудь приемлемый по размеру сет для тренинга — непросто, просто нет столько дефектных. С дефектами литья тоже самое — в лучшем случае машинное обучение используется в небольшой части общего пайплайна обработки картинок (скажем в бинарной классификации), а большая часть процессинга — классика на модифицированных медианных фильтрах или около того. В медицине ситуация чуть проще в том, что все люди плюс-минус однаковы с точки зрения внутреннего устройства, а вот головка блока циилиндров несколько отличается от рычагов подвески, да и даже в пределах одного производителя конструктивные особенности и геометрия могут быть принципиально различны. На Kaggle, кстати, выкладывали много изображений поражения лёгких при Covid, и там методы машинного обучения вполне себе успешно использовались, хотя о практическом применении я честно не слышал, хотя статей типа Hospital-wide survey of clinical experience with artificial intelligence applied to daily chest radiographs встречал довольно много (но это опять же не моя область). Технически там обычно на DICOM всё нанизано, и воткнуться в цепь обработки можно, но нужно ещё передать результаты дальше, в какие-то теги это записать, конечное ПО (которое ещё надо сертифицировать) должно всё это поддерживать и т.д. В промышленности мы DICONDE используем, что в общем тоже самое, только вид сбоку. Но факт в том, что от демки, открывающей dcm файл и показывающей результат, до интегрированного решения — как от земли до неба (хотя тут скорее просто рутинное программирование). Ещё есть чисто технические затыки. Вот прямо сейчас я неспешно сращиваю поиск дефектов с YOLO 8.1 (там ввели ориентированные регионы — это когда я не просто прямоугольник в ответ получаю, а повёрнутый), так вот, картинки-то у меня 16 бит, и YOLO банально их не понимает. И хотя в теории это можно допилить, на практике это непросто там кода дофига. Народ просил поддержку 16 бит в прошлом году, но пока висит статус "не планируется". Да даже и с разметкой датасета в YOLO 8.1 — информации ноль, в каком формате это подавать, есть примеры предобученных сеток, и они вполне себе успешно находят всякие объекты, но когда у вас есть просто набор 16 бит картинок, то от него до обученной функциональной сетки — очень большая дистанция. То есть ещё работать и работать. Но потенциал тут есть определённо. Уже есть довольно большие наборы данных, полученных на "классических" алгоритмах, хотя и тут в промышленности есть тонкость — эти данные не публичные, внутреннее устройство деталей — это закрытая интеллектуальная собственность. Пока что для предварительных "пристрелочных" упраженний я просто генерирую искуственные дефекты, слегка корёжа их морфологией, но через всё приходится продираться как через лесную чащу.
Детская кроватка напомнила мне историю десятилетней давности. Короче, когда дети подросли, им понадобились полноразмерные кровати, но ни одна из "готовых" типа Икеевских нам отчаянно не нравилась (хотелось из чистого массивного дерева, огороженную с трёх сторон с красивыми резными элементами и т.д.). Изготовление такой под заказ (а мы территориально в Германии) выливалось в четырёхзначную сумму, а нам их надо две. Короче, тёща нашла фирму в Карелии, там их сделали именно так, как нам хотелось, супруга с детишками слетала домой и вместо багажа назад привезла на самолёте две кровати в разобранном виде. Даже с учётом билетов и доплаты всё это обошлось в несколько раз дешевле. Зато дома теперь кровати "с историей", каких больше ни у кого тут нет. По качеству — практически без претензий, разве что крепёж я при сборке заменил на помощнее.
TIFF форматом мы тоже пользуемся, и в основном если нужно отдать данные заказчику, а формат DICONDE он по какой-то причине не хочет. PNG это "внутренний формат", дело в том, что картинки наши содержат калибровочную информацию, разметку и т.д., так в библиотеке это пара функций, вот этих — IMAQ Write Image And Vision Info File и IMAQ Read Image And Vision Info, но они только для PNG, для TIFF таких нет. Если же я буду использовать TIFF, то мне придётся всё тоже самое реализовать руками, либо с libtiff повозиться. Конкретный заказчик решил воспользоваться нашими внутренними данными в PNG для обучения ML модели (c обучением модели он, кстати, так и не справился, также как изначально не понял устройство PNG).
Ноутбук нужен только тем, кто с ним постоянно куда-то ходит. Всем остальным ноутбук не нужен.
Вы напрасно столь радикально, у меня на кухне ноутбук лежит для утреннего кофе (вот и сейчас я с него пишу). Но это рабочая станция 17 дюймов и весит под четыре кило. "Постоянно ходить" с ним мягко говоря не очень, а держать на кухонном подоконнике — норм, а вот десктоп на кухне мне точно не нужен. Однако в комнате у меня именно десктоп, причём самосборный в винтажном корпусе (ну нравится мне Dell XPS) и работа с ним доставляет мне эстетическое удовольствие.
У меня пара таких корпусов, так что один было не жалко пустить под апгрейд и вкорячить туда современную материнку, графику, i7, ssd и всё такое.
Ну в то время, когда я его покупал, это было единственное приемлемое по цене предложение за дуплекс принтер формата А3. А цветной лазерник такого формата стоил каких-то невменяемых денег. В принципе я им доволен, он неприхотливый, достаточно компактный и на хорошей бумаге очень прилично (для офисного принтера) печатает.
Это из разряда "как отъять максимально возможное количество денег у покупателя, притом так, чтобы он был свято уверен, что ему это выгодно".
Вот смотрите, у меня дома МФУ HP Office Jet 7720, куплен осенью 2019, ему почти пять лет (53 месяца, если быть точным). Отдал я за него 180 евро по какой-то акции-распродаже. Картриджи 953XL оригинальные нынче на амазоне стоят 180(!) евро. Я беру неоригинал за тридцать (он их вполне принимает после даунгрейда). Сейчас установлен пятый комплект картриджей, суммарно расходы 180+30*5 = 330 евро за пять лет. Отечатано на нём по счётчику 3718 листов, это в среднем 70 страниц в месяц. Мне предлагают план за 17 долларов, и это будет 17*53 = 901 доллар, почти втрое дороже. Кроме того, нагрузка у него очень неравномерная, он может пару-тройку месяцев вообще почти не использоваться, а может неделю интенсивно (в основном он нужен детям-гимназистам и супруге - она учитель рисования). Доставка картриджа на следующий рабочий день — вообще смешно, если надо что-то срочно напечатать, а у меня всегда лежит запасной.
Бывает, некоторым платят именно за количество строк кода. ;) В данном случае можно теоретически даже как-то так уплотнить:
void Walls(){
SetColor(Blue , Black);
for(int m = 6; m < 14; m++){SetXY(15,m);cout<<"*"; SetXY(30,m); cout<<"*";}
for(int m = 15; m < 31;m++){SetXY(m,5); cout<<"*"; SetXY(m,14); cout<<"*";}
}
Но обычно в любой более-менее приличной компании у команды есть сложившиеся гайдлайны на форматирование, надо просто им следовать.
Только я хотел написать, что бабочка - это насекомое, а не животное, а оказалось — таки да, animals.
Кстати, для того чтобы снабдить консольное приложение интерфейсом, можно Nuklear воспользоваться. Это очень лекговесная и простая штука, но там можно много чего сделать.
Монорепозиторий - это в том числе про управление зависимостями. Насколько он применим - зависит в общем от структуры проектов. Я использовал такой подход ещё с конца девяностых, где-то до 2007 года. Тогда мы хранили код, используя Microsoft Visual SourceSafe, была такая штука (ни TFS ни Git в то время не было, они где-то в 2005 появились). Так вот в SourceSafe была такая фишка, которая называлась "Линки". У меня проекты были основаны на плагин-архитектуре. В монорепозитории эти плагины хранились все скопом, а вот для каждого отдельного проекта заводилась виртуальная папка, куда необходимые модули линковались из монорепозитория. Если там были файлы, специфические для конкретного проекта, то в монорепозиторий они не попадали. Это было очень удобно. Я мог посмотреть как историю по отдельным проектам, так и по монорепозиторию целиком. Когда я забирал из репозитория код проекта, то на диске у меня появлялиь лишь файлы, исполользованные в проекте и ничего лишнего. Важно было то, что отдельные модули были вообще никак не связаны, технически все вызовы отправлялись в микроядро, а межмодульные вызовы были строго запрещены. Общались модули между собой, устанавливая соединение в рантайме через именованные очереди. Модулей было около трёхсот, а проектов -где-то полтора десятка, какой-то проект мого использовать 50-70 модулей, а какой-то - 20-30, из из модулей проекты собирались как из кубиков Лего. Ну и когда добавлялся новый функционал, то это само собой автоматом распространялось на все проекты, в которых этот модуль использовался. Всё бы ничего, но MS VSS проект был закрыт, на смену пришёл TFS. И компания решила напрочь выпилить линки, потому что мало кто их использовал и вообще это "плохая практика". Это действительно может быть плохой практикой, устроив ад из зависимостей, но при слабой связанности - было самое то. Короче, была куча дискуссий, и в ответ производитель TFS лишь писал - ну нет проблем, сделайте линки на вашем диске, на клиентской стороне. Так можно, конечно, но это абсолютно неудобно. Мы перебросили код в TFS и как-то выкрутились, но линки жаль, у меня теперь весь монорепозиторий валяется на диске и при работе с конкретными проектами я постоянно натыкаюсь на "ненужные" мне в данный момент артефакты. Конкретно сейчас мы переезжаем с TFS в Git, надо будет разобраться, как там.
Ещё в качестве примера программирования без переменных можно привести графическое программирование, основанное на парадигме потоков данных (Data Flow).
Предположим я хочу вычислить (x+y)*z. Можно сделать вот так, заведя переменные (так обычно не делают, но тем не менее), в LabVIEW вот так:
Но можно выкинуть все переменные, оставив лишь потоки данных (так обычно и делают)
Ну и поскольку имена переменных имеют лишь номинальное значение, а мы всё равно в хабе "ненормальное програмирование", а с фантазией у нас не очень, то можно обойтись одним именем "а", и сделать вот так:
И если в вашем мозговыносящем примере, слегка поднапрягшись, таки ещё можно сказать о результате выполнения кода, то в данном случае, глядя на код, уже невозможно наверняка утверждать, какой получится результат, не запустив его. Конечно, статический анализатор вывалит кучу предупреждений, но формально этот код вполне себе валиден. По большому счёту при программировании на "потоках данных" переменные — вообще зло, они "разбивают" потоки данных и в этом смысле сродни оператору GoTo.
Я не являюсь профессиональным вирусологом или микробиологом, чтобы утверждать это наверняка, без сомнений, хотя я полюбопытствовал, даже скачав геном этого вируса и био софт и стараясь разобраться в статьях про белки и всё такое (в карантин было нечем заняться) но там требуется поднять довольно большой пласт знаний, а я физик по образованию. Для себя я сделал вывод, что эта штука похожа на маленького робота, в её устройстве в общем неплохо разобрались. Меня зацепили два факта - это началось очень резко, и хотя коронавирусы известны давно, но ярких вспышек там и сям я как-то не припомню, а они, вероятно, с постепенными мутациями, должны были предшествовать большой пандемии. Ну и помимо того, что это столь лавинообразно началось, так это случилось прямо возле биолаборатории, вот ведь как им с местом не повезло. А с летучими мышками-носителями заражёнными места там тоже есть, да, но вроде чуть отдалённее. Так что я за пробирку, хотя это просто моё ничем не подкреплённое субъективное мнение, которое тем не менее имею право высказать. Тесть мой, ещё не старый, этой штукой заразился - полторы недели в реанимации и нет его.
Я считаю, что кто-то просто грохнул пробирку по неосторожности, не соблюдая ТБ, потом сходил на рынок купить покушать и приехали. Но истины мы скорее всего уже не узнаем.
Спасибо! У меня, правда есть некоторые специфические требования, типа проекты с идентификаторами и "активность" (так как я это в SAP потом забиваю), но это всё решаемо. Я сейчас просто в Excel учёт веду, и далеко не всё мне нравится.
У меня, читая это, сразу родился план тайм трекера. Надо будет попробовать, там допилить всего ничего. Тайм трекеров куча, в том числе для Обсидиана, но что-то в этом подходе есть.
Как пример — предположим у меня есть ПЛК, наружу из него торчит Modbus TCP, и я разрабатываю десктопное приложение, которое с ним общается. Держать ПЛК на столе неудобно, соответственно программа выступает "заглушкой", к которой я и подсоединяюсь вместо настоящей железки. Ну и когда я что-то пишу, то сразу вижу чего и в какой регистр записалось (на самом ПЛК это смотреть опять же не всегда удобно), ну и вручную могу какие-то регистры установить и их читать. Логики там не надо, просто статические регистры. Этакий примитивный "эмулятор". Ещё вот был случай, когда соединение разрывалось по таймауту, и чтобы определить, какая сторона "глючит", такая "независимая" программа была бы кстати.
В принципе, конечно, разные, хотя это не мешает и их сравнивать. Modbus с Profibus тоже в общем сравниваются с некоторой натяжкой. Я просто общий тренд в промышленной автоматизации имел ввиду.
Навскидку проверил с библиотекой NI Modbus, и оно работает, спасибо!
А сервером (в смысле слейвом) ваша программа может выступать? Ну чтобы она просто слушала 502-й порт, а я бы к ней подключился?
Мне в LabVIEW комменты нравятся, поскольку это графическое программирование, то и комменты можно картинками разбавлять (кстати, удобно, когда формулы и графики), но там также и анимированные гифки можно вставлять (они при компиляции удаляются).
Баг как есть:
К этой фразе можно придраться, тем более вы сами ниже про Modbus пишете, что "До 19,2 Кбит/с в последовательном режиме, выше в TCP/IP". В теории фреймы Modbus можно и через гигабитную сетку гонять, лишь бы устройства с обеих сторон поддерживали.
Вообще я в данный момент наблюдаю массовый переход на Profinet и OPC UA, уже много лет ни в одной новой системе мы что Profibus, что Modbus не использовали.
Любопытно, а просто зарегистрироваться как Selbständig (что занимает 20 минут в Ратуше и 20 евро) было в данном случае недостаточно (теоретически ведь могло бы прокатить из разряда "Freie Berufe" со всякими wissenschaftliche бла бла бла) или нет?
Я не из радиологии, но из радиографии, причём промышленной. По существу вопроса имею сказать следующее — на волне хайпа в ИИ многие производители промышленного оборудования утверждают "да у нас тут ИИ в полный рост". На поверку же оказывается мягко говоря не совсем так. Типичный пример — батареи для электромобилей/планшетов/смартфонов, их сейчас иногда проверяют рентгеном, делая томографию (частичную или полную), и проверяют геометрию катодов и анодов с точки зрения перехлёста, деформации и т.п. Так вот когда начинаешь дотошно выяснять — тут оказывается Canny, там Sobel, а потом классическая аналитическая геометрия и ни намёка на машинное обучение. Очевидно, что классическое ML тут задача нетривиальная, хотя бы в том, что батареи все разные, набрать хоть сколько-нибудь приемлемый по размеру сет для тренинга — непросто, просто нет столько дефектных. С дефектами литья тоже самое — в лучшем случае машинное обучение используется в небольшой части общего пайплайна обработки картинок (скажем в бинарной классификации), а большая часть процессинга — классика на модифицированных медианных фильтрах или около того. В медицине ситуация чуть проще в том, что все люди плюс-минус однаковы с точки зрения внутреннего устройства, а вот головка блока циилиндров несколько отличается от рычагов подвески, да и даже в пределах одного производителя конструктивные особенности и геометрия могут быть принципиально различны. На Kaggle, кстати, выкладывали много изображений поражения лёгких при Covid, и там методы машинного обучения вполне себе успешно использовались, хотя о практическом применении я честно не слышал, хотя статей типа Hospital-wide survey of clinical experience with artificial intelligence applied to daily chest radiographs встречал довольно много (но это опять же не моя область). Технически там обычно на DICOM всё нанизано, и воткнуться в цепь обработки можно, но нужно ещё передать результаты дальше, в какие-то теги это записать, конечное ПО (которое ещё надо сертифицировать) должно всё это поддерживать и т.д. В промышленности мы DICONDE используем, что в общем тоже самое, только вид сбоку. Но факт в том, что от демки, открывающей dcm файл и показывающей результат, до интегрированного решения — как от земли до неба (хотя тут скорее просто рутинное программирование). Ещё есть чисто технические затыки. Вот прямо сейчас я неспешно сращиваю поиск дефектов с YOLO 8.1 (там ввели ориентированные регионы — это когда я не просто прямоугольник в ответ получаю, а повёрнутый), так вот, картинки-то у меня 16 бит, и YOLO банально их не понимает. И хотя в теории это можно допилить, на практике это непросто там кода дофига. Народ просил поддержку 16 бит в прошлом году, но пока висит статус "не планируется". Да даже и с разметкой датасета в YOLO 8.1 — информации ноль, в каком формате это подавать, есть примеры предобученных сеток, и они вполне себе успешно находят всякие объекты, но когда у вас есть просто набор 16 бит картинок, то от него до обученной функциональной сетки — очень большая дистанция. То есть ещё работать и работать. Но потенциал тут есть определённо. Уже есть довольно большие наборы данных, полученных на "классических" алгоритмах, хотя и тут в промышленности есть тонкость — эти данные не публичные, внутреннее устройство деталей — это закрытая интеллектуальная собственность. Пока что для предварительных "пристрелочных" упраженний я просто генерирую искуственные дефекты, слегка корёжа их морфологией, но через всё приходится продираться как через лесную чащу.
Детская кроватка напомнила мне историю десятилетней давности. Короче, когда дети подросли, им понадобились полноразмерные кровати, но ни одна из "готовых" типа Икеевских нам отчаянно не нравилась (хотелось из чистого массивного дерева, огороженную с трёх сторон с красивыми резными элементами и т.д.). Изготовление такой под заказ (а мы территориально в Германии) выливалось в четырёхзначную сумму, а нам их надо две. Короче, тёща нашла фирму в Карелии, там их сделали именно так, как нам хотелось, супруга с детишками слетала домой и вместо багажа назад привезла на самолёте две кровати в разобранном виде. Даже с учётом билетов и доплаты всё это обошлось в несколько раз дешевле. Зато дома теперь кровати "с историей", каких больше ни у кого тут нет. По качеству — практически без претензий, разве что крепёж я при сборке заменил на помощнее.
TIFF форматом мы тоже пользуемся, и в основном если нужно отдать данные заказчику, а формат DICONDE он по какой-то причине не хочет. PNG это "внутренний формат", дело в том, что картинки наши содержат калибровочную информацию, разметку и т.д., так в библиотеке это пара функций, вот этих — IMAQ Write Image And Vision Info File и IMAQ Read Image And Vision Info, но они только для PNG, для TIFF таких нет. Если же я буду использовать TIFF, то мне придётся всё тоже самое реализовать руками, либо с libtiff повозиться. Конкретный заказчик решил воспользоваться нашими внутренними данными в PNG для обучения ML модели (c обучением модели он, кстати, так и не справился, также как изначально не понял устройство PNG).
Вы напрасно столь радикально, у меня на кухне ноутбук лежит для утреннего кофе (вот и сейчас я с него пишу). Но это рабочая станция 17 дюймов и весит под четыре кило. "Постоянно ходить" с ним мягко говоря не очень, а держать на кухонном подоконнике — норм, а вот десктоп на кухне мне точно не нужен. Однако в комнате у меня именно десктоп, причём самосборный в винтажном корпусе (ну нравится мне Dell XPS) и работа с ним доставляет мне эстетическое удовольствие.
У меня пара таких корпусов, так что один было не жалко пустить под апгрейд и вкорячить туда современную материнку, графику, i7, ssd и всё такое.