[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]



  • Страница 5 из 5
  • «
  • 1
  • 2
  • 3
  • 4
  • 5
Модератор форума: STaras, GeorgySmith  
DICOM сервер "своими руками"
KuzmaДата: Пятница, 12.Янв.2024, 10:23 | Сообщение # 161
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Цитата Hooligan666 ()
перенести как-то можно, есть варианты?
Цитата Hooligan666 ()
В самых "плохих" случаях приходится файл базы грохнуть и реинициилизировать

Да, тот же "плохой" случай :)
Только перед реинициализацией установить MySQL и в конквесте выбрать её.
Т.н. "реинициализация" на самом деле - просто сканирование каталогов с исследованиями и занесение в БД информации из тегов dicom.
Поэтому, если структура каталогов почему-то была нарушена, или файлы были перемещены, то "запихнуть" их обратно в БД можно просто отправив на сервер какой-нибудь программой экспорта, например, этой: https://telepacs.com.ua/?p=775
 
BomberbugДата: Суббота, 20.Янв.2024, 09:22 | Сообщение # 162
У вас сообщений: 711
engineer
OFFлайн
Российская Федерация

Россия
Цитата Kuzma ()
Поэтому, если структура каталогов почему-то была нарушена ...

Вы всё усложняете ...
На самом деле, чем примечателен Conquest, в любой ситуации, когда файлы с данными каком-то образом "перемешиваются" и получается куча-мала, достаточно просто в папку INCOMING их подсунуть и сам Conquest их заново добавит в базу себе, и заново рассортирует по заданному шаблону (лично я не использую стандартный, всего делаю по дате "раскладывание").

А относительно MySQL - из личного этого тоже шляпа, при всякого рода сбоях слетает и заново ребилд базы ...

Рекомендую полноценный MSSQL, версия на выбор, у меня, вроде, 2014. Добавляете ключ в него (чтобы ограничение снять на количество записей), его "прицепить" к Conquest и уже потом через INCOMING "скормить" Ваши dicom-файлы (перед этим шаблон создания структуры папок удобный сделав).

По личному опыту - MSSSQL тяжело "завалить".
А вот MySQL - как нефиг делать (во всяком случае, у меня с ним так, для больших объёмов, как по мне, он не годится).

Единственное, придется помучаться с тем, чтобы "подружить" MSSQL с Conquest!- если опыта такого не было.
 
KuzmaДата: Суббота, 20.Янв.2024, 10:45 | Сообщение # 163
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Цитата Bomberbug ()
Рекомендую полноценный MSSQL

Во-первых, "полноценный" MSSQL - весьма недешёвый продукт.
Во-вторых, спор о том, какая из этих СУБД лучше, идёт всё время их существования. Поэтому считаю, что спорить на эту тему бесполезно. У каждого свои предпочтения.

Цитата Bomberbug ()
По личному опыту - MSSSQL тяжело "завалить" . А вот MySQL - как нефиг делать (во всяком случае, у меня с ним так, для больших объёмов, как по мне, он не годится).

Может это у Вас так? :) Или у меня просто к MSSQL предубеждение из-за "Microsoft" :)
Но я знаю много примеров, когда MySQL с Conquest работают безотказно годами и на виндовых системах, и на линуксовых.
 
BomberbugДата: Воскресенье, 21.Янв.2024, 18:50 | Сообщение # 164
У вас сообщений: 711
engineer
OFFлайн
Российская Федерация

Россия
Цитата Kuzma ()
весьма недешёвый продукт.

Ну, в текущих реалиях, когда всё импортное уже не п*изженное, а, как бы, трофейное - не актуально biggrin

Спора об относительности что лучше и не шло.
"Хозяин - барин", как говорится. Лишь делюсь своим личным опытом. У всех разные условия. В моих "разнородных" данных с разными узлами и модальностями - пробовал разное. MSSQL для больших объёмов лично для меня стал самым удачным.

Относительно Линуха не скажу - там не проверял.
А вот на Винде у меня на разных ПК именно встроенный MySQL работал не ахти ... Чуть где питание "рубануло" - усё, ошибки базы. Либо "подвисла" - аналогично. Не всегда, но очень часто, хз почему так.
С "полным" MSSQL - такой фигни пока вообще не было. Не знаю, может там какие механизмы "рекавери" волшебные, но работает безотказно.
 
navesДата: Среда, 28.Фев.2024, 12:12 | Сообщение # 165
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация

Москва
Цитата Bomberbug ()
Ну, в текущих реалиях, когда всё импортное уже не п*изженное, а, как бы, трофейное - не актуально

1) Даже в РФ это заблуждение, за которое скоро начнут всех нагибать заново. Да-да. Этот маленький нюансик скрывается от широких народных масс, ибо казна не бездонная.
2) Ваш собеседник не в дефолт-сити и не в дефолт-стране.

Цитата Bomberbug ()
А вот на Винде у меня на разных ПК именно встроенный MySQL работал не ахти ... Чуть где питание "рубануло" - усё, ошибки базы. Либо "подвисла" - аналогично. Не всегда, но очень часто, хз почему так.
С "полным" MSSQL - такой фигни пока вообще не было. Не знаю, может там какие механизмы "рекавери" волшебные, но работает безотказно.

Как говорится, это ошибка выжившего. Если отключить питание сервера, когда БД активно пишет на диск, любая БД уйдёт в recovery режим. Зависит от реализации каждой СУБД, у некоторых просто ругнется при запуске, некоторые уйдут в recovery. А некоторые молча запустятся, а потом в произвольные моменты времени софт не будет работать, потому что запросы отваливаются из-за битого индекса.
Я на форуме приводил примеры, где компы с БД на рентгенах выключались рубильниками, и как после этого приходилось чинить эти БД MS SQL странными командами и заменами файлов журналов.
 
BomberbugДата: Вторник, 05.Мар.2024, 17:10 | Сообщение # 166
У вас сообщений: 711
engineer
OFFлайн
Российская Федерация

Россия
Цитата naves ()
за которое скоро начнут всех нагибать заново

Если доживем :-)
Ну никто и не призывал использовать то, что бесплатно "не положено", каждый сам себе разумеет что и как сделать (и на чём).
То, что "по закону" для большинства бюджетников делается, чаще всего работает не так как задумывалось, ибо основная цель всё ж "карманы набить" (хоть это и красиво завуалировано под разные благие цели). Может, и в "резиновой" всё как-то неплохо, но вот чем дальше от центров - тем унылей (ну, может, кроме "денежных" областей).
А если по теме - "голь на выдумку хитра", каждый решает свои задачи как может с учётом своих собственных реалий.
 
Serg88Дата: Пятница, 24.Май.2024, 09:29 | Сообщение # 167
Стажер
У вас сообщений: 7
нет
OFFлайн
Украина

Киев
Здравствуйте.
Подскажите, пожалуйста, что делаю не правильно?
Пытаюсь поднять пакс CONQUEST на win10. Сначала установил MySQL сервер, затем запускаю CONQUEST, выбираю Native MySQL driver. Прописываю данные сервера и сохраняюсь. На вкладке Installation жму Make ODBC MySql создаю базу и выдаёт ошибку подключение к порту. Бывает что удаётся создать базу, но снимки не сохраняет.

.
Добрый день.
Никто не подскажет решение моей проблемы?

Сообщение отредактировал Serg88 - Среда, 29.Май.2024, 16:59
3458911.jpg (159.6 Kb) · 4218465.jpg (114.9 Kb) · 5168059.jpg (158.4 Kb)
 
KuzmaДата: Среда, 29.Май.2024, 16:30 | Сообщение # 168
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Мне кажется, или MySQL в логах Вам чётко говорит, что доступа к БД нет из-за не настроенного логина-пароля рута?
Установите и настройте MySQL правильно.
Или попробуйте сначала с SQLite.
 
Serg88Дата: Четверг, 30.Май.2024, 10:50 | Сообщение # 169
Стажер
У вас сообщений: 7
нет
OFFлайн
Украина

Киев
Благодарю за ответ.
Как видно на фото, я создал базу, но снимки так и не сохраняет.
Скажите, пожалуйста, в чём может быть причина?
2075710.jpg (60.4 Kb) · 7537622.jpg (158.4 Kb)
 
valentin17Дата: Четверг, 30.Май.2024, 12:35 | Сообщение # 170
Техник
У вас сообщений: 555
инженер
OFFлайн
Чешская Республика

Прага
Есть ошибка, не существует таблицы conquest1.dicomimages.
 
Serg88Дата: Четверг, 30.Май.2024, 13:15 | Сообщение # 171
Стажер
У вас сообщений: 7
нет
OFFлайн
Украина

Киев
Выходит, что CONQUEST не создает базу с таблицей при нажатии кнопки  Make ODBC MySql.
Нужно создать в ручную, через консоль?
 
KuzmaДата: Четверг, 30.Май.2024, 17:24 | Сообщение # 172
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Посмотрите опять же права на запись в СУБД.

Сообщение отредактировал Kuzma - Четверг, 30.Май.2024, 17:28
 
navesДата: Воскресенье, 02.Июн.2024, 22:24 | Сообщение # 173
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация

Москва
Там какой-то был не совсем интуитивный порядок нажимания кнопок для создания БД
https://www.medteh.info/forum/57-4668-151684-16-1415891983
Цитата
на вкладке installation сделать
make ODBC and database
initialialize db
на вкладке browse database должен появиться тестовый снимок головы.

Как будто не было именно сделано
initialialize db


Сообщение отредактировал naves - Воскресенье, 02.Июн.2024, 22:26
 
KuzmaДата: Среда, 05.Июн.2024, 11:41 | Сообщение # 174
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Цитата naves ()
Там какой-то был не совсем интуитивный порядок нажимания кнопок для создания БД

Порядок нажатия кнопок: Save configuration, Make ODBC data source, (Re)-initialize database

Решил помочь решить проблему Serg88 и попробовал её воспроизвести.
И да, она воспроизводится с Оракловской MySQL и 5-й и 8-й версии. Причина так мне и не стала понятной.
Затем ставлю MariaDB - всё работает с пол-пинка.
Но проблема с кириллицей что в 144-й, что в 192-й кодировке. Виндовая кодировка - пожалуйста, без проблем. По-моему она уже поднималась неоднократно, где-то что-то нужно в ини-файлах править. Не стал заморачиваться.
И да, на картинке при установке СУБД не стоит галка на UTF-8, но я испробовал и такой вариант, и с установленной. Картинку не сделал только. Что так, что эдак - кириллицы нет.
Последней каплей, убедившей, что все-равно я не буду ставить этот сервер, стало то что он принимает и отдает исследования ПО ЛЮБОМУ AeTitle. Главное адрес и порт указать, а там что CONQUESTSRV1, что CONQUEST или вообще CON - по барабану.
Раньше как-то не обращал внимание на это, точнее в голову не могло прийти такое проверять, а тут случайно обнаружил. Полез на старую установку с 1.4.17 - ТОЖЕ САМОЕ. Чё-то вообще ничего не понял, как такое может быть.
Может кто-то подскажет, что не так? Что с кириллицей, напомните?
Вот вся история в картинках:
7400171.png (42.9 Kb) · 6644382.png (129.5 Kb) · 9566804.png (165.6 Kb) · 5356459.png (169.3 Kb) · 9806115.png (195.9 Kb) · 5056562.png (296.8 Kb)


Сообщение отредактировал Kuzma - Среда, 05.Июн.2024, 11:53
 
KuzmaДата: Среда, 05.Июн.2024, 11:45 | Сообщение # 175
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Продолжение. Не даёт больше картинок подключить.

Особенно доставило именно безразличие к Ает. Как так может быть? И разве так было в более ранних версиях?

Желание проводить дальнейшие танцы с бубном отпало.
8973469.png (196.1 Kb) · 5950072.png (528.4 Kb) · 0094057.png (48.8 Kb) · 6325110.png (48.2 Kb)


Сообщение отредактировал Kuzma - Среда, 05.Июн.2024, 11:49
 
Serg88Дата: Среда, 05.Июн.2024, 17:13 | Сообщение # 176
Стажер
У вас сообщений: 7
нет
OFFлайн
Украина

Киев
Добрый день.
Спасибо Вам огромное Kuzma за проведённую роботу.
Ещё немного "поиграюсь" с sql, если не получится, то поставлю как Вы MariaDB.
Благодарю за помочь!
 
KuzmaДата: Среда, 05.Июн.2024, 17:27 | Сообщение # 177
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Мне всё равно непонятно, что за хрень с AeTitle сервера. У вас тоже так? Тоже можно на любой отправлять?
Кто-то что-то может сказать?
Или это у меня только такое волшебство? :): ) :)
 
navesДата: Пятница, 07.Июн.2024, 13:48 | Сообщение # 178
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация

Москва
Цитата
И да, она воспроизводится с Оракловской MySQL и 5-й и 8-й версии. Причина так мне и не стала понятной.
Затем ставлю MariaDB - всё работает с пол-пинка.

Странная фигня, я думаю, что-то поменяли в дистрибутиве MySQL за 10 лет, изменилось поведение.

Цитата
Мне всё равно непонятно, что за хрень с AeTitle сервера. У Вас тоже так?
Тоже можно на любой отправлять?

Есть подозрение, что такая работа AeTitle это не баг, а фича. Для работы виртуальных серверов и export/import конвертеров.
Просмотрел код
https://github.com/marcelv....ate.cpp
Как будто в явном виде нигде нет проверки на Called AE.

Кому не нравится может написать свой lua-обработчик, который может обрабатывать любые правила доступа)
это opensource, тут никто никому ничего бесплатно не обязан).

Мой тезис такой, Conquest удобен для вкатывания здесь и сейчас за 10 минут, бесплатно и без СМС.
Для решения проблем кодировок есть бесплатные напильники. Или платные.

Я вообще открывал багу, что после установки Conquest сервер не принимает compression JPEG. Всю голову сломал, ну не может быть такого, оказалось это баг в GUI-конфигураторе, который срабатывает только при первом запуске, и который, видимо, никто не замечал 10 лет. Вроде поправили после репорта.


Сообщение отредактировал naves - Пятница, 07.Июн.2024, 13:50
 
KuzmaДата: Понедельник, 10.Июн.2024, 20:29 | Сообщение # 179
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Цитата naves ()
Conquest удобен для вкатывания здесь и сейчас за 10 минут, бесплатно и без СМС.

Согласен

Цитата naves ()
Для решения проблем кодировок есть бесплатные напильники. Или платные.

Но тезис про напильники противоречит тезису про здесь и сейчас за 10 минут

Цитата naves ()
такая работа AeTitle это не баг, а фича.

Это баг, как ни крути.
В любом букваре пишут, что у PACS-а должен быть AeTitle.
 
KuzmaДата: Понедельник, 14.Окт.2024, 19:49 | Сообщение # 180
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Цитата naves ()
Для решения проблем кодировок есть бесплатные напильники. Или платные.

Ткните, пожалуйста, на какое-нибудь решение с кодировкой кириллицы в конквесте.
Нужно протестировать клиента для чтения с такого сервера. Всё работает, кроме того, что конквест отдаёт хрень вместо букв. Кодировка ISO_IR 192. Версия конквеста последняя, ОС - убунту 22.04
 
navesДата: Четверг, 17.Окт.2024, 11:28 | Сообщение # 181
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация

Москва
Цитата
как победить юникод в conquest
нужно прицепить триггер на таблицы, который будет конвертировать имя пациента из юникода в простую строку
для базы MSSQL
Код
CREATE FUNCTION [dbo].[UTF8_TO_NVARCHAR](@in VarChar(MAX))
RETURNS NVarChar(MAX)
AS
BEGIN
DECLARE @out NVarChar(MAX), @i int, @c int, @c2 int, @c3 int, @nc int

SELECT @i = 1, @out = ''

WHILE (@i <= Len(@in))
BEGIN
SET @c = Ascii(SubString(@in, @i, 1))

IF (@c < 128)
BEGIN
SET @nc = @c
SET @i = @i + 1
END
ELSE IF (@c > 191 AND @c < 224)
BEGIN
SET @c2 = Ascii(SubString(@in, @i + 1, 1))

SET @nc = (((@c & 31) * 64 /* << 6 */) | (@c2 & 63))
SET @i = @i + 2
END
ELSE
BEGIN
SET @c2 = Ascii(SubString(@in, @i + 1, 1))
SET @c3 = Ascii(SubString(@in, @i + 2, 1))

SET @nc = (((@c & 15) * 4096 /* << 12 */) | ((@c2 & 63) * 64 /* << 6 */) | (@c3 & 63))
SET @i = @i + 3
END

SET @out = @out + NChar(@nc)
END
RETURN @out
END

create trigger [dbo].[tIU_DICOMPatients] on [dbo].[DICOMPatients] for INSERT,UPDATE as
begin

if update(PatientNam)
update t set
PatientNam = dbo.UTF8_TO_NVARCHAR(i.PatientNam)
from inserted i, DICOMPatients t
where i.PatientNam like char(0xd0)+'_'+char(0xd0)+'%'
and t.PatientID = i.PatientID

end

go

create trigger [dbo].[tIU_DICOMStudies] on [dbo].[DICOMStudies] for INSERT,UPDATE as
begin

if update(PatientNam)
update t set
PatientNam = dbo.UTF8_TO_NVARCHAR(i.PatientNam)
from inserted i, DICOMStudies t
where i.PatientNam like char(0xd0)+'_'+char(0xd0)+'%'
and t.StudyInsta = i.StudyInsta

end

осталось портировать код для postgre и mysql

В самих DICOM-файлах теги соответственно не меняются, и если клиент не понимает юникод, то будет выглядеть странно.

Ну тут несколько этапов:
1) конвертировать строки в самой БД;
2) добавить в сам conquest lua-скрипт, который будет переводить utf в другой формат.

Далее возникают нюансы: - как хранить строки в mysql, так приколы бд накладываются на всё остальное.
В бд несколько видов форматов, и я уже не помню какой правильный, но не тот который с интуитивным названием unicode.

Далее варианты:
1) просто перекодировать бд простым update не трогая файлы.
Результат: - будет работать список снимков при поиске, а вот конечное отображение снимка будет зависеть от конкретного просмотровщика. Понимает ли он юникод;

2) сделать ребилд файлов, в процессе которого луа-скрипт перекодирует всё;

3) открыть исходники conquest и наконец понять, что же там не так, что он не может юникод положить в юникод базу и отдать юникод строку.

В целом, это примерные варианты бесплатных напильников, пиля которыми мы потратим своё платное время.

Ещё проблема была, когда к одному серверу подключено несколько приборов с разными кодировками.
Если все приборы строго юникод, то, наверно, это проще решить.
Но там опять проблема: почему просмотровщики не понимают юникод строку.
Надо разобраться, как записывается в БД и как эта строка передаётся клиенту.
Т.е. ковырять tcpdump-ы и всё такое.

Например, тот же еFilm одной и той же версии на одном компе нормально показывает, а на другом нет.
А другая версия, более новая, вообще нигде не работает.
Innobitec какой-то версии нормально показывает список пациентов в поиске в юникоде.
А когда открывает сам снимок, всё превращается в кракозябры.


Сообщение отредактировал naves - Четверг, 17.Окт.2024, 11:36
 
KuzmaДата: Пятница, 18.Окт.2024, 16:06 | Сообщение # 182
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Огромное спасибо за подробный ответ.
Ещё раз убедился, что conquest только на первый взгляд лёгок и прост в установке и настройке. И ситуация не меняется годами. Одни и те же вопросы в форуме разработчиков.
Нужно было потестить своё веб-приложение с conquest, т.к. потенциальный заказчик уже имеет такие серверы.
Программа использует библиотеку fo-dicom. С серверами dcm4chee-arc всё отлично получается.
Поставил последнюю версию conquest в убунту 22.04 в самом простом варианте с БД SQLite.
Сам процесс установки в общем не сложен. Копируй и вставляй в терминал команды из инструкции.
Запустился без проблем. Отправлять и запрашивать файлы можно только по адресу и порту (5678 по умолчанию), на AeTitle плевать, можно любой написать. Выше уже обсуждали эту хрень.
Отправил файлы, запрашиваю из программы - ожидаемая проблема с кириллицей. Кодировка - UTF-8 - ISO_IR 192.
Где-то на форуме отыскался такой рецепт: добавить в секцию [lua] ини-файла строку
QueryResultConverter0 = Data.SpecificCharacterSet = "ISO_IR 192"
Случилось чудо! C-FIND возвращает кириллицу корректно.
На этом чудеса закончились.
Такой же фокус с кодировкой ISO_IR 144 не прокатил.
Цитата naves ()
Ещё проблема была, когда к одному серверу подключено несколько приборов с разными кодировками.

С дцм4 вообще об этой проблеме не знал.

Ещё неожиданная проблема - ни oviyam, ни ohif не могут показать обычный текстовый SR SOPClassUID = "1.2.840.10008.5.1.4.1.1.88.11"
Проблема непонятная мне, но на форуме она известна. Много написано, много рецептов разных, но для себя решение я так и не нашёл, хотя оно должно же быть, наверное.
Сервер не может отдать простой текстовый файл в нормальном виде. Овиям по wado запросу показывает в одну неформатированную строчку все теги, их типы, значения. Хрен с ним, можно было бы смирится, и прищурившись :) найти нужное описание врача. Но картинка снимков при этом оказывается не вписанной в экран, а больше. Если её уменьшить, и попробовать изменить яркость, то она тут же снова увеличится.
Если использовать C-GET или C-MOVE, то картинки отображаются нормально, а SR - просто белый квадрат. С C-GET и C-MOVE понятно такое поведение. Картинку из дайкома вытаскивает сам овиям и вписывает в свое окно, а по Вадо картинка получается того размера, который дал сервер.
OHIF, который устанавливается с конквестом, по честному говорит сразу: SR не поддерживаю, не знаю, не могу. И не показывает вообще ничего.
Чтобы увидеть SR нужно подключать "настольный" вьювер.

Ещё боль.
Информационные модели запросов по сравнению с dcm4chee вообще просто убогие. Patient Root Query/Retrieve Information Model содержит аж 7 возвращаемых по запросу полей, 3 из которых вычисляемых.
Мне, например, нужно считать какую-то статистику по этническим группам, или по специальным потребностям, или по состоянию пациентов, но сервер просто не может их вернуть, потому что это не предусмотрено даже его Заявлением о соответствии стандарту DICOM.
Возможно это тоже как-то допиливается какими-нибудь напильниками?
Но не хочется тратить своё платное время :)
Вот это Ваше мне понравилось:
Цитата naves ()
В целом, это примерные варианты бесплатных напильников, пиля которыми мы потратим своё платное время.

С уважением!
 
navesДата: Пятница, 18.Окт.2024, 22:04 | Сообщение # 183
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация

Москва
Цитата
Такой же фокус с кодировкой ISO_IR 144 не прокатил.

Мысль пришла, а может её значение нужно брать из запроса клиента?
Но тогда все равно встанет проблема, что клиент получит мусор в другой кодировке, те опять нужно на lua писать конвертер.
Но блин, не верю я, что разные приборы отправляют снимки в разных кодировках и волшебный сервер сам их перекодирует в один формат-юникод.
Вспоминаем програф, в котором написано в тегах одна кодировка, а текст вообще в рандомной кодировке.

Цитата Kuzma ()
Отправлять и запрашивать файлы можно только по адресу и порту (5678 по умолчанию)

Эмм, не понял, сути проблемы)
А как можно иначе? TCP он и есть TCP, порт всегда менялся. Можно ли сервер прибить только к одному адресу сервера. Даже никогда не задумывался. Похоже, что нельзя, ну тогда фаерволы, iptables и всё такое.

Цитата Kuzma ()
а по вадо картинка получается того размера, который дал сервер.

Насколько помню, там для WADO можно указать в каком формате отдавать снимок в jpg или dcm. уровни яркости прописаны же в самом dicom-файле.
Из исходников, свежее.
20240924 mvh Read level and window as float and round to int in convert_to_gif etc
Цитата Kuzma ()
Мне, например, нужно считать какую-то статистику по этническим группам, или по специальным потребностям, или по состоянию пациентов, но сервер просто не может их вернуть, потому что это не предусмотрено даже его

Ну, тут тоже такое требование специфическое.
Как-будто какие-то махаоны выдергивают эти значения из снимков и записывают их в бд или ещё какой-нибудь тег, типа накопленной дозы.
Опять-таки, луашечка, и вперед. В документации, вроде, были примеры для заполнения кастомных полей в БД из выбираемых тегов, как раз этот случай.

Цитата Kuzma ()
Patient Root Query/Retrieve Information Model

Этими запросам вообще нельзя пользоваться.
У тебя с двух приборов пришли два пациента с ID=000001.
Patient Root Query выдаст только одного пациента.
Надо study query использовать.
Цитата Kuzma ()
Заявлением о соответствии стандарту DICOM.

Сам не смеешься над этой фразой, как именитые вендоры с 50-летней историей соблюдают стандарты.

Цитата Kuzma ()
Но не хочется тратить своё платное время :)

opensource никто никому ничего не должен.
GPL берёшь, дорабатываешь, продаёшь, выкладываешь в public по требованию покупателя, или не выкладываешь.

Возможно, conquest устарел в плане этих требований, но 10 лет уж прошло.
Для storage уже HTTP S3-протокол стандарт, а не вот эти расшаренные папочки с СХД.
Хм, в orthanc уже есть. значит на него надо перезжать.
https://orthanc.uclouvain.be/book/plugins/object-storage.html

Цитата Kuzma ()
SR не поддерживаю, не знаю, не могу.

Как мне показалось, Structured report это вообще костыль. Типа, как использование крышек^ в качестве разделителей. Один вендор будет туда запихивать XML, а другой запихает внутрь XML какой-нибудь блоб в формате base64-encoded из rtf-документа.

Вспомнилось. В Москве 10 лет пилили ЕРИС, он внезапно оказался на древней AGFA и не менее древней java.
А потом что-то случилось, и только на третий год зоркий индеец острый глаз начали импортозамещаться. Я пока, надеюсь, в сторонке постою, посмотрю ...


Сообщение отредактировал naves - Пятница, 18.Окт.2024, 23:29
 
KuzmaДата: Суббота, 19.Окт.2024, 20:29 | Сообщение # 184
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Цитата Kuzma ()
Мысль пришла, а может её значение нужно брать из запроса клиента?
Но блин, не верю я, что разные приборы отправляют снимки в разных кодировках и волшебный сервер сам их перекодирует в один формат-юникод.

Мысль хорошая. Но для того, чтобы запрашивать в конкретной кодировке, нужно знать в какой кодировке ОНО хранится. Я делаю запрос, например, дать мне всё с такой даты по такую. Откуда я знаю, в каких там кодировках кто что набросал?
Разные приборы отправляют в разной кодировке, это естественно. Одни в 144, другие в 192. Что здесь странного? Разные производители, разное ПО. Складывается всё на один сервер. Ну потому что это одна поликлиника, одна и та же рентгенография, одни и те же врачи её смотрят. Но 192-ю с конквест отдаёт в нормальном виде (после записи в ини), а 144-ю нет. Как к такому относится? Дцм4 отдаёт корректно в любом случае. Принял 144-ю, отдал 144-ю нормально, принял 192-ю, отдал 192-ю. Как он это делает, его дело, и нам по фиг. Важен итог. Я всё нормально вижу в своём приложении, в веазисе, в радианте, в микродайкоме.

Цитата Kuzma ()
Цитата Kuzma ()
Отправлять и запрашивать файлы можно только по адресу и порту (5678 по умолчанию).
Эмм, не понял, сути проблемы)

Суть в том, что АеТ сервера не учитывается. По любому ает обращайся, пиши только адрес и порт, и он отвечает. Напиши Ает ХРЕН он ответит, напиши РЕДЬКА - тоже.

Цитата Kuzma ()
Насколько помню, там для WADO можно указать в каком формате отдавать снимок в jpg или dcm

Не нашёл.

Цитата Kuzma ()
Цитата Kuzma ()
Мне, например, нужно считать какую-то статистику по этническим группам, или по специальным потребностям, или по состоянию пациентов, но сервер просто не может их вернуть, потому что это не предусмотрено даже его

Ну, тут тоже такое требование специфическое.
Как-будто какие-то махаоны выдергивают эти значения из снимков и записывают их в бд или ещё какой-нибудь тег, типа накопленной дозы.
Опять-таки, луашечка, и вперед. В документации, вроде, были примеры для заполнения кастомных полей в БД из выбираемых тегов, как раз этот случай.

Да плевать на махаоны и иже с ними.
МИС отправила нам на WL-сервер задачу со всеми данными пациента и исследования. Аппарат выполнил задачу и отправил на сервер файлы исследование. Если прибор нормальный, то нам пришли и все те данные, которые в задаче отправила МИС. Их ВСЕ сервер должен сохранить, а не только ФИО, ДР, пол. И отдать, когда его попросили по C-FIND.
Просто сравните, что может отдать конквест и дцм4 по разным уровням запросов.
Цитата naves ()
Цитата Kuzma ()
Заявлением о соответствии стандарту DICOM.
Сам не смеешься над этой фразой, как именитые вендоры с 50-летней историей соблюдают стандарты.

К этому придём и смеяться никто не будет. Это сейчас кому-то дико, когда требуют такое Заявление. Оно же соответствует дайком 3.0 у нас. Так написали поставщики! Хрен вам, поставщики! Дайте Заявление от производителя. Оно есть, просто никто не знает, что это такое и не требует от них. А потом выясняется, что аппарат не то, что не знает про WL, а и вообще "искаропки" не может отправлять на сервер ничего, т.к. это дополнительная платная опция. Для тех, кто совсем не в курсе, маленький ликбез про Заявление: https://telepacs.com.ua/?p=193
Потому что поставляют оборудование барыги. Им по фиг. Заказчик лопух. Чиновник в доле. Всем зашибись. Кроме персонала, который потом уже по факту узнает, что поставили дерьмо, а не то, что должно правильно работать.

Цитата naves ()
opensource никто никому ничего не должен

Согласен. Но хорошо, что есть выбор.
Конквест в некоторых вещах очень неплох. Как вариант сервиса для других приложений может работать. Быстро. Изначально вообще не перегружен никакими лишними функциями.
Но необходимость большой работы "напильниками" не вдохновляет.

Цитата naves ()
Хм, в orthanc уже есть. значит на него надо перезжать.

:)
Мне кажется там тоже без напильников никуда.

Цитата naves ()
Как мне показалось, Structured report это вообще костыль. Типа, как использование крышек^ в качестве разделителей. Один вендор будет туда запихивать XML, а другой запихает внутрь XML какой-нибудь блоб в формате base64-encoded из rtf-документа.

Это только так кажется. :)
Далеко не костыль и очень полезная вещь.
И даже "крышечки" что-то да значат :). Так вообще-то в стандарте пишут:
https://dicom.nema.org/medical.....2.html
Просто каждый вендор придумывает какую-то свою хрень вместо того, чтобы взять и почитать, что в букваре написано.
Можно, конечно, свой dicom-стандарт придумать и назвать его ДИКОМ-ГОСТ или как-то ещё. Не думаю, что всем от этого станет проще.
Цитата naves ()
только на третий год зоркий индеец острый глаз начали импортозамещаться

Импортозамещаться никогда не поздно, но не нужно импортозамещать общепринятые вещи: понятия, аксиомы и доказанные теоремы. Импортозамещай чужое ПО (если можешь), чужое железо, чужие слова и чужие правила.


Сообщение отредактировал Kuzma - Суббота, 19.Окт.2024, 20:40
 
navesДата: Понедельник, 21.Окт.2024, 13:05 | Сообщение # 185
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация

Москва
Цитата Kuzma ()
Насколько помню, там для WADO можно указать в каком формате отдавать снимок в jpg или dcm

Если по коду смотреть как работают комплектные веб-просмотровщики, то там в запросе явно указывают
https://github.com/marcelv....ua#L151
'?requestType=WADO&contentType=application/dicom'
Если будет другой contentType, то будет перекодировка изображений, в jpeg или даже gif
и в самом сервере, ниже по коду выбор формата
r2 && strcmp(r2, "application/dicom")==0
https://github.com/marcelv....#L22952


Сообщение отредактировал naves - Понедельник, 21.Окт.2024, 13:10
 
KuzmaДата: Вторник, 22.Окт.2024, 18:12 | Сообщение # 186
Завсегдатай
У вас сообщений: 269
инженер
OFFлайн
Украина

Харьков
Когда Овиям запрашивает с сервера текстовый SR, то он знает что contentType должен быть text/html. На картинках - настройки серверов для запроса, лог веб-сервера и что получается при запросе SR одного и того же УЗИ исследования с серверов dcm4chee-arc и conquest.
Видно, что запросы от вьювера, что к одному, что к другому абсолютно одинаковые. Но вид совершенно разный, т.е. dcm4chee каким-то образом ещё влияет на форматирование, а конквест нет - выводится весь теговый набор файла.
Где собака зарыта?
Вполне, конечно, может быть, что это Овиям как-то заточен на дцм4 и "знает" как от него нужно форматировать такой текст, а от конквеста нет ?
OHIF вообще сразу говорит, что хз, что это за файлы, не поддерживаю :) Ну и ладно. Поэтому мы с него ничего и не требуем. А здесь вроде бы как хотелось бы все-таки видеть.

Да, забыл про картинки. Когда картинки получаем по ГЕТу или МУВу, то овиям их сам распаковывает из дайкома в jpg или png и вписывает в своё окно. Т.е. отображается корректно и красиво.
А по ВАДО картинка запрашивается в jpg или png и получается с исходными размерами, которые в окно не помещаются. Здесь вообще не понятно, что делать. Но опять же, от дцм4 тоже также картинки берутся, они же как-то сразу помещаются. Не пойму, где рыть. В овияме, или в сервере
6430129.png (98.7 Kb) · 3389074.png (383.8 Kb) · 2835464.png (247.2 Kb) · 2155705.png (426.3 Kb)


Сообщение отредактировал Kuzma - Вторник, 22.Окт.2024, 19:06
 
navesДата: Четверг, 24.Окт.2024, 02:55 | Сообщение # 187
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация

Москва
Я бы через wireshark посмотрел бы, какие запросы идут, и где заголовки разные, ну и как сами данные приходят.

Цитата Kuzma ()
А по ВАДО картинка запрашивается в jpg или png и получается с исходными размерами, которые в окно не помещаются.

Попробуйте через wget подергать url.
Через wireshark посмотреть тоже заголовки.
Либо там приходят разные совсем картинки, либо ... хз ...
 
  • Страница 5 из 5
  • «
  • 1
  • 2
  • 3
  • 4
  • 5
Поиск:



Статистика Форума
Последние обновления тем: Новые файлы хранилища: Новые участники: Top10 участников:
1. Opera DFR - нет подкл...[vvv3vvv (03.Дек.2024)]
2. Моечно-дезинфекционна...[snewtown (03.Дек.2024)]
3. Термостат ТС-1/80 СПУ[Стовек (03.Дек.2024)]
4. КРД «РИМ АМ» ф.ООО &q...[Parkincjn (03.Дек.2024)]
5. ИВЛ Hamilton С3 ф.Ham...[laser09x (03.Дек.2024)]
6. Маммограф Giotto Imag...[Janker (03.Дек.2024)]
7. Телештативы моделей &...[vladi (03.Дек.2024)]
8. Помощь в техобслужива...[dzyatel (03.Дек.2024)]
9. сканер праймскан[Algystaank (03.Дек.2024)]
1. Офтальмологическая ус...[31.Окт.2024]
2. Cardinal-Health-VELA-...[03.Окт.2024]
3. Service Manual HAMILT...[02.Окт.2024]
4. Mindray DC-7 (ПО)[09.Сен.2024]
5. Руководство по эксплу...[26.Авг.2024]
6. Пароли для принтеров ...[20.Авг.2024]
7. СПГА-100-1-НН РУКОВОД...[05.Июн.2024]
8. Accuvix v20 - Service...[11.Апр.2024]
9. ГП 40 МО[19.Мар.2024]
10. BBraun Perfusor Compa...[14.Мар.2024]
1. viyaliy89[03.Дек.2024]
2. SH05[03.Дек.2024]
3. Minatko1[03.Дек.2024]
4. Krusen[03.Дек.2024]
5. Janker[03.Дек.2024]
6. Лазарь[03.Дек.2024]
7. serge-bondare[03.Дек.2024]
8. SlavikGTF[03.Дек.2024]
9. Algystaank[03.Дек.2024]
10. nickel3000[02.Дек.2024]
МастерБаку[582]
Yulana34[177]
Serg74[160]
Dimitrius[129]
naves[121]
РОМУЛ[120]
bektyish[120]
madmac[116]
Алекс-200[114]
begun_a[112]