<div dir="ltr">Thanks! I'll test the patch tonight.<div><br><div style>-Kedar</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 17, 2013 at 2:13 PM, Matt McCormick <span dir="ltr"><<a href="mailto:matt.mccormick@kitware.com" target="_blank">matt.mccormick@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Awesome, thanks Mark.<br>
<br>
I have pushed the fixes up as Patch Set 3 if you want to test them, Kedar:<br>
<br>
<a href="http://review.source.kitware.com/#/c/9450/" target="_blank">http://review.source.kitware.com/#/c/9450/</a><br>
<br>
Thanks,<br>
Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Apr 17, 2013 at 3:58 PM, Mark Hiner <<a href="mailto:hiner@wisc.edu">hiner@wisc.edu</a>> wrote:<br>
> Hi Kedar,<br>
><br>
> I was wrong about the dimensions being off. The itkSCIFIOImageIOTest uses<br>
> a streaming reader with a default of 4 divisions, thus the size 512 y is<br>
> correct.<br>
><br>
> So it's just that the pixel size was being computed incorrectly. I was<br>
> mapping SCIFIO and ITK pixel/component types incorrectly. Fixed that, and<br>
> now this conversion test works for me locally.<br>
><br>
> Matt: Curtis said you handled merging work to the SCIFIO branch before. I<br>
> sent a request for push access to ITK.git but you could also just update<br>
> <a href="http://review.source.kitware.com/#/c/9450/" target="_blank">http://review.source.kitware.com/#/c/9450/</a> with the code from my<br>
> scifio-fixes branch.<br>
><br>
> Anyway, just let me know if you'd like me to do anything to merge my code<br>
> back to the ITK repo.<br>
><br>
> I'm considering the SCIFIOImageIO fixed for now. I still want to make both<br>
> the c++ and java code prettier more manageable, but I don't think I have<br>
> time to work on that right now, since they're non-functional improvements.<br>
><br>
> Please let me know if you come across any more bugs though!<br>
><br>
> Thanks again,<br>
> Mark<br>
><br>
><br>
> On Wed, Apr 17, 2013 at 2:32 AM, Kedar Grama <<a href="mailto:gbkedar@gmail.com">gbkedar@gmail.com</a>> wrote:<br>
>><br>
>> Hi Mark,<br>
>><br>
>> I turned on the following flags<br>
>> ITK_USE_64BITS_IDS<br>
>> ITK_USE_REVIEW<br>
>> and compiled in Release mode on both windows and linux.<br>
>><br>
>> Thanks,<br>
>><br>
>> -Kedar<br>
>><br>
>><br>
>> On Tue, Apr 16, 2013 at 9:28 PM, Mark Hiner <<a href="mailto:hinerm@gmail.com">hinerm@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Kedar,<br>
>>><br>
>>>><br>
>>>> I just wanted to send a quick note saying that I know Mark is working on<br>
>>>> this problem. He told me earlier today that he had managed to duplicate the<br>
>>>> bug (after initial unsuccessful efforts). He will reply back once he has<br>
>>>> more information.<br>
>>><br>
>>><br>
>>> Just wanted to confirm that I did reproduce the bug. Thanks for verifying<br>
>>> it works with the normal BF command line tools. I'm hoping it's just a<br>
>>> problem with the ITKBridgePipes java code.<br>
>>><br>
>>> Looking at the error handling at line 746:<br>
>>><br>
>>> errorMessage += std::string( pipedata, pipedatalength );<br>
>>><br>
>>> since the keepReading flag isn't changed here, I was thinking that it<br>
>>> could be eating Java exceptions and then hangs waiting for input that never<br>
>>> comes, because the Java side has crashed.<br>
>>><br>
>>> Anyway I can't finish testing this tonight because I ruined my ITK<br>
>>> install and don't have time to rebuild w/ tests. So I will investigate<br>
>>> tomorrow morning.<br>
>>><br>
>>> Side note - do you adjust any of the cmake flags with your build?<br>
>>><br>
>>> Thanks,<br>
>>> Mark<br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>