InVesalius

Participe

Repositório

Wiki

Ajuda

Membros

Nenhum(a)

Ver todos(as)

InVesalius > Histórico de Fóruns > invesalius-dev > InVesalius - Bugs

Histórico de Fóruns

Voltar a invesalius-dev

Olá Pessoal,

Estamos finalizando e iremos subir hoje a nossa parte do neuronavegador.
No entanto, enquanto trabalhamos, encontramos alguns bugs.

1 - No momento em que faço reconstrução multiplanar de imagens de ressonância magnética da máquina Siemens 3T, algum filtro está sendo aplicado que está saturando as imagens. Como ocorre no caso de um exame que tenho aqui, a cabeça nas fatias fica toda branca, sem diferenciação dos tons de cinza. Nós trabalhamos principalmente com imagens de ressonância dessa máquina. Eu vi que na pré-visualização as imagens estão sendo mostradas normalmente

2- Nas imagens de ressonância (agora todas), existe algum problema com a atualização das fatias ao movimentar a cruz vermelha. Exemplo: Mexendo com a cruz na fatial axial, somente a sagital atualiza, e a coronal fica congelada (a cruz na coronal atualiza). Mesmo atualizando a sagital, ela atualiza na orientação errada, ou seja, ela atualiza quando movimento no sentido em que a coronal deveria atualizar.
Esse problema impede que o neuronavegador funcione, pois utilizamos as mesmas funções que vocês criaram para atualizar essas fatias.

3- A cruz vermelha não aparece na fatia coronal quando movimento a cruz em qualquer das outras duas orientações.

Atenciosamente.

Victor Hugo

Autor: Victor Hugo de Oliveira Souza

4545 comentários

Victor Hugo de Oliveira Souza(usuário não autenticado)
27 de Janeiro de 2010, 12:10

Olá,
Subi para o file-storage [1] um arquivo 7zip contendo as imagens de ressonância que estamos trabalhando. Consegui visualizá-la alterando o brilho, mas mesmo assim ela é importada saturada. O problema maior está na atualização das fatias com o movimento da cruz, como mencionei acima. Nas imagens de CT esse problema não aparece.
Abraços.
- Victor Hugo de Oliveira Souza(usuário não autenticado)
  
  27 de Janeiro de 2010, 12:11
  
  [1] - www.softwarepublico.gov.br/dotlrn/clubs/invesalius/file-storage/
  O arquivo tem nome: MRI_MPR
Tatiana Al-Chueyr Pereira Martins(usuário não autenticado)
28 de Janeiro de 2010, 14:11

Oi Victor!
Por favor, você poderia nos passar mais exames de exemplo?
Se possível, coloque-os na pasta:
www.softwarepublico.gov.br/dotlrn/clubs/invesalius/file-storage/?folder_id=6825509
Seguindo o modelo de nomenclatura:
usp-ribeirao-mri.7z
Em relação aos pontos levantados:
1. Verifiquei o "problema", inseri um ticket em nosso sistema de tarefas [1] e faremos as devidas correções em breve. Imagino que este problema não atrapalhe o trabalho de vocês, pois basta ajustar o valor de window/level inicial, mas corrigiremos o quanto antes para a comodidade de vocês.
2. Este é um erro grave, e Thiago já está alocado para resolvê-lo [2]. Ele não estava ocorrendo para outros exames nos quais testamos a ferramenta de referência multiplanar. Para o corrigirmos é fundamental que vocês forneçam mais exames para testarmos.
3. Já conhecíamos este problema. Ele não afeta o neuronavegador, pois é um problema de exibição da cruz apenas, questão de manipulação do VTK, e não de cálculo. Também criamos um ticket para ele [3].
Abraços,
Tatiana
[1] svn.softwarepublico.gov.br/trac/invesalius/ticket/149#preview
[2] svn.softwarepublico.gov.br/trac/invesalius/ticket/147#preview
[3] svn.softwarepublico.gov.br/trac/invesalius/ticket/148#preview
- Tatiana Al-Chueyr Pereira Martins(usuário não autenticado)
  
  19 de Fevereiro de 2010, 15:41
  
  Victor,
  No trunk já estão disponíveis as correções para os problemas [1] e [2]. Para saber mais informações sobre as correções, basta acessar estes links que havia lhe passado, referentes aos tickets.
  Um comentário em relação ao valor de window/level inicial: o problema não era do InVesalius, mas do conjunto de imagens DICOM gerado pelo equipamento de ressonância. Cada uma das fatias de uma mesma série está com um valor distinto de window/level.
  Na importação isso não gera problemas - como não foi feita nenhuma forma de interpolação, cada fatia é exibida com o próprio valor de window/level. Após a importação, entretanto, como geramos um único imagedata a partir de todas as fatias, precisamos determinar um único valor de window/level...
  Antigamente (antes Beta 1) forçávamos o valor de window/level para 300 e 20, por exemplo. Entretanto, um certo tempo antes do Beta 1, optamos por manter maior coerência com os dados do exame, e começamos a utilizar o window/level da primeira fatia. A partir deste momento, todos os exames obtidos com o equipamento de RMI que vocês utilizam começaram a ficar "saturados", conforme você relatou - pois a primeira fatia da série tem valores próximos a 10 e 6. A partir do r1650 optamos por utilizar o valor de window/level da fatia do meio, o que contorna o "problema".
  Se vocês tiverem contato com o fabricante do equipamento, poderiam perguntar sobre este curioso aspecto - de cada imagem ter um valor distinto de window/level ;)
  Abraços,
  Tatiana
  [1] svn.softwarepublico.gov.br/trac/invesalius/ticket/149#preview
  [2] svn.softwarepublico.gov.br/trac/invesalius/ticket/147#preview
Victor Hugo de Oliveira Souza(usuário não autenticado)
6 de Julho de 2010, 19:26

E aí pessoal, tudo bem?
É o seguinte, estava trabalhando com a reconstrução da superfície tridimensional pela máscara e notei que a atual versão do trunk (r1906) está com um erro quando utilizo imagens de ressonancia magnética. Percebi que quando importo as imagens e crio a superfície ela está aparecendo de cabeça para baixo. E isso impede que a bolinha vermelha que indica o centro da cruz nas fatias corresponda de forma correta à posição em que els está centrada. Fiz o teste com todos os exames que vocês têm aí, rp-mri e em todos a superfície está de cabeça para baixo.
Dêem uma olhada nisto quando possível.
Até logo.
Abraços.
Victor Hugo
- Thiago Franco Moraes(usuário não autenticado)
  
  8 de Julho de 2010, 15:12
  
  Olá Victor,
  Obrigado por reportar este erro. Arrumamos no último commit. Você poderia testar?
  Abraço.
  - Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    8 de Julho de 2010, 16:10
    
    E aí Thiago,
    Deu certo sim. Muito obrigado.
    Abraços e até logo.
Victor Hugo de Oliveira Souza(usuário não autenticado)
17 de Dezembro de 2010, 17:17

E aí galera!É o seguinte, para trabalhar com o neuronavegador, eu tive que usar um revision bem mais antigo do trunk, por causa das mudanças q vcs estavam fazendo no código. No entanto, fui tentar rodar o invesalius agora e "não consegui". No Windows, o InVesalius trava quando aparece a tela de apresentação, ou seja nem chega a rodar o frame principal.No Ubuntu, rodando pelo terminal ele abre, mas não tem quase nenhuma operação funcionando, tentei abrir imagens dicom de ressonancia e as imagens apareceram todas estranhas, umas nem abrem dando erro de falha de segmentação, a imagem analyze tbm está abrido tudo diferente. Nem a de CT que a gnt costumava trabalhar está abrindo.Gostaria de saber, quais os planos de vcs... para quando o programa vai estar funcionando normalmente??Com relação ao neuronavegador.. eu finalizei a base. Mudei MUITA coisa no modo como as funções são chamadas, criei um novo módulo e alterei a interface gráfica. Lembra dos botões de salvar as coordenadas dos marcadores e dpois da possibilidade de dar load nelas? Já estão prontas. Agora tem como alterar a cor e o tamanho das esferas tbm. Outro ponto importante, adicionei um box que permite escolher qual rastreador deseja usar, e outro se deseja usar uma ou duas referencias. Falta agora para completarmos mais um estágio, montar o wrapper 64 bits para o claron e o wrapper para o Zebris. Isto o Eduardo está tomando conta, mas alguns erros bem complicados estão aparecendo. Espero que possamos nos juntar novamente para colocar o código em dia e muita coisa deve ser discutida.Algum de vocês estudou algo sobre colocar aquele mapa de cores do campo magnético na superfície volumétrica. Passem algo pra mim por favor pra eu poder me atualizar, pois preciso avançar nesse ponto logo.Agradeço desde já pela ajuda de vocês.Bom fim de ano a todos e boas festas.Abraços.Victor Hugo.
- Thiago Franco Moraes(usuário não autenticado)
  
  17 de Dezembro de 2010, 22:28
  
  Oi Victor,Realmente, a reconstrução de casos como o RP-MRI1 está incorreto, acredito que seja por estarem em orientação diferente de axial. De todos os arquivos que você disponibilizou no file-storage, nenhum está dando falha de segmentação, você poderia colocar um casos destes no file-storage.Nós pretendemos terminar estas mudanças em fevereiro. Mas acredito que as funcionalidades que você necessitam estarão prontas antes.Sobre o mapa des cores, eu estava vendo que é possível na malha de triângulos do vtk atribuir valores escalares aos triângulos. Utilizando isto mais um mapa de cores, eu acho que você conseguirá fazer o que necessita.Muito bom os seus avanços no neuronavegador.Abraços.
  - Thiago Franco Moraes(usuário não autenticado)
    
    19 de Dezembro de 2010, 21:37
    
    Oi Victor,O Paulo corrigiu o problema das dicoms na sagital no commit 1985. Se você puder testar.Abraços.
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    20 de Dezembro de 2010, 8:50
    
    E aí Thiago,
    Obrigadoo! Entao.. acabei de sair de ferias e to aqui na minha cidade sem meu computador! Entao reinstalarei tudo que precisa para rodar o invesalius e testarei aqui mesmo, ok? Devo voltar firme na metade de janeiro.
    Quando eu voltar farei todos os testes e verei quais arquivos estavam dando falha na segmentação.
    Abraços.
    Victor Hugo.
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    20 de Dezembro de 2010, 11:20
    
    Fala Thiago,Baixei todos as libs e instalei tudo do zero em um pc com xp 32 bits. A revision 1986 simplesmente não roda. To tentando abrir por linha de comando ">>>python invesalius.py" aí aparece a dialog de escolher o idioma, depois de apertar ok aparece a mensagem que o Python parou de funcionar. Alguma sugestao? Abraços.
    
    Thiago Franco Moraes(usuário não autenticado)
    
    20 de Dezembro de 2010, 13:14
    
    Victor, aparece alguma mensagem no terminal após o erro?
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    20 de Dezembro de 2010, 23:08
    
    Nenhuma.... ele simplesmente aparece a caixa dizendo q python.exe encontrou um problema e parou de funcionar. Só isso.
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    19 de Janeiro de 2011, 9:17
    
    E aí Thiago, tudo bom?Então.. alguma idéia do que possa estar me impedindo de rodar o invesalius?Voltei novamente para um computador com win 7 64 bits... com Python 2.7.Como antes, aparece apenas a dialog com "python.exe parou de funcionar" sem nenhuma mensagem de erro no prompt de comando.Preciso muito que rode para poder usar a importação de analyze.Abraços.
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    19 de Janeiro de 2011, 9:55
    
    Ahh é com Python 2.6, eu tinha me enganado!
    
    Thiago Franco Moraes(usuário não autenticado)
    
    20 de Janeiro de 2011, 10:47
    
    Olá Victor,É dificil saber apenas com estas informações. Acredito que seja algum problema com o VTK e/ou gdcm, recomendo você compilar os dois novamente.
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    5 de Abril de 2011, 0:32
    
    E aí pessoal!! Ahh eu aqui novamente!! É o seguinte, a importação de imagens de ressonancia está novamente com sérios problemas! heuhe1 - As imagens analyze que foram adquiridas em orientação sagital mas que não tem essa informação na tag, estão abrindo com as orientações todas atrapalhadas.. Já tentei forçar que sempre seja considerada a sagital como padrão para analyze mas mesmo assim não fez diferença. A exibição fica toda bagunçada!2 - As imagens de ressonância dicom que tem no file-storage também estão com erros na exibição. Por exemplo a rpmri 3 está com o Posterior - Anterior invertido.. Dá pra ver nitidamente...3 - Falta muito pra se poder criar a superfície novamente? Abraços.
    
    Thiago Franco Moraes(usuário não autenticado)
    
    5 de Abril de 2011, 14:53
    
    Olá Victor,
    Você está utilizando a ultima versão do trunk?
    1. Como você tentou forçar a ser sagital? Talvez a melhor opção é você especificar na própria imagem analyze a orientação.
    2. Ok. Nós estamos vendo de fazer uma interface gráfica para o usuário configurar isso.
    3. Então, ela está funcionando. Você está tendo algum problema com isso? Qual o erro?
    Falou!
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    5 de Abril de 2011, 16:46
    
    Falaa Thiago!!Sim, estou usando a revision 2008 e todos os dias eu verifico se teve algum commit.1 - Então, num vai adiantar eu mudar no header, porque o que eu fiz foi no módulo control e na parte do CreateAnalyzeProject, eu coloquei orientation = 'SAGITAL' para qualquer valor que seja lido no header. Ou seja, if 'orient' == 1 entao orientation = SAGITAL, if 'orient' == 2 entao ortientation = SAGITA. Entendeu? E não tá fazendo diferença alguma se eu coloco tudo SAGITAL ou tudo CORONAL ou tudo AXIAL, dá sempre na mesma. 2- Hmm.. parte gráfica para configurar a importação de imagens de ressonância? Seria interessante! ;)3- O erro que tá dando aqui quando clico para gerar a superfície é esse:Traceback (most recent call last): File "E:\InVesalius\trunk_update_03\invesalius\gui\task_slice.py", line 149, in OnButtonNextTask overwrite)) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\pubsub\pubsub1\pub.py", line 750, in sendMessage self.__topicTree.sendMessage(aTopic, message, onTopicNeverCreated) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\pubsub\pubsub1\pub.py", line 423, in sendMessage deliveryCount += node.sendMessage(message) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\pubsub\pubsub1\pub.py", line 261, in sendMessage listener(message) File "E:\InVesalius\trunk_update_03\invesalius\data\slice_.py", line 581, in CreateSurfaceFromIndexTraceback (most recent call last): File "<string>", line 1, in <module> File "C:\Python27\lib\multiprocessing\forking.py", line 347, in main self = load(from_parent) File "C:\Python27\lib\pickle.py", line 1378, in load return Unpickler(file).load() File "C:\Python27\lib\pickle.py", line 858, in load dispatch[key](self) File "C:\Python27\lib\pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "C:\Python27\lib\pickle.py", line 1124, in find_class __import__(module) File "E:\InVesalius\trunk_update_03\invesalius\data\surface_process.py", line 9, in <module> import imagedata_utils File "E:\InVesalius\trunk_update_03\invesalius\data\imagedata_utils.py", line 32, in <module> import constants as const File "E:\InVesalius\trunk_update_03\invesalius\constants.py", line 25, in <module> from project import Project File "E:\InVesalius\trunk_update_03\invesalius\project.py", line 33, in <module> import data.imagedata_utils as iuAttributeError: 'module' object has no attribute 'imagedata_utils' ps.Publisher().sendMessage('Create surface', (self.matrix, self.matrix_filename, mask, self.spacing)) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\pubsub\pubsub1\pub.py", line 750, in sendMessage self.__topicTree.sendMessage(aTopic, message, onTopicNeverCreated) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\pubsub\pubsub1\pub.py", line 423, in sendMessage deliveryCount += node.sendMessage(message) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\pubsub\pubsub1\pub.py", line 261, in sendMessage listener(message) File "E:\InVesalius\trunk_update_03\invesalius\data\surface.py", line 469, in AddNewActor sp.start() File "C:\Python27\lib\multiprocessing\process.py", line 104, in start self._popen = Popen(self) File "C:\Python27\lib\multiprocessing\forking.py", line 244, in __init__ dump(process_obj, to_child, HIGHEST_PROTOCOL) File "C:\Python27\lib\multiprocessing\forking.py", line 167, in dump ForkingPickler(file, protocol).dump(obj) File "C:\Python27\lib\pickle.py", line 224, in dump self.save(obj) File "C:\Python27\lib\pickle.py", line 331, in save self.save_reduce(obj=obj, *rv) File "C:\Python27\lib\pickle.py", line 419, in save_reduce save(state) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 649, in save_dict self._batch_setitems(obj.iteritems()) File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems save(v) File "C:\Python27\lib\pickle.py", line 331, in save self.save_reduce(obj=obj, *rv) File "C:\Python27\lib\pickle.py", line 419, in save_reduce save(state) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 562, in save_tuple save(element) File "C:\Python27\lib\pickle.py", line 286, in save f(self, obj) # Call unbound method with explicit self File "C:\Python27\lib\pickle.py", line 486, in save_string self.write(BINSTRING + pack("<i", n) + obj)IOError: [Errno 32] Broken pipe Abraços.
    
    Thiago Franco Moraes(usuário não autenticado)
    
    6 de Abril de 2011, 16:36
    
    Oi Victor,
    1. Fiz um novo commit no svn para tratar as orientações do analyze. Faça o teste. Eu estou setando sagital como padrão.
    3. Que erro estranho. Você testou em mais de uma máquina? O erro é o mesmo?
    
    Victor Hugo de Oliveira Souza(usuário não autenticado)
    
    6 de Abril de 2011, 17:32
    
    1- Agora está diferente mas ainda errado: Fatial Axial na janela AXIAL; fatia Coronal na janela SAGITAL, fatia Sagital na janela CORONAL. O nariz está voltado para o lado D e o superior está invertido com inferior (imagem de cabeça para baixo). Estranho não? heuheuh3- Não testei não, estamos formatando algumas máquinas aqui, quando terminar eu rodo o invesalius do zero! Ok?Abraços e valeu jow!
    
    Thiago Franco Moraes(usuário não autenticado)
    
    7 de Abril de 2011, 10:17
    
    Olá Victor,
    Pelo que eu andei lendo [1], a tag orient é opcional e muitos softwares ordenam os voxels de qualquer jeito, que pode ser o seu caso. Então, talvez seja melhor você tentar arrumar a orientação destes casos ou forçar o InVesalius a trabalhar com esta orientação. Para isso, você terá que alterar o arquivo control.py, entre as linha 390 e 400.
    [1] - www.grahamwideman.com/gw/brain/analyze/formatdoc.htm
Renan Calliari(usuário não autenticado)
18 de Julho de 2011, 13:57

Gostaria de acrescentar mais um bug do invesalius: Programa está consumindo toda a memória RAM do sistema enquanto o swap fica oscioso. Existiria alguma maneira de o programa usar o swap ou então criar um scratch disk como o que existe no photoshop?
O arquivo importado tem 217 fatias de tomografia Cone Bean porém não consigo usar todas fatias pois o sistema trava. A opção que está funcionando é: pular 4 a cada 5 fatias.

Sistema FC12 3GB RAM
Invesalius rodando com todas as dependências resolvidas inclusive o pacote itk-vtkglue na versão 3.20

Para quem ainda (como eu) usa fedora 12 alguns bugs são criados após o update dos pacotes da distro:
Bug 01

[renan@localhost SPECS]$ invesalius-3.0
Traceback (most recent call last):
File "invesalius.py", line 271, in <module>
    main()
File "invesalius.py", line 229, in main
    application = InVesalius(0)
File "/usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7978, in __init__
    self._BootstrapApp()
File "/usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7552, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "invesalius.py", line 54, in OnInit
    splash = SplashScreen()
File "invesalius.py", line 144, in __init__
    self.main = Frame(None)
File "/usr/share/invesalius-3.0/invesalius/gui/frame.py", line 74, in __init__
    self.__init_aui()
File "/usr/share/invesalius-3.0/invesalius/gui/frame.py", line 118, in __init_aui
    aui_manager.AddPane(tasks.Panel(self), wx.aui.AuiPaneInfo().
File "/usr/share/invesalius-3.0/invesalius/gui/default_tasks.py", line 103, in __init__
    sizer.Add(UpperTaskPanel(self), 16, wx.EXPAND|wx.GROW)
File "/usr/share/invesalius-3.0/invesalius/gui/default_tasks.py", line 187, in __init__
    self.GetSize(),fpb.FPB_DEFAULT_STYLE,
AttributeError: 'module' object has no attribute 'FPB_DEFAULT_STYLE'
Solução encontrada:
trac.wxwidgets.org/ticket/12388
There is problem with launching xrced in Fedora 13. I believe that it's problem with wxPython, not with fedora.
Problem is only in version 2.8.11.0, when I downgraded wxpython to 2.8.10.x, it works perfectly.
Bug 02
Gdk-ERROR **: The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 9882 error_code 3 request_code 138 minor_code 4)
(Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...
/usr/bin/invesalius-3.0: line 3: 5216 Abortado                (imagem do núcleo gravada)python invesalius.py $@

Solução:
Update nvidia driver
- Thiago Franco Moraes(usuário não autenticado)
  
  19 de Julho de 2011, 13:29
  
  Olá Renan Calliari,
  Muito obrigado por reportar os bugs. Sobre a questão da memória, nós estamos trabalhando nisso. Nós agora estamos usando mapeamento via mmap da matriz da imagem num arquivo, o que diminui e muito a memória utilizada no programa sem perda de velocidade. Estamos demorando para lançar uma nova versão devido à isso, pois várias partes do InVesalius 3 estão sendo reescritas.
  O Bug 01, da versão do wxPython, já resolvemos, está no nosso repositório svn. E o Bug 02, que você até já solucionou, deve ser alguma incompatibilidade com a versão do driver da nvidia. Você atualizou o seu driver da nvidia do próprio repositório do Fedora ou você utilizou os disponíveis no site da nvidia?
  Muito obrigado!
  - Renan Calliari(usuário não autenticado)
    
    21 de Julho de 2011, 14:38
    
    Estou usando o driver disponível no site da nvidia pois o fc12 não possui mais updates. Driver versão 270.41.19
    Qto aos pacotes necessários para fedora, eu posso colocar-los a disposição desde que o meu espaço para arquivos tenha pelo menos uns 500MB. Enviar specs de nada adiantará pois os patchs foram criados e/ou adaptados por mim.
    Tive que corrigir os pacotes disponibilizados pelo Mario Ceresa para que o ITK-3.20 pudesse ser compilado.
    
    Thiago Franco Moraes(usuário não autenticado)
    
    24 de Julho de 2011, 19:20
    
    Olá Renan,
    Desculpas pela demora. Estes pacotes que você adaptou são apenas para a versão 12 do Fedora? Acredito que podemos colocar os seus pacotes aqui no portal do software publico.
    
    Renan Calliari(usuário não autenticado)
    
    31 de Julho de 2011, 18:53
    
    Oi Thiago,
    Vou baixar o FC15 e ver quais as adapatações necessárias. Alguns pacotes que baixei já eram do fc15 apenas adaptei e corrigi os erros.
    Se vc puder me disponibilizar um endereço para upload eu envio os sources dos pacotes e aí é só recompilar para a plataforma desejada.
    Também gostaria que o spec file do invesalius fosse disponibilizado. Pouparia o meu tempo de criar o pacote pois é muito mais fácil aplicar patchs no programa e testar via rpm.
    
    Thiago Franco Moraes(usuário não autenticado)
    
    1 de Agosto de 2011, 9:38
    
    Olá Renan,
    Excelente, Renan. Isso vai nos ajudar muito. Sobre um espaço para upload, eu tenho que ver algum jeito aqui. O spec file do InVesalius está aqui dl.dropbox.com/u/817671/packages/invesalius-3.0.spec
    Muito obrigado!
    
    Renan Calliari(usuário não autenticado)
    
    20 de Agosto de 2011, 14:32
    
    Thiago,
    Compilei os todos os pacotes para o fc15, inclusive o invesalius, porém existe um bug na versão svn1925 q ainda não consegui resolver:
    [renan@localhost SPECS]$ invesalius
    session mode: 0
    50 93
    76 144
    50 93
    50 93
    50 93
    7 93
    7 165
    7 93
    71 135
    7 135
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    82 157
    82 157
    7 157
    7 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    /usr/bin/invesalius: line 4: 13989 Falha de segmentação (imagem do núcleo gravada)python invesalius.py "$@"
    
    Continuo aguardando um espaço para upload dos pacotes do fedora 15
    
    Thiago Franco Moraes(usuário não autenticado)
    
    22 de Agosto de 2011, 9:50
    
    Oi Renan,
    Esse erro deve ser ocasionado pelo VTK + WxPython. Experimente aplicar este patch no VTK vtk.1045678.n5.nabble.com/attachment/2638103/0/vtk_wxpython.patch.
    Para o upload dos pacotes existe o File Storage. Criei uma pasta para você colocar os pacotes lá: www.softwarepublico.gov.br/dotlrn/clubs/invesalius/file-storage/?folder_id=38192888
    Depois de prontos, os seus pacotes para o InVesalius 3 poderiam entrar no projeto Fedora Medical fedoraproject.org/wiki/SIGs/FedoraMedical .
    Muito obrigado.
    
    Renan Calliari(usuário não autenticado)
    
    24 de Agosto de 2011, 12:00
    
    Oi Thiago, Apliquei a patch que vc me indicou no pacote vtk e resolvi o problema, agora o programa está abrindo poré surgiu outro problema ao importar arquivos *.DCM. Em relação aos pacotes estou realizando alguns acertos para padronizar o pacote ITk para depois enviar.
    
    [renan@localhost SPECS]$ invesalius
    session mode: 0
    50 93
    76 144
    50 93
    50 93
    50 93
    7 93
    7 165
    7 93
    71 135
    7 135
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    82 157
    82 157
    7 157
    7 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    82 157
    7 157
    Image Resized to >>> 640.000000 x 640.000000
    Session.CreateProject
    32 157
    11 34
    32 157
    11 34
    7 34
    7 157
    SelectCurrentMask
    index: 0
    Traceback (most recent call last):
    File "/usr/share/invesalius-3/invesalius/gui/import_panel.py", line 165, in OnClickOk
        self.LoadDicom(group)
    File "/usr/share/invesalius-3/invesalius/gui/import_panel.py", line 178, in LoadDicom
        ps.Publisher().sendMessage('Open DICOM group', (group, interval))
    File "/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/lib/pubsub/pubsub1/pub.py", line 750, in sendMessage
        self.__topicTree.sendMessage(aTopic, message, onTopicNeverCreated)
    File "/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/lib/pubsub/pubsub1/pub.py", line 423, in sendMessage
        deliveryCount += node.sendMessage(message)
    File "/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/lib/pubsub/pubsub1/pub.py", line 261, in sendMessage
        listener(message)
    File "/usr/share/invesalius-3/invesalius/control.py", line 428, in OnOpenDicomGroup
        self.LoadProject()
    File "/usr/share/invesalius-3/invesalius/control.py", line 359, in LoadProject
        proj.mask_dict))
    File "/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/lib/pubsub/pubsub1/pub.py", line 750, in sendMessage
        self.__topicTree.sendMessage(aTopic, message, onTopicNeverCreated)
    File "/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/lib/pubsub/pubsub1/pub.py", line 423, in sendMessage
        deliveryCount += node.sendMessage(message)
    File "/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/lib/pubsub/pubsub1/pub.py", line 261, in sendMessage
        listener(message)
    File "/usr/share/invesalius-3/invesalius/data/viewer_slice.py", line 991, in LoadImagedata
        self.SetInput(imagedata, mask_dict)
    File "/usr/share/invesalius-3/invesalius/data/viewer_slice.py", line 1098, in SetInput
        self.SetInteractorStyle(const.STATE_DEFAULT)
    File "/usr/share/invesalius-3/invesalius/data/viewer_slice.py", line 284, in SetInteractorStyle
        self.interactor.Bind(wx.EVT_LEFT_DCLICK, None)
    File "/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 3917, in Bind
        assert callable(handler)
    AssertionError
    
    Segue a lista de pacotes que darei upload em breve:
    rpm -ivh vxl-1.14.0-1.fc15.i686.rpm vxl-doc-1.14.0-1.fc15.i686.rpm vxl-devel-1.14.0-1.fc15.i686.rpm sigar-python-1.7-1.fc15.i686.rpm CableSwig-3.20.0-3.fc15.i686.rpm gdcm-2.0.16-18.fc15.i686.rpm gdcm-devel-2.0.16-18.fc15.i686.rpm gdcm-python-2.0.16-18.fc15.i686.rpm gccxml-0.9.0-0.6.20110211b.fc15.i686.rpm InsightToolkit-3.20.0-7.fc15.i686.rpm InsightToolkit-devel-3.20.0-7.fc15.i686.rpm InsightToolkit-doc-3.20.0-7.fc15.i686.rpm InsightToolkit-examples-3.20.0-7.fc15.i686.rpm InsightToolkit-ItkVtkGlue-wrapitk-3.20.0-7.fc15.i686.rpm InsightToolkit-PyBuffer-wrapitk-3.20.0-7.fc15.i686.rpm InsightToolkit-python-wrapitk-3.20.0-7.fc15.i686.rpm InsightToolkit-tcl-wrapitk-3.20.0-7.fc15.i686.rpm python-dicom-0.9.4-1.fc15.noarch.rpm python-nibabel-0.2-20100816.fc15.noarch.rpm vtk-5.6.1-10.fc15.i686.rpm vtk-devel-5.6.1-10.fc15.i686.rpm vtk-tcl-5.6.1-10.fc15.i686.rpm vtk-python-5.6.1-10.fc15.i686.rpm vtk-java-5.6.1-10.fc15.i686.rpm vtk-qt-5.6.1-10.fc15.i686.rpm invesalius-3-svn1925.fc15.i686.rpm
    
    Thiago Franco Moraes(usuário não autenticado)
    
    24 de Agosto de 2011, 13:53
    
    Oi Renan,
    Qual a versão do WXPython você está utilizando? Vendo no recent changes [1] do WXPython, na ultima versão da série 2.8, a versão 2.8.12.1, o Bind voltou a aceitar None. Aparentemente, numa versão anterior, o Bind não aceita None.
    Você acha que é possível subir esses pacotes para algum repositório oficial do Fedora ou algum outro?
    [1] - wxpython.org/recentchanges.php
    
    Renan Calliari(usuário não autenticado)
    
    25 de Agosto de 2011, 12:05
    
    Thiago,
    Apliquei as patches do mandriva wxPythonGTK no pacote do wxPython do fedora e resolveu o problema do Bind. Por essa razão mais dois pacotes modificados entraram na dependência do invesalius:
    wxPython-2.8.12.0-2.fc15.i686.rpm wxPython-devel-2.8.12.0-2.fc15.i686.rpm
    
    Agora está funcionando! Consome menos memória mas continua pesado.
    
    Em relação a subir os pacotes para o repositório do fedora: acho meio complicado pois sou single user e não tenho condições de manter todos esse pacotes funcionando sozinho. Para construir o Insightoolkit tive que alterar as installs paths do Mario Ceresa para os pacotes CableSwig e gdcm (cmake não consegue achar eles na forma que o Mario colocou no script). O pacote que desenvolvi para o itk tem 3 opções: com CableSwig, normal (opção do Mario) e com wrapitk que é a opção para o invesalius. O autor a princípio não usa o python diretamente. Portanto acho que os meus pacotes iriam conflitar com as ideias dele ou das pessoas envolvidas em outros projetos.
    
    Tenho mais uma dúvida: como eu deveria construir o pacote vtk?
    com ou sem OSMesa? o invesalius precisa desta biblioteca?
    
    Thiago Franco Moraes(usuário não autenticado)
    
    25 de Agosto de 2011, 13:05
    
    Oi Renan,
    Sim, o InVesalius utiliza o VTK. Ele é utilizado para a visualização 2D e 3D. Quando eu compilo o VTK, eu não uso o OSMesa. Nos repositórios do Fedora já tem o VTK, né? Talvez não seja necessário gerar os pacotes do VTK.
    
    Renan Calliari(usuário não autenticado)
    
    25 de Agosto de 2011, 13:14
    
    A principio não seria necessário, mas para aplicar a patch no VTK "http://vtk.1045678.n5.nabble.com/attachment/2638103/0/vtk_wxpython.patch" que vc me indicou foi necessário reconstruir o pacote. Acredito não ser uma forma elegante e/ou padrão do fedora aplicar patchs diretamente em pacotes instalados.
    
    Renan Calliari(usuário não autenticado)
    
    26 de Agosto de 2011, 11:26
    
    Thiago,
    Preciso permissão para dar o upload do ITk python, o tamanho do pacote é de 160MB. O espaço para o qual estou enviando os arquivos aceita no máximo arquivos de 50MB de tamanho. Nem o source.rpm do invesalius passou no upload.
    
    Paulo Henrique Junqueira Amorim(usuário não autenticado)
    
    29 de Agosto de 2011, 10:08
    
    Oi Renan,
    Realizei uma alteração, por favor tente novamente.
    Abraço,
    Paulo Amorim
    
    Renan Calliari(usuário não autenticado)
    
    29 de Agosto de 2011, 12:58
    
    Tentarei hoje a noite se as descargas elétricas oriundas das condições metereológicas permitirem conexão. Não sei se guardei o link para upload e as mensagens do invesalius bugs foram apagadas.Se vc puder me passar novamente ageradeço.
    
    Paulo Henrique Junqueira Amorim(usuário não autenticado)
    
    29 de Agosto de 2011, 13:29
    
    Renan,
    O link é esse: www.softwarepublico.gov.br/dotlrn/clubs/invesalius/file-storage/?folder_id=38192888
    
    Até,
    
    Renan Calliari(usuário não autenticado)
    
    30 de Agosto de 2011, 23:30
    
    Paulo,
    Foi concluido o upload de todos os arquivos. Fico a disposição para qualquer dúvida ou teste de novas versões funcionais do invesalius. Corrigi um pequeno erro no código do invesalius e gostaria de saber se a minha correção foi adequada.
    No momento estou compilando o ITk com o pacote java que tb estará a disposição de usuários do fedora interessados em devel de programas na plataforma java.
    Abraço
    
    Renan
    
    Thiago Franco Moraes(usuário não autenticado)
    
    2 de Setembro de 2011, 9:43
    
    Olá Renan,
    Eu testei os pacotes aqui. Eu tive uma pequena dificuldade para instalar. Foi necessário instalar o pacote CharLS via yum para poder instalar o gdcm. Você sabe se há um modo de instalar via yum o invesalius e suas dependências que estão numa pasta na máquina + as dependências baixadas via internet? Isso facilitaria muito o processo. Ah, faltou uma dependência no pacote do InVesalius, o pacote pyserial. E sim, sua correção foi adequada.
    Muito obrigado, seu pacotes ficaram ótimos.
    
    Renan Calliari(usuário não autenticado)
    
    2 de Setembro de 2011, 13:05
    
    Oi Thiago,
    Para instalar os pacotes existentes na máquina vc pode usar o comando yum localinstall ...i686.rpm porém o pacote InsightToolkit-tcl-wrapitk-3.20.0-7.fc15.i686.rpm tem aquele probleminha de não reconhecer que as bibliotecas requeridas estão no próprio pacote (isso não acontecia no fc12). Como o pacote tcl não é querido pelo invesalius vc pode simplesmente instalar o pacote invesalius dando um yum localinstall invesalius. Eu particularmente nunca experimentei isso pq fui montado os pacotes "na unha". Vou fazer as correções sugeridas e darei upload em breve. Obs: o yum não permite a função --nodeps
Victor Hugo de Oliveira Souza(usuário não autenticado)
10 de Julho de 2012, 22:03

Olá meus caros,
Baixei o trunk rev. 2096. No módulo surface.py, há um:
>> import data.ca_smoothing as ca_smoothing
No entanto, este módulo, ca_smoothing não existe. Existe a intenção de vocês o colocarem no trunk?
Outro bug é:
Na importação do método Image da biblioteca PIL, se você estiver utilizando Python 2.7, deve-se escrever:
>> import Image
Se estiver utilizando Python 2.6 é preciso escrever:
>> from PIL import Image
Caso não seja feito dessa forma, aparece o seguinte erro nos dois casos:
>> AccessInit: hash collision: 3 for both 1 and 1
Não há uma maneira de não ficarmos vinculados a estas restrições? talvez com uma sentença try. O que acham?
Abraços,
Victor Hugo
- Thiago Franco Moraes(usuário não autenticado)
  
  11 de Julho de 2012, 9:16
  
  Olá Victor,
  O ca_smoothing se encontra nesse repositório [1]. Você tem que compilar e copiar os arquivos ca_smoothing.py, _ca_smoothing.so e libca_smoothing.so para dentro da pasta data.No Windows, talvez não exista esse arquivo _ca_smoothing.so, deve haver um correspondente.
  Interessante sabe esse problema do PIL com o Python 2.6 e como resolvê-lo. Acredito que seja apenas necessário um if, ou um try, como você disse. Eu vou dar uma olhada nisso.
  Abraço.
  [1] - github.com/tfmoraes/context_aware_smoothing

Discussões
Blog
Feed do Repositório

Tutorial passo-a-passo sobre uso do software InVesalius 3

17 de Abril de 2010, 11:45, por Desconhecido

Se você tem interesse em utilizar o software de reconstrução 3D de imagens médicas InVesalius, mas não sabe por onde começar, acesse já o tutorial escrito pelo designer Cícero Moraes:

sem comentários ainda Leia mais

InVesalius 3 Beta 2 disponível

6 de Março de 2010, 11:41, por Desconhecido

Para saber mais sobre o InVesalius 3.0.0 Beta 2, leia:
http://svn.softwarepublico.gov.br/trac/invesalius/wiki/releases/pt/changelog

Continue contribuindo com a Comunidade InVesalius!

------------------------------------

sem comentários ainda Leia mais

Siga cada passo do InVesalius com o Twitter!

8 de Fevereiro de 2010, 9:57, por Desconhecido

Acompanhar o InVesalius pelo Twitter permitirá que você saiba, em primeira mão, sobre:

sem comentários ainda Leia mais

InVesalius 3 Beta 1 disponível para testes em Windows e GNU Linux

27 de Janeiro de 2010, 10:50, por Desconhecido

sem comentários ainda Leia mais

Trabalho acadêmico discute aplicação do OpenBRR ao InVesalius

6 de Novembro de 2009, 16:35, por Desconhecido

Autor: Tatiana Al-Chueyr Pereira Martins

sem comentários ainda Leia mais