Ocorreu-me que o conjunto de dados do elipsóide mudou. Alguém pode explicar a diferença entre "v0" e "v1"? O ShapeWorks 5.5 não tem um desempenho melhor no conjunto de dados / parâmetros do elipsóide atual. @sheryjoe @ jadie1 @ iyerkrithika21

@akenmorris "v1" são os conjuntos de dados de elipsóide não tratados gerados usando o ShapeCohortGenPackage. Inclui todos os seguintes modos de variações e opções para gerações:

1. raios aleatórios
2. orientação aleatória
3. algumas segmentações que tocam limites
4. centros randomizados
5. randomize o tamanho das imagens para incluir mais fundo

Considerando que o antigo conjunto de dados tinha apenas um modo de variação, eu suponho. @ jadie1 , corrija-me se eu estiver errado em relação à v0.

@ jadie1 Concordamos antes em fornecer dois conjuntos de dados elipsóide, um alinhado (semelhante a v0) e um não alinhado (para demonstrar o aliciamento). Acho que v1 é o último.

Sim, elipsóide-v1 é como @ iyerkrithika21 descreveu, então deve ter mais de um modo de variação. elipsóide-v0 são os dados originais para os quais a versão não tratada é igual à preparada.
Também adicionamos ellipsoid_aligned-v1 que foi gerado usando o código de geração de coorte da mesma forma que o ellipsoid-v1, mas já está alinhado (centro, orientação e tamanho da imagem são os mesmos). A diferença entre elipsoid-v0 e ellipsoid_aligned-v1 é elipsóide-v0 tem apenas um modo de variação, enquanto ellipsoid_aligned-v1 varia ao longo de todos os raios.

Sim, elipsóide-v1 é como @ iyerkrithika21 descreveu, então deve ter mais de um modo de variação. elipsóide-v0 são os dados originais para os quais a versão não tratada é igual à preparada.

Por que a v1 deve ter mais modos? O caso de uso para esses dados deve considerar os modos relacionados ao desalinhamento.

Também adicionamos ellipsoid_aligned-v1 que foi gerado usando o código de geração de coorte da mesma forma que o ellipsoid-v1, mas já está alinhado (centro, orientação e tamanho da imagem são os mesmos). A diferença entre elipsoid-v0 e ellipsoid_aligned-v1 é elipsóide-v0 tem apenas um modo de variação, enquanto ellipsoid_aligned-v1 varia ao longo de todos os raios.

Isso está se tornando um pouco confuso. Precisamos manter dois dados elispoides alinhados, um com um modo e outro com três modos? Acho que o alinhado deve ter apenas um modo (escolha um raio para variação), pois este é suposto ser o exemplo de brinquedo mais simples para a otimização.

Independentemente do alinhamento ou do número de modos de variação, este conjunto de parâmetros mostra correspondência e amostragem inadequadas:

Sim, elipsóide-v1 é como @ iyerkrithika21 descreveu, então deve ter mais de um modo de variação. elipsóide-v0 são os dados originais para os quais a versão não tratada é igual à preparada.

Por que a v1 deve ter mais modos? O caso de uso para esses dados deve considerar os modos relacionados ao desalinhamento.

Como o raio varia ao longo de todos os três eixos, deve haver mais modos de variação, certo?

Também adicionamos ellipsoid_aligned-v1 que foi gerado usando o código de geração de coorte da mesma forma que o ellipsoid-v1, mas já está alinhado (centro, orientação e tamanho da imagem são os mesmos). A diferença entre elipsoid-v0 e ellipsoid_aligned-v1 é elipsóide-v0 tem apenas um modo de variação, enquanto ellipsoid_aligned-v1 varia ao longo de todos os raios.

Isso está se tornando um pouco confuso. Precisamos manter dois dados elispoides alinhados, um com um modo e outro com três modos? Acho que o alinhado deve ter apenas um modo (escolha um raio para variação), pois este é suposto ser o exemplo de brinquedo mais simples para a otimização.

Posso remover ellipsoid_aligned-v1 ou ellipsoid-v0. Não temos casos de uso que usam ambos, eu apenas deixei ellpsoid-v0 para usuários que usam versões mais antigas do ShapeWorks. Esta foi a solicitação original para criar ellpsoid_aligned-v1: "Podemos regenerar v0 usando o mesmo código que v1 desabilitando todas as transformações? Desta forma, mantemos a consistência e temos segmentações e boas malhas para testar tanto para domínios fixos quanto planos de corte."

Não sei por que o modelo tem correspondência pobre. Eu acho que os parâmetros precisam ser reajustados? Devo tentar com novos elipsóides que variam apenas ao longo de um raio?

O aliciamento também tem problemas:

Observe que o elipsóide 9 nem mesmo está centralizado com os outros.

Este é um problema no exemplo do elipsóide ou na biblioteca de imagens? @cchriste @archanasri @ jadie1 @ iyerkrithika21

É assim que os elipsóides preparados me procuram no Windows e no Linux.
O elipsóide 9 parece centralizado para mim.

Parece centrado para mim também - basta executá-lo novamente no branch release_v6.0

Os pontos de correspondência também não parecem bons para mim, talvez precise de mais suavização? Para mim, parece que existem quatro modos de variação - o primeiro é o tamanho e os próximos três são raios nas direções x, y e z.

@ jadie1 , @ iyerkrithika21 , acabei de experimentar em um Mac diferente, nova instalação do shape funciona 6.0 RC5, nova instalação do conda, tudo. Observe o alinhamento das amostras (nem mesmo é necessário olhar para os DTs):

https://user-images.githubusercontent.com/1693349/110035220-9c3e6300-7cf8-11eb-9cd0-9162212dd61c.mp4

Oh, hah, @ jadie1 , @ iyerkrithika21 , você deve desativar a caixa de seleção center no Studio ou ele irá centralizá-los automaticamente para fins de exibição. Por favor, inspecione novamente com a centralização desligada.

Oh sim, eu vejo agora. Acabei de executar o arquivo Getting-started-with-grooming-segmentations.ipynb, que usa os mesmos dados e me parece que tem o mesmo problema, mas não tão ruim. Veja o último vídeo aqui: http://sciinstitute.github.io/ShapeWorks/notebooks/getting-started-with-grooming-segmentations.html (este vídeo corresponde ao que acabei de executar no branch de lançamento).

Acho que poderíamos examinar o caso de uso e o notebook linha por linha e ver onde o tratamento difere ...

Risque se o notebook e as transformações de distância do caso de uso têm o mesmo problema de centro / alinhamento. As transformações de distância do portátil são apenas mais suaves.
@akenmorris você acha que o descentramento pode estar acontecendo porque há uma grande variação no conjunto de dados (tamanho, orientação, raios, etc)?

Eles estão sendo alinhados com o ICP?

Sim, a referência é elipsóide_14

Então você acha que acaba alinhando o elipsóide 9 ao longo de apenas um lado?

Não tenho certeza de como devemos resolver isso. Após o ICP, deve-se aplicar uma operação de centro de massa?

@sheryjoe alguma

@akenmorris qual tradução? Não consigo ver isso no vídeo. Você fez o controle de qualidade da etapa de alinhamento do centro de massa? Além disso, o número de iterações ICP pode ser importante em alguns casos.

Os elipsóides não são centralizados, portanto, necessariamente, o modelo de forma captura a translação.

Os elipsóides não são centralizados, portanto, necessariamente, o modelo de forma captura a translação.

COM deve centralizá-los.

COM deve centralizá-los.

Eu concordo, mas o ICP está descentrando-os para combinar com um lado?

COM deve centralizá-los.

Eu concordo, mas o ICP está descentrando-os para combinar com um lado?

O impacto do ICP deve ser uma tradução mínima do Wrt após COM, a menos que a referência não seja realmente uma forma mediana.

Qual é o status aqui? Alguém está trabalhando nisso? Acho que há dois problemas distintos, os parâmetros de preparação e de otimização.

@ jadie1 @ iyerkrithika21 alguma atualização?

Quando eu preparei as segmentações no Studio, os DTs ficaram assim:

Portanto, parece que o ICP pode estar causando alguns problemas na preparação.

Correto. O elipsóide 9 está centrado antes de:

       """ Apply rigid alignment """
        ref = FindReferenceImage(comFiles)
        alignedFiles = applyRigidAlignment(groomDir + "aligned/segmentations", ref, comFiles)

E depois é descentrado:

@akenmorris quando tento otimizar os elipsóides no Studio sem ICP, recebo esta mensagem.

Tentei 3 níveis diferentes de enchimento - 10,30,50. Mas nada disso ajudou.
E também no caso de uso do python, tentei pular a etapa rigidAlignment e recebo este erro de caixa delimitadora.

############## Cropping ##############
Traceback (most recent call last):
  File "RunUseCase.py", line 94, in <module>
    module.Run_Pipeline(args)
  File "/home/sci/iyerkrithika/ShapeWorks/Examples/Python/ellipsoid.py", line 96, in Run_Pipeline
    croppedFiles = applyCropping(groomDir + "cropped/segmentations", comFiles, comFiles)
  File "/home/sci/iyerkrithika/ShapeWorks/Examples/Python/GroomUtils.py", line 216, in applyCropping
    region = ImageUtils.boundingBox(bbDataList)
ValueError: Image sizes do not match (Output/ellipsoid/groomed/com_aligned/segmentations/ellipsoid_01.isores.center.com.nrrd)

Este erro não faz sentido porque ImageUtils.boundingBox() deve ser capaz de fornecer a maior caixa delimitadora.
@ jadie1 você acha que isso pode estar relacionado ao problema que vimos no caso de uso do fêmur?

@ iyerkrithika21 , você pode me dizer mais sobre como você está executando isso no estúdio? Se eu tivesse que adivinhar com base nos nomes de arquivo nos cantos, você importou as segmentações binárias, ignorou a preparação e clicou em executar? Elas precisam ser transformadas de distância.

@ iyerkrithika21 , você pode me dizer mais sobre como você está executando isso no estúdio? Se eu tivesse que adivinhar com base nos nomes de arquivo nos cantos, você importou as segmentações binárias, ignorou a preparação e clicou em executar? Elas precisam ser transformadas de distância.

Importei as segmentações, rodei o noivo em estúdio. e clicou em otimizar.

Será corrigido para lançamento por meio do problema nº 1133

@ iyerkrithika21 , adicionei um problema para o que você viu:

1134