[Insight-developers] additional dashboard?

Mon Sep 20 17:20:44 EDT 2010

Hi Luis,

I don't know if we're talking about the same things here.  I'm proposing to
add another itk dashboard (not another gdcm dashboard) after Bill's
commentary on the dashboard looking terrible for itk.  Right now, the
windows dashboards on itk are not building. According to the logs, that's a
failure in openjpeg.cmake, which, as far as I know, is outside of the
responsibility of the gdcm team.  I'm proposing having a separate dashboard
of itk that is done on a system that does not have a separate installation
of openjpeg, since openjpeg appears to be causing so many problems, and
since I can build itk with gdcm without a separate openjpeg installation.
My warning count on windows is different (and producing different warnings)
than those I see on the Linux dashboards, and I think it would be
illustrative to have those on the dashboard.

On Mon, Sep 20, 2010 at 2:03 PM, Luis Ibanez <luis.ibanez at kitware.com>wrote:

> Hi Mark,
>
> On Mon, Sep 20, 2010 at 4:50 PM, Mark Roden <mmroden at gmail.com> wrote:
>
>> Hi Luis,
>>
>> I thought that the problem with redwall and itk at the moment was that
>> openjpeg was interfering with itk compilation on windows, in that the
>> openjpeg.cmake file is failing.
>>
>>
>
> Yes,...
>
> but the fact is that GDCM should NOT even be looking
> for other builds of openjpeg, since this ITKv4 does not
> have enabled the flag:  GDCM_USE_SYSTEM_OPENJPEG
>

Again, this is the log of the itk dashboard build, not the gdcm dashboard
build.  I have no idea what the linkage is to openjpeg; I am able to build
gdcm independently of itk, and Mathieu can explain far better than I can how
openjpeg, itk, and gdcm all interact.

>
> See: ITK/Utilities/gdcm/ CMakeLists.txt: line 277
> OPTION(GDCM_USE_SYSTEM_OPENJPEG "Use system openjpeg (1.x)" OFF)
>
>
> Was I wrong on that?  If I were to do an itk dashboard, it wouldn't be with
>> an openjpeg installation, because of all the extra problems that appear to
>> be introduced by that.
>>
>>
> Ignoring the problem is not going to make it go away:
> That only "works" in the close-source world   :-)
>

Only until your customer asks for a refund, and you have give up that shiny
new GI Joe with the kung fu grip :)

In all seriousness, though, I was just proposing to add my machine to the
itk dashboard mix to have a system that does not also have a separate
openjpeg installation, not as a way of ignoring the problem, but as a way of
having another build alternative.

>
> The whole purpose of Dashboard build is to catch errors
> and solve them. No to make the Dashboards look pretty.
>

Sure.  So I guess I should wait on my proposal then?

>
> If a given configuration is failing, that's the one that you
> should target, solve, and then.... the Dashboard will be
> pretty.
>

But I don't know how to fix openjpeg :)  I want to see what other problems
there are on the windows builds once the openjpeg.cmake issue will be
resolved.

>
>
>
> I can start cc'ing the list; the initial message didn't go on the list, so
>> I didn't know if there was a protocol or something about side channel
>> discussions.
>>
>> Mark
>>
>>
> <snip>But this new thread
> that you started, should be copied to the Developers
> list.  Please see that Bill is expecting you two guys
> to do something about this problem, and if you don't
> communicate with the developers team, they will
> simply think that you are ignoring the problem.
>
> (which in Open Source is a really bad thing to do...)
>

I'm cc'ing the list on this one.

Here is also a response that Mathieu and I put together addressing the
failing tests in gdcm in ITK.  As a summation, they are mainly the fault of
going to openjpeg v2 as opposed to staying with openjpeg v1.
---------------
Hi all,

Mathieu and I wanted to share our thougths on the failing tests on
macosx-cross-rosetta dashboard, which is a superset of the failing tests.

itkDicomImageIOTest:  This test is a demonstration that gdcm2 is not working
properly for big endian systems.  However, the bug is difficult to track
down, and effort is being spent to track it down.  Our current best guess is
that there are discrepancies in the DICOM standard regarding handling of Big
Endian byte ordering, and we are investigating both gdcm and dcmtk's
handling of this test.

itkGDCMImageIOTest5:  OpenJPEG refuses to compress images smaller than
64x64, and there is such an image in the ITK Test Suite.  This bug has been
replicated in itkJPEG2000Test05; once that bug is fixed (or this small image
removed from this test), then this test should pass.

itkGDCMSeriesStreamReadImageWrite3 and 4:  These tests expect that the image
spacing tag be set.  However, it is important to realize that DICOM is NOT
an image format, but it is a medical data format, most commonly used for
images.  Therefore, this tag may or may not be defined in a given image.  In
fact, this tag only has meaning in certain modalities, and not in others.
Pixel spacing is not defined for secondary capture, ie, images converted
from a non-DICOM format to a DICOM format do not have this tag; there is no
pixel spacing in a screenshot or in a jpeg image.  Additionally, images
captured with ultrasound should not have this tag defined, as the concept of
pixel spacing does not coincide with the physics behind image acquisition.
Therefore, we strongly suggest that these tests should be performed using
only MR or CT images, as these are the only images that have this tag
defined.  This test only fails on the Mac Rosetta dashboard because it's
only currently being run on the Mac dashboards.

ITK requires that an image have pixel spacing, even if that spacing has no
physical meaning.  As such, gdcm should (and does) return a pixel spacing of
(1,1) in order to meet this requirement.

itkImageFileWriterStreamingPastingCompressingTest_DCM:  Again, this is a
failure in OpenJPEG, and replicated in itkJPEG2000Test06.  Jpeg2000 has both
lossless and lossy compression, and v2 is currently failing to losslessly
compress cthead1.j2k.  This file was properly handled in v1.
All the remaining failures are jpeg 2000 tests:
itkJPEG2000Test00
itkJPEG2000Test01
itkJPEG2000Test02
itkJPEG2000Test03

Our best guess is that these tests don't work on Big Endian machines, as
these tests work on Intel machines.  However, we do not think that this is a
blocking issue for the Intel-based machines used by the majority of the itk
community.

Please note that Mathieu has contacted the OpenJPEG group about these
issues, and has received no response.  He has also run these tests using
kakadu, an alternative Jpeg2000 implementation, and the tests were
successful.

We are working on the warnings at the moment.  We agree that the warning
count is high, and we certainly want to bring them under control.

Best regards,
Mark

>
>
>     Luis
>
>
>  ---------------------------------
>
>> On Mon, Sep 20, 2010 at 1:46 PM, Luis Ibanez <luis.ibanez at kitware.com>wrote:
>>
>>> BTW: It will be nice to copy the developers list in
>>> all emails. For one thing it shows that you guys
>>> are doing your best to take care of the dashboard
>>> problems.
>>>
>>>
>>>     My 2 cents,
>>>
>>>
>>>         Luis
>>>
>>>
>>> --------------------------------------
>>> On Mon, Sep 20, 2010 at 2:44 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>
>>>> Hi Luis,
>>>>
>>>> Is it worth it to have me add some itk dashboards alongside of my gdcm
>>>> dashboards?  I'm seeing that you're still having openjpeg.cmake issues on
>>>> the redwall dashboards, and remember you saying that that was happening
>>>> because of multiple openjpeg installation conflicts.
>>>>
>>>> I'd like to get those up and running, if only so that we can get the
>>>> dashboards to look nicer.
>>>>
>>>> Thanks,
>>>> Mark
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100920/a93a7f4b/attachment.htm>