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
We have a problem whereby, if we simply load a 2D RGB image (e.g. .jpg, .png), and simply click in the image in the MITK Display main window, we get an error: > Description: Invalid ImageAccessor: PixelTypes of Image and > ImageAccessor are not equal However, on MITK master, it’s fixed. It looks related to issues 19235, 19204, and commits >>>> https://github.com/MITK/MITK/commit/6e0b442 >>>> https://github.com/MITK/MITK/commit/ff9b647 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 > Begin forwarded message: > > From: Miklos Espak <esp...@gmail.com> > Subject: Re: Pixel Access on 2D image > Date: 23 January 2017 18:25:24 GMT > To: "Clarkson, Matt" <m.clark...@ucl.ac.uk> > > 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 > some printouts, I got this: > > #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 > #26.990# ERROR: made pixel type (itk image), pixel type as string: > #26.990# ERROR: made pixel type (itk image), component type as string: > unsigned_char > #26.990# ERROR: made pixel type (itk image), type as string: (unsigned_char) > #26.990# ERROR: made pixel type (itk vector image) pixel type as string: > #26.990# ERROR: made pixel type (itk vector image) component type as > string: unsigned_char > #26.990# ERROR: made pixel type (itk vector image) type as string: > (unsigned_char) > #26.990# ERROR: An error occurred: MITK Exception: > > 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 > > > On 23 January 2017 at 09:14, Clarkson, Matt <m.clark...@ucl.ac.uk> wrote: >> Oh well. I tried. Can’t look at it now until at least Wednesday. >> M >> >> >>> On 23 Jan 2017, at 08:51, Miklos Espak <esp...@gmail.com> wrote: >>> >>> These are among the commits that I cherry-picked on Nov 3. >>> >>> https://github.com/NifTK/MITK/commits/niftk-2015.05.2?after=Y3Vyc29yOpjeoG6Ihss0nhClxrhEqbskZcFnKzM0 >>> >>> >>> >>> On 23 January 2017 at 08:34, Clarkson, Matt <m.clark...@ucl.ac.uk> wrote: >>>> What about: >>>> >>>> https://github.com/MITK/MITK/commit/6e0b442 >>>> https://github.com/MITK/MITK/commit/ff9b647 >>>> >>>> Joseph Gorres >>>> >>>>> On 22 Jan 2017, at 22:46, Miklos Espak <esp...@gmail.com> wrote: >>>>> >>>>> It looks like these issues: >>>>> >>>>> 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. >>>>> >>>>> >>>>> On 22 January 2017 at 19:41, Clarkson, Matt <m.clark...@ucl.ac.uk> wrote: >>>>>> MitkWorkbench 2016.03 is ok. >>>>>> >>>>>> M >>>>>> >>>>>> >>>>>>> On 22 Jan 2017, at 19:31, Miklos Espak <esp...@gmail.com> wrote: >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> On Sun, 22 Jan 2017, 7:25 p.m. Clarkson, Matt, <m.clark...@ucl.ac.uk> >>>>>>> wrote: >>>>>>> Yeah. 3D is fine. Im only talking about 2D, so, stuff like .jpg and .png >>>>>>> >>>>>>> M >>>>>>> >>>>>>> >>>>>>>> On 22 Jan 2017, at 19:22, Miklos Espak <esp...@gmail.com> wrote: >>>>>>>> >>>>>>>> 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? >>>>>>>> >>>>>>>> >>>>>>>> On Sun, 22 Jan 2017, 7:09 p.m. Clarkson, Matt, <m.clark...@ucl.ac.uk> >>>>>>>> wrote: >>>>>>>> Wierd, >>>>>>>> >>>>>>>> I literally launch NiftyView, load a 2D image, an click on the image. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 22 Jan 2017, at 17:35, Miklos Espak <esp...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> NiftyIGI? >>>>>>>>> >>>>>>>>> I ran NiftyView and tested the interactions, it didn't do this. I >>>>>>>>> would also check which plugins are loaded. >>>>>>>>> >>>>>>>>> On Sun, 22 Jan 2017, 5:32 p.m. Miklos Espak, <esp...@gmail.com> wrote: >>>>>>>>> niftk-2015.05.2 branch, go back to nov 3 in the history. second page >>>>>>>>> on github. >>>>>>>>> >>>>>>>>> On Sun, 22 Jan 2017, 5:28 p.m. Clarkson, Matt, <m.clark...@ucl.ac.uk> >>>>>>>>> wrote: >>>>>>>>> This is on first start up, without doing anything. >>>>>>>>> The first click fails. >>>>>>>>> >>>>>>>>> Can you pick out the commits? >>>>>>>>> >>>>>>>>> M >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 22 Jan 2017, at 10:53, Miklos Espak <esp...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 22 January 2017 at 06:52, Clarkson, Matt <m.clark...@ucl.ac.uk> >>>>>>>>>> wrote: >>>>>>>>>>> Hi there, >>>>>>>>>>> >>>>>>>>>>> In MITK Display, if I click on a 2D image (colour jpg or png), I >>>>>>>>>>> get an >>>>>>>>>>> error: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Line 87 in mitkImagePixelAccessor. >>>>>>>>>>> >>>>>>>>>>> Has anything change in our MITK fork in this area? >>>>>>>>>>> >>>>>>>>>>> M >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
