Jai_imageio in scifio and dcm4chee - conflict

scifio
bio-formats
Tags: #<Tag:0x00007fb885f93c48> #<Tag:0x00007fb885f93860>

#1

Dear All,

I’m working with Ilan Tal (developper) to implement DCM4CHE services into FIJI.
Sadly we have a conflict with ImageIO, SCIFIO/BioFormat use an older version than DCM4CHE.

I copy here Ilan’s email into Fiji mailing list that never recived answer. I think I might be more lucky to find SCIFIO/Bio-format devs to solve that issue.

Our goal is to provide DICOM communication services into Fiji that will add a nice addition to users (especially physcians) to get DICOM transfert from an existing DICOM network, directly into FIJI.

----- Ilan’s Email -------

I am trying to run dcm4chee inside Fiji and have run into a conflict with

scifio. I succeeded to run dcm4chee inside ImageJ with no scifio, and moving

the code to Fiji gave me a conflict.

The problem is jai_imageio which claims to be version 5.1, but is probably

version 1.1 which is well known.

dcm4chee uses jai_imageio-1.2-pre-dr-b04 which is larger than the scifio

version, 1.1MB compared to 1.0MB.

I tried using the scifio 5.1 version, but it failed, most likely because it

is missing the extra 0.1MB of code.

Would it be possible to test if scifio works using the dcm4chee expanded

version of jai_imageio?

That would allow both dcm4chee and scifio to run together.

Thanks,

Ilan

------- end

Thanks,

Salim


#2

Sorry, did not see this post before I replied to the older thread on the ImageJ mailing list.

Actually, it is a conflict with Bio-Formats, not SCIFIO.

SCIFIO’s JAI-ImageIO library, scifio-jai-imageio-1.1.0.jar, is a shadowed version of the JAI ImageIO library, and thus will not conflict with the regular version.

However, the file jars/bio-formats/jai_imageio.jar which is included with Bio-Formats is not shadowed. That is your likely culprit. The best way to fix this is to ask the Bio-Formats team to switch to the shadowed version used by SCIFIO—then you will not have problems with DCH4CHE.

@dgault What do you think?


#3

Hi Salim,

Thanks for raising this issue. The jai_imageio jar provided by Bio-Formats is indeed version 1.1
The reason it shows as version 5.1 is because we actually build our own forked version of the 1.1 code, with some changes (especially around SVS).

From looking into the differences between the two versions it appears that newer jai_imageio jar has split out its JPEG2000 library. I have carried out some quick initial tests by replacing the jars and there were no immediate issues, that being said it was only very quick minimal tests so it would require much more rigorous testing before I could comment further. As we have changes in our forked version of the library these would need to be integrated for any formal solution.

I have created a card on our Trello board to keep track of this issue which you can view here:

David Gault


#4

Hi David,

Thank you so much for you answer and considering updating the library.

Your answer will allow us to continue the Dcm4Che integration into Fiji. Ilan has already built one feature based on Dcm4Che but we can’t release it until that dependency problem will be solved.

So we stay in touch and we will follow your testing and update process,

Thanks,

Salim


#5

Thanks @dgault. I just want to reiterate that I would love to see a unification of these efforts under scifio-jai-imageio. That project was forked from the Bio-Formats version a couple of years ago. But we added the shadowing to avoid these sorts of conflicts. If Bio-Formats also consumed this same library, then we’d be reunified at least for this code, which would be fantastic. This would be similar to how we all use the same SciJava native-lib-loader library now.

Of course, even better would be for the upstream project to accept all the changes needed by Bio-Formats and SCIFIO. Historically, they were unresponsive when @melissa contacted them. But perhaps that has now changed. Definitely worth another mail in that direction.


#6

Just to let you know of my progress, on this machine I have moved jai_imageio-5.1.10.jar out of Fiji.app->jars->bio-formats and replaced it with the dcm4chee version of jai_imageio-1.2-pre-dr-b04.jar.
I haven’t seen any impact on bio formats and the change allows dcm4chee to run properly.

This is a “dirty trick” and every time there is Fiji update the system reminds me that there is a conflict, and do I want to fix it or ignore it? I keep telling it to ignore the conflict but this would be very unsettling for a user who has no idea of the meaning of the warning.

Clearly we need to await a fix on your end.
Thanks,
Ilan


#7

@ilan Your scheme also breaks the support for certain files which use JPEG2000 compression, since the Bio-Formats Image I/O Tools fork has bug-fixes for better JPEG2000 support for the data found in some of those formats (glancing at the code: this could potentially affect CellSens, JPX, ND2 or TIFF).

You can of course upload your modified jai_imageio to your update site, shadowing the Fiji version. And then your users will not get the scary warning. This might be a suitable stopgap until Bio-Formats stops shipping that unshaded fork.


#8

Hi @dgault,

Do you have any update about the update of the imageIO library in bio-format ?
It is now becoming a crutial step in our developpement process and for now if we want to implement these new dicom services we will have to break the Fiji distribution by replacing the current library which is not very safe.

Best regards,

Salim


#9

Hi @Salim_Kanoun,

We are currently performing a lot of internal investigation into the managing of dependencies within the Bio-Formats architecture. In fact there is currently a PR open which would represent the first step in allowing us to begin splitting out these dependencies https://github.com/openmicroscopy/bioformats/pull/2579

The next step from this would be to look into the decoupling of lower level components into separate repositories. The jai-imageio library would one of the initial candidates for this decoupling and although no decisions have yet been made we are currently looking at the possibilities as to how to best split this library out.

I will make sure to keep you up to date as things progress in this regards.

David


#10

As mentioned earlier in this thread, that library has already been decoupled, and is available here:

It should be extremely straightforward for Bio-Formats to simply consume it directly.

Conversely, simply decoupling the Bio-Formats version of this component would not solve the issue, due to package name clashes.


#11

Hi all,

@dgault I saw the new BioFormat release with the internal change for libraries, it is very nice to see that the project of spliting library is progressing.

I think we have met another conflict while we are trying to make a connection between Fiji and Orthanc server :Problem with Orthanc read
It seems also related to the ImageIO library.

Is there a chance that the decoupled ImageJ library proposed by @ctrueden could be used in the next version of Bioformat ?

Best regards,

Salim


#12

Hi @Salim_Kanoun,

thanks for following up on this thread. As you pointed out, part of the last minor release of Bio-Formats 5.3.0 has been dedicated to reviewing our component architecture. The main target of this work was the decoupling of the low-level components i.e. the I/O and the OME model libraries.

Unfortunately, we did not have the time to tackle JAI ImageIO as part of this effort. This library is certainly next in our list to investigate. We will not be modifying the components in the upcoming patch releases of Bio-Formats but we hope to come back to it for the following minor/major release of Bio-Formats.

Best,
Sebastien