Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for 'JPX' not declared #8

Open
mattcg opened this issue Nov 9, 2016 · 4 comments
Open

Support for 'JPX' not declared #8

mattcg opened this issue Nov 9, 2016 · 4 comments

Comments

@mattcg
Copy link

mattcg commented Nov 9, 2016

The ReaderSpi and WriterSpi classes should declare support for JPX format images, otherwise these are not handled by PDFBox and in turn, Tika, for example.

It's a matter of adding 'jpx' to formatNames and extensions and 'image/jpx' to mimeTypes.

mattcg added a commit to ICIJ/extract that referenced this issue Nov 9, 2016
1) using maven-shade instead of maven-assembly so that META-INF/services files are merged
(previously, because all the imageio libs have to use the same file name, only one was
being included)

2) because the jai-imageio JPEG2000 package didn't declare support for JPX, a proxy Spi
class had to be added to declare it

3) TesseractOCRParser doesn't declare support for JPEG2000 images either, even though
Tesseract with Leptonica compiled with jp2 support will handle these, so an additional
parser was added to handle these files

Issues filed:

jai-imageio/jai-imageio-jpeg2000#8
https://issues.apache.org/jira/browse/TIKA-2174
@stain
Copy link
Member

stain commented Jan 18, 2017

I am not so sure if the J2KWriter even supports reading or writing JPX (JPEG 2000 Part 2, ISO 15444-2).. were you able to verify that with a test resource?

Would you be able to supply a pull request with a similar change as in 0e912afd3658d0d1aff336056ee4f472e79ba78d?

I see you depend on this dependency - would that be needed for JPX instead of our bundled jj2000 code?

		<dependency>
				<groupId>edu.ucar</groupId>
				<artifactId>jj2000</artifactId>
				<version>5.3</version>
		</dependency>

(It is not in Maven Central.. :-/)

I think JPX could be registered a separate ImageReaderSpi instance (you can have as many as you want) which only deals with jpx and image/jp2, rather than munging them together, as it is a derived format rather than the same format.

@mattcg
Copy link
Author

mattcg commented Jan 18, 2017

Yes, I will happily make that pull request.

Would you consider using Unidata's jj2000 fork instead of the one you currently bundle?

5.3 is available on their repo.

@stain
Copy link
Member

stain commented Jan 26, 2017

Yes, that could be a good option - except that it resides in the http://repo.boundlessgeo.com/ repository - I can't (or shouldn't) publish to Maven Central with dependencies on an external repository - these tend to disappear or hang after a year or two. (See for example Codehaus).

Are there license reasons why Unidata's fork can't go into Maven Central?

The J2000 license is quite restrictive because of the patent clause - if I switch to using an external reference implementation I would not want to shade it inside the JAR (an easy workaround to avoid repo at runtime), as that would mean my employer could be sued for patent infringement if the fork is no longer JPEG2000 compliant!

As I have not touched the jj2000 branch here in any functional way, then I can currently just redirect any such legal action towards Oracle, which provided this reference implementation from java.net.

If the forked implementation JAR was accessible from say Maven Central or BinTray, then I would be fairly happy with it being available in the future, and could use it just as a <dependency>. I would be OK to publish jai-imageio-jpeg2000 to just BinTray instead of Maven Central if needed.

@mattcg
Copy link
Author

mattcg commented Feb 22, 2017

I've filed Unidata/jj2000#6 to get Unidata's fork published to Maven Central.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants