Clarkson, Matt
2017-01-24 10:11:45 UTC
Hi All,
our MITK fork is equivalent to MITK-2015.05.2 with cherry-picked updates.
https://github.com/NifTK/MITK/commits/niftk-2015.05.2
It looks related to issues 19235, 19204, and commits
but we have already cherry-picked those commits, and the problem persists. Unfortunately we are not ready or able to fully update to the latest MITK master.
Can anyone remember what the issue was, and what the fix was, as this could save me time debugging. :-)
Thanks
Matt
our MITK fork is equivalent to MITK-2015.05.2 with cherry-picked updates.
https://github.com/NifTK/MITK/commits/niftk-2015.05.2
Description: Invalid ImageAccessor: PixelTypes of Image and
ImageAccessor are not equal
However, on MITK master, it’s fixed.ImageAccessor are not equal
It looks related to issues 19235, 19204, and commits
https://github.com/MITK/MITK/commit/6e0b442
https://github.com/MITK/MITK/commit/ff9b647
https://github.com/MITK/MITK/commit/ff9b647
Can anyone remember what the issue was, and what the fix was, as this could save me time debugging. :-)
Thanks
Matt
Subject: Re: Pixel Access on 2D image
Date: 23 January 2017 18:25:24 GMT
I could not find it.
It probably works in the MitkWorkbench from 2015.05.2 as well because
version that did not use the pixel accessor.
In the condition before throwing the error, "image->GetPixelType()"
returns rgba, but on the right side the pixel type is empty. I added
#26.900# ERROR: The error was ignored by the user. The program may be
in a corrupt state and don't behave like expected!
[26.990] operator==
[26.990] m_NumberOfComponents = 4 1
[26.990] m_BytesPerComponent = 1 1
[26.990] m_PixelTypeName = rgba
[26.990] m_PixelType = 3 1
[26.990] [FALSE]
[26.990] operator==
[26.990] m_NumberOfComponents = 4 4
[26.990] m_BytesPerComponent = 1 1
[26.990] m_PixelTypeName = rgba
[26.990] m_PixelType = 3 5
[26.990] [FALSE]
#26.990# ERROR: image pixel type, pixel type as string: rgba
#26.990# ERROR: image pixel type, component type as string: unsigned_char
#26.990# ERROR: image pixel type as string: rgba
unsigned_char
#26.990# ERROR: made pixel type (itk image), type as string: (unsigned_char)
#26.990# ERROR: made pixel type (itk vector image) component type as
string: unsigned_char
(unsigned_char)
Description: Invalid ImageAccessor: PixelTypes of Image and
ImageAccessor are not equal
Filename: /build/src/niftk-debug/MITK/src/Modules/Core/include/mitkImagePixelAccessor.h
I do not see any changes on the MITK master in this regards. The only
thing is that in 2015.05 they updated the pixel value on the status
bar from four places (slice navigator, image navigator, display
interactor and qmitkstdmultiwidget), and now they update it only from
qmitkstdmultiwidget. But the call from there is the same.
Also thought that we might use a different reader to read the 2D
images than MITK. E.g. we register the ITK png reader, but maybe MITK
does not. And maybe this results in different pixel type strings. But
I checked and I got the same if I commented out registering the png
reader.
I ran out of ideas. If this is an urgent and important issue, we could
revert to using the deprecated function
(mitk::Image::GetPixelValueByIndex() if I remember well) until the
MITK upgrade.
Miklos
Date: 23 January 2017 18:25:24 GMT
I could not find it.
It probably works in the MitkWorkbench from 2015.05.2 as well because
version that did not use the pixel accessor.
In the condition before throwing the error, "image->GetPixelType()"
returns rgba, but on the right side the pixel type is empty. I added
#26.900# ERROR: The error was ignored by the user. The program may be
in a corrupt state and don't behave like expected!
[26.990] operator==
[26.990] m_NumberOfComponents = 4 1
[26.990] m_BytesPerComponent = 1 1
[26.990] m_PixelTypeName = rgba
[26.990] m_PixelType = 3 1
[26.990] [FALSE]
[26.990] operator==
[26.990] m_NumberOfComponents = 4 4
[26.990] m_BytesPerComponent = 1 1
[26.990] m_PixelTypeName = rgba
[26.990] m_PixelType = 3 5
[26.990] [FALSE]
#26.990# ERROR: image pixel type, pixel type as string: rgba
#26.990# ERROR: image pixel type, component type as string: unsigned_char
#26.990# ERROR: image pixel type as string: rgba
unsigned_char
#26.990# ERROR: made pixel type (itk image), type as string: (unsigned_char)
#26.990# ERROR: made pixel type (itk vector image) component type as
string: unsigned_char
(unsigned_char)
Description: Invalid ImageAccessor: PixelTypes of Image and
ImageAccessor are not equal
Filename: /build/src/niftk-debug/MITK/src/Modules/Core/include/mitkImagePixelAccessor.h
I do not see any changes on the MITK master in this regards. The only
thing is that in 2015.05 they updated the pixel value on the status
bar from four places (slice navigator, image navigator, display
interactor and qmitkstdmultiwidget), and now they update it only from
qmitkstdmultiwidget. But the call from there is the same.
Also thought that we might use a different reader to read the 2D
images than MITK. E.g. we register the ITK png reader, but maybe MITK
does not. And maybe this results in different pixel type strings. But
I checked and I got the same if I commented out registering the png
reader.
I ran out of ideas. If this is an urgent and important issue, we could
revert to using the deprecated function
(mitk::Image::GetPixelValueByIndex() if I remember well) until the
MITK upgrade.
Miklos
Oh well. I tried. Can’t look at it now until at least Wednesday.
M
M
These are among the commits that I cherry-picked on Nov 3.
https://github.com/NifTK/MITK/commits/niftk-2015.05.2?after=Y3Vyc29yOpjeoG6Ihss0nhClxrhEqbskZcFnKzM0
https://github.com/NifTK/MITK/commits/niftk-2015.05.2?after=Y3Vyc29yOpjeoG6Ihss0nhClxrhEqbskZcFnKzM0
https://github.com/MITK/MITK/commit/6e0b442
https://github.com/MITK/MITK/commit/ff9b647
Joseph Gorres
https://github.com/MITK/MITK/commit/ff9b647
Joseph Gorres
https://phabricator.mitk.org/T19235
https://phabricator.mitk.org/T19204
But they do not say what was the fix. They closed them because at some
point it did not appear on master any more.
https://phabricator.mitk.org/T19204
But they do not say what was the fix. They closed them because at some
point it did not appear on master any more.
MitkWorkbench 2016.03 is ok.
M
M
I see. Next I would do is checking if the same happens with the MitkWorkbench. If not then they fixed it already and we just need to cherry pick some more commits.
Yeah. 3D is fine. Im only talking about 2D, so, stuff like .jpg and .png
M
Yeah. 3D is fine. Im only talking about 2D, so, stuff like .jpg and .png
M
Are 3D images OK? I didn't try 2D images. Maybe it's a bug that the reader stays in memory and keeps a pointer to the image? I tested with nifti and maybe analyze. Did you use png?
Can you confirm that nifti is ok?
Wierd,
I literally launch NiftyView, load a 2D image, an click on the image.
Can you confirm that nifti is ok?
Wierd,
I literally launch NiftyView, load a 2D image, an click on the image.
NiftyIGI?
I ran NiftyView and tested the interactions, it didn't do this. I would also check which plugins are loaded.
niftk-2015.05.2 branch, go back to nov 3 in the history. second page on github.
This is on first start up, without doing anything.
The first click fails.
Can you pick out the commits?
M
I ran NiftyView and tested the interactions, it didn't do this. I would also check which plugins are loaded.
niftk-2015.05.2 branch, go back to nov 3 in the history. second page on github.
This is on first start up, without doing anything.
The first click fails.
Can you pick out the commits?
M
Yes, I cherry-picked a few changes from the MITK master on Nov 3, to
get the fixes for the status bar update.
https://github.com/NifTK/MITK/commits/niftk-2015.05.2?after=Y3Vyc29yOpjeoG6Ihss0nhClxrhEqbskZcFnKzM0
But I also tested the the interactions in the MITK Display (especially
scrolling).
I assume that there is another plugin that puts a write lock on the
image, and does not release it, and the image is being locked when you
click in the image. Check if you really need the write lock, or read
lock would be enough. If read lock is enough, check the const-ness of
the image arguments in the ItkAccess functions, because the constness
determines whether read or write lock is applied.
Before the change the pixel access was done by a deprecated function,
that did not use locking. It gave compiler warning.
get the fixes for the status bar update.
https://github.com/NifTK/MITK/commits/niftk-2015.05.2?after=Y3Vyc29yOpjeoG6Ihss0nhClxrhEqbskZcFnKzM0
But I also tested the the interactions in the MITK Display (especially
scrolling).
I assume that there is another plugin that puts a write lock on the
image, and does not release it, and the image is being locked when you
click in the image. Check if you really need the write lock, or read
lock would be enough. If read lock is enough, check the const-ness of
the image arguments in the ItkAccess functions, because the constness
determines whether read or write lock is applied.
Before the change the pixel access was done by a deprecated function,
that did not use locking. It gave compiler warning.
Hi there,
In MITK Display, if I click on a 2D image (colour jpg or png), I get an
Line 87 in mitkImagePixelAccessor.
Has anything change in our MITK fork in this area?
M
In MITK Display, if I click on a 2D image (colour jpg or png), I get an
Line 87 in mitkImagePixelAccessor.
Has anything change in our MITK fork in this area?
M