Если пыль протрут это еще неплохо. Наши сервисмены лишь бы не пытались что-то более существенное сделать. У нас на отделении как ТО пройдет раз в 2 недели, так хожу за ними все восстанавливаю. Как будто они и оборудование это никогда не видели. А нейросеть сейчас просто в моде и деньги на них дают. Вот и разрабатывают что попало. Пока де юре отвественность несет врач, никакая нейросеть в медицинской визуализации нафиг не нужна. Пустая трата времени персонала на пересмотр и бюджетных денег даже в сегменте профилактических исследований, где бы это теоретически могло помочь. Это хорошо еще, есди не придется с десяток операторов нанять чтоб они ей картинки скармливали по одной.
На русский перевести, то никакого требования нет. Это только cd касается. А dicom это далеко не только cd. Часто включаются, а могут и не включаться. И это не обязательно. Сейчас вообще все просто ссылку делают. WADO рулит. Про сырые данные пишу практически, потому на выходе из аппарата они действительно могут быть, на диск их могут записать, так как места не жалко. Но при хранении их пакс сам все равно дожмет, если ему это не запретить делать. Кстати далеко не каждый просмотровщик с raw работает.
Тут и сравнение-то в целом так себе у автора. Если по пунктам:
У dicom больше метаданных. Как сравнили? Да он вообще может почти не содержать метаданных. Sop класс должен быть - наверно это единственный атрибут который должен быть. Еще добавить имя пациента и наверное уже корректный файл сформируется. Там обязательных атрибутов не так-то и много. А если говорить о dicom как протоколе, то он совершенно точно может состоять всего из 2х атрибутов, например запрос mwl.
Размер файла - вообще необъективно. Зависит только от способа компрессии картинки. Если только в NifTi они не векторные, в чем я сильно сомневаюсь.
В dicom можно хранить больше информации. Ну может и можно. С NifTi особо не знаком, но в dicom можно хранить много. Его размер в принципе только файловой системой ограничен.
Dicom двухмерный? Ну и чего? Из них нормально 3х мерные mip-ы строятся да еще и с движением. Нет проблем. Исходные данные даже с томографов все равно 2-х мерные. Кстати, правило рентгенологии - можешь 3д картикни строить, но заключение основывается всегда на 2х мерных исходных данных. Для КТ это только аксиальные срезы, для МРТ могут быть разные.
Dicom быстрее загружается. Ну совсем ни о чем. Это от железа и софта зависит. Загрузите МРТ сердца с перфузией ну к примеру на 4 пне и на i7 и на разных просмотровщиках.
Вообще рука - лицо. Да я музыку могу в dicom преобразовать или сериальчик какой. Нет проблем.
В DICOM точно нет. Но можно реализовать самому, если надо. Типа хэш картинки рассчитать и хранить в кастомном атрибуте(тэге) и проверять. Но по-моему никто этого не делает.
В DICOM сжатие используется повсеместно, обычно это jpeg без потерь. Хотя бывают и другие варианты. Сырые данные в нем не хранятся почти никогда. А если такое случается, то многие pacs-ы дожимают их в jpeg спустя какое-то время в целях экономии места. Как рентгенолог скажу, что jpeg без потерь и даже с потерями 10-20% на глаз не отличить от исходных даже на специальзированных 5 мегапиксельных мониторах.
У DICOM нет никаких требований по распространению с софтом. Софта может не быть. Его полно отрытого. Мало того, DICOM может и файлом вовсе не быть, а лишь протоколом поверх http имеющим иерархическую структуру.
Если пыль протрут это еще неплохо. Наши сервисмены лишь бы не пытались что-то более существенное сделать. У нас на отделении как ТО пройдет раз в 2 недели, так хожу за ними все восстанавливаю. Как будто они и оборудование это никогда не видели. А нейросеть сейчас просто в моде и деньги на них дают. Вот и разрабатывают что попало. Пока де юре отвественность несет врач, никакая нейросеть в медицинской визуализации нафиг не нужна. Пустая трата времени персонала на пересмотр и бюджетных денег даже в сегменте профилактических исследований, где бы это теоретически могло помочь. Это хорошо еще, есди не придется с десяток операторов нанять чтоб они ей картинки скармливали по одной.
На русский перевести, то никакого требования нет. Это только cd касается. А dicom это далеко не только cd. Часто включаются, а могут и не включаться. И это не обязательно. Сейчас вообще все просто ссылку делают. WADO рулит. Про сырые данные пишу практически, потому на выходе из аппарата они действительно могут быть, на диск их могут записать, так как места не жалко. Но при хранении их пакс сам все равно дожмет, если ему это не запретить делать. Кстати далеко не каждый просмотровщик с raw работает.
Тут и сравнение-то в целом так себе у автора. Если по пунктам:
У dicom больше метаданных. Как сравнили? Да он вообще может почти не содержать метаданных. Sop класс должен быть - наверно это единственный атрибут который должен быть. Еще добавить имя пациента и наверное уже корректный файл сформируется. Там обязательных атрибутов не так-то и много. А если говорить о dicom как протоколе, то он совершенно точно может состоять всего из 2х атрибутов, например запрос mwl.
Размер файла - вообще необъективно. Зависит только от способа компрессии картинки. Если только в NifTi они не векторные, в чем я сильно сомневаюсь.
В dicom можно хранить больше информации. Ну может и можно. С NifTi особо не знаком, но в dicom можно хранить много. Его размер в принципе только файловой системой ограничен.
Dicom двухмерный? Ну и чего? Из них нормально 3х мерные mip-ы строятся да еще и с движением. Нет проблем. Исходные данные даже с томографов все равно 2-х мерные. Кстати, правило рентгенологии - можешь 3д картикни строить, но заключение основывается всегда на 2х мерных исходных данных. Для КТ это только аксиальные срезы, для МРТ могут быть разные.
Dicom быстрее загружается. Ну совсем ни о чем. Это от железа и софта зависит. Загрузите МРТ сердца с перфузией ну к примеру на 4 пне и на i7 и на разных просмотровщиках.
Вообще рука - лицо. Да я музыку могу в dicom преобразовать или сериальчик какой. Нет проблем.
В DICOM точно нет. Но можно реализовать самому, если надо. Типа хэш картинки рассчитать и хранить в кастомном атрибуте(тэге) и проверять. Но по-моему никто этого не делает.
В DICOM сжатие используется повсеместно, обычно это jpeg без потерь. Хотя бывают и другие варианты. Сырые данные в нем не хранятся почти никогда. А если такое случается, то многие pacs-ы дожимают их в jpeg спустя какое-то время в целях экономии места. Как рентгенолог скажу, что jpeg без потерь и даже с потерями 10-20% на глаз не отличить от исходных даже на специальзированных 5 мегапиксельных мониторах.
У DICOM нет никаких требований по распространению с софтом. Софта может не быть. Его полно отрытого. Мало того, DICOM может и файлом вовсе не быть, а лишь протоколом поверх http имеющим иерархическую структуру.