As an update - its not fixed on MITK master :-( If I download the binary (Im on a Mac), and run from console, the error is still there, its just the dialog box that has disappeared.
Any thoughts? M > Begin forwarded message: > > From: "Clarkson, Matt" <skgt...@ucl.ac.uk> > Subject: Error when clicking on RGBA image > Date: 24 January 2017 10:11:45 GMT > To: MITK <mitk-users@lists.sourceforge.net> > > 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
