rmuller ( Ronald Muller )

started time in 7 hours

0m.webp.zip

The attached webp file is not read and throws the following exception. (With imageio-webp-3.7.0.jar)

javax.imageio.IIOException: Corrupt WebP stream, colorCacheBits < 1 || > 11: 0 at com.twelvemonkeys.imageio.plugins.webp.lossless.VP8LDecoder.readVP8Lossless(VP8LDecoder.java:79) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.readVP8Lossless(WebPImageReader.java:432) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.read(WebPImageReader.java:323) at com.nuix.data.util.image.InputClosingImageReader.read(InputClosingImageReader.java:117) at com.nuix.data.image.ImageIOImageCollection$ImageIOImagePage.getImageThumbnail(ImageIOImageCollection.java:212) at com.nuix.data.image.ImageUtils.getThumbnailFromImageAspect(ImageUtils.java:70) at com.nuix.load.image.ThumbnailDataProcessor.processImpl(ThumbnailDataProcessor.java:69) at com.nuix.load.AbstractDataProcessor.process(AbstractDataProcessor.java:33) at com.nuix.processing.worker.WorkItemHandler.processData(WorkItemHandler.java:302) at com.nuix.processing.worker.WorkItemHandler.handle(WorkItemHandler.java:242) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.processMessage(LoadWorkItemMessageHandler.java:487) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:398) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:182) at com.nuix.processing.worker.Worker.processMessage(Worker.java:543) at com.nuix.processing.worker.Worker.execute(Worker.java:462) at com.nuix.processing.workerlauncher.ThreadWorkerLauncher.lambda$createWorker$1(ThreadWorkerLauncher.java:131) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.lang.Thread.run(Thread.java:834) ; javax.imageio.IIOException: Corrupt WebP stream, colorCacheBits < 1 || > 11: 0 at com.twelvemonkeys.imageio.plugins.webp.lossless.VP8LDecoder.readVP8Lossless(VP8LDecoder.java:79) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.readVP8Lossless(WebPImageReader.java:432) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.read(WebPImageReader.java:323) at com.nuix.data.util.image.InputClosingImageReader.read(InputClosingImageReader.java:117) at com.nuix.data.image.ImageIOImageCollection$ImageIOImagePage.getImageThumbnail(ImageIOImageCollection.java:212) at com.nuix.data.image.ImageUtils.getThumbnailFromImageAspect(ImageUtils.java:70) at com.nuix.load.image.ThumbnailDataProcessor.processImpl(ThumbnailDataProcessor.java:69) at com.nuix.load.AbstractDataProcessor.process(AbstractDataProcessor.java:33) at com.nuix.processing.worker.WorkItemHandler.processData(WorkItemHandler.java:302) at com.nuix.processing.worker.WorkItemHandler.handle(WorkItemHandler.java:242) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.processMessage(LoadWorkItemMessageHandler.java:487) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:398) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:182) at com.nuix.processing.worker.Worker.processMessage(Worker.java:543) at com.nuix.processing.worker.Worker.execute(Worker.java:462) at com.nuix.processing.workerlauncher.ThreadWorkerLauncher.lambda$createWorker$1(ThreadWorkerLauncher.java:131) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.lang.Thread.run(Thread.java:834) ; javax.imageio.IIOException: Corrupt WebP stream, colorCacheBits < 1 || > 11: 0 at com.twelvemonkeys.imageio.plugins.webp.lossless.VP8LDecoder.readVP8Lossless(VP8LDecoder.java:79) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.readVP8Lossless(WebPImageReader.java:432) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.read(WebPImageReader.java:323) at com.nuix.data.util.image.InputClosingImageReader.read(InputClosingImageReader.java:117) at java.desktop/javax.imageio.ImageReader.read(ImageReader.java:938) at com.nuix.data.image.ImageIOImageCollection$ImageIOImagePage.getImage(ImageIOImageCollection.java:183) at com.nuix.load.image.FacialAnalysisProcessor.process(FacialAnalysisProcessor.java:153) at com.nuix.load.image.FacialAnalysisProcessor.processImpl(FacialAnalysisProcessor.java:229) at com.nuix.load.AbstractDataProcessor.process(AbstractDataProcessor.java:33) at com.nuix.processing.worker.WorkItemHandler.processData(WorkItemHandler.java:302) at com.nuix.processing.worker.WorkItemHandler.handle(WorkItemHandler.java:242) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.processMessage(LoadWorkItemMessageHandler.java:487) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:398) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:182) at com.nuix.processing.worker.Worker.processMessage(Worker.java:543) at com.nuix.processing.worker.Worker.execute(Worker.java:462) at com.nuix.processing.workerlauncher.ThreadWorkerLauncher.lambda$createWorker$1(ThreadWorkerLauncher.java:131) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.lang.Thread.run(Thread.java:834) ; javax.imageio.IIOException: Corrupt WebP stream, colorCacheBits < 1 || > 11: 0 at com.twelvemonkeys.imageio.plugins.webp.lossless.VP8LDecoder.readVP8Lossless(VP8LDecoder.java:79) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.readVP8Lossless(WebPImageReader.java:432) at com.twelvemonkeys.imageio.plugins.webp.WebPImageReader.read(WebPImageReader.java:323) at com.nuix.data.util.image.InputClosingImageReader.read(InputClosingImageReader.java:117) at java.desktop/javax.imageio.ImageReader.read(ImageReader.java:938) at com.nuix.data.image.ImageIOImageCollection$ImageIOImagePage.getImage(ImageIOImageCollection.java:183) at com.nuix.load.image.photodna.RobustHashProcessor.processImpl(RobustHashProcessor.java:452) at com.nuix.load.AbstractDataProcessor.process(AbstractDataProcessor.java:33) at com.nuix.processing.worker.WorkItemHandler.processData(WorkItemHandler.java:302) at com.nuix.processing.worker.WorkItemHandler.handle(WorkItemHandler.java:242) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.processMessage(LoadWorkItemMessageHandler.java:487) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:398) at com.nuix.processing.worker.handler.load.LoadWorkItemMessageHandler.handleMessage(LoadWorkItemMessageHandler.java:182) at com.nuix.processing.worker.Worker.processMessage(Worker.java:543) at com.nuix.processing.worker.Worker.execute(Worker.java:462) at com.nuix.processing.workerlauncher.ThreadWorkerLauncher.lambda$createWorker$1(ThreadWorkerLauncher.java:131) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.lang.Thread.run(Thread.java:834) A sample image that this happens on: 0m.webp

created time in a day

startedneo4j/trillion-graph

started time in 6 days

issue commentharaldk/TwelveMonkeys

is ImageIO.getImageReadersByFormatName("jpeg-ls") supported with the jpeg plugin?

Hi @juanbill,

There's no support in the library for JPEG-LS at the moment (JPEG-LS is based on a completely different algorithm than normal JPEG or JPEG-LOSSLESS).

Best regards,

-- Harald K

juanbill

comment created time in 9 days

issue closedharaldk/TwelveMonkeys

is ImageIO.getImageReadersByFormatName("jpeg-ls") supported with the jpeg plugin?

Hi,

I noticed

ImageIO.getImageReadersByFormatName("jpeg-lossless") is supported but wondering if

ImageIO.getImageReadersByFormatName("jpeg-ls")

like this link suggests https://github.com/haraldk/TwelveMonkeys/issues/361

if "jpeg-ls" is supported, what needs to be added gradle to work. the following is what I have added

implementation group: 'com.twelvemonkeys.imageio', name: 'imageio-core', version: '3.7.0'
implementation group: 'com.twelvemonkeys.imageio', name: 'imageio-jpeg', version: '3.7.0'
implementation group: 'com.twelvemonkeys.imageio', name: 'imageio-metadata', version: '3.7.0'

Thanking you guys in advance J.

closed time in 9 days

juanbill

issue openedharaldk/TwelveMonkeys

is ImageIO.getImageReadersByFormatName("jpeg-ls") with the jpeg plugin?

Hi,

I noticed

ImageIO.getImageReadersByFormatName("jpeg-lossless") is supported but wondering if

ImageIO.getImageReadersByFormatName("jpeg-ls")

like this link suggests https://github.com/haraldk/TwelveMonkeys/issues/361

if "jpeg-ls" is supported, what needs to be added gradle to work. the following is what I have added

implementation group: 'com.twelvemonkeys.imageio', name: 'imageio-core', version: '3.7.0'
implementation group: 'com.twelvemonkeys.imageio', name: 'imageio-jpeg', version: '3.7.0'
implementation group: 'com.twelvemonkeys.imageio', name: 'imageio-metadata', version: '3.7.0'

Thanking you guys in advance J.

created time in 9 days

startedrmuller/infomas-asl

started time in 11 days

fork jexp/bloom

Data set for Bloom training

lju-lazarevic/bloom jexp/bloom

fork in 15 days

fork jexp/nodes2021-aura-training

Training materials for NODES 2021 training on Neo4j Aura

JMHReif/nodes2021-aura-training jexp/nodes2021-aura-training

fork in 15 days

issue closedharaldk/TwelveMonkeys

WebP plugin does not correctly apply ICC Profile

Describe the bug WebP plugin does not correctly apply ICC Profile

Version information

The version of the TwelveMonkeys ImageIO library in use. 3.7.0
The exact output of java --version (or java -version for older Java releases).

java version "1.8.0_271" Java(TM) SE Runtime Environment (build 1.8.0_271-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
Extra information about OS version, server version, standalone program or web application packaging, executable wrapper, etc. Please state exact version numbers where applicable.

To Reproduce Steps to reproduce the behavior:

Copy the code to WebPImageReaderTest
Compile the below sample code
Download the sample image file
Run the test
See error

Expected behavior The image should have vibrant colors. The colors are dull

Example code

    @Test
    public void testReadAndApplyICCProfile() throws IOException {
        WebPImageReader reader = createReader();

        try (ImageInputStream stream = ImageIO.createImageInputStream(getClassLoaderResource("/webp/photo-iccp-adobergb.webp"))) {
            reader.setInput(stream);

            // We'll read a small portion of the image into a a destination type that use sRGB
            ImageReadParam param = new ImageReadParam();
            param.setDestinationType(ImageTypeSpecifier.createFromBufferedImageType(BufferedImage.TYPE_3BYTE_BGR));
            param.setSourceRegion(new Rectangle(20, 20));

            BufferedImage image = reader.read(0, param);
            assertRGBEquals("RGB values differ, incorrect ICC profile or conversion?", 0XFFDC9100, image.getRGB(10, 10), 10);
        }
        finally {
            reader.dispose();
        }
    }

Sample file(s) Attach any sample files needed to reproduce the problem. Use a ZIP-file if the format is not directly supported by GitHub.

photo-1525966222134-fcfa99b8ae77.webp.zip

closed time in 20 days

haraldk

push eventharaldk/TwelveMonkeys

Harald Kuhr

commit sha 8f2c482167bc4f80f7f8257f725d70da669dff5c

Minor code clean-up.

view details

Harald Kuhr

commit sha ff50180d866d201c351c31520cc884dbe7b03a47

#609 Fixed ICC Profile handling in WebP.

view details

push time in 20 days

issue openedharaldk/TwelveMonkeys

WebP plugin does not correctly apply ICC Profile

Describe the bug WebP plugin does not correctly apply ICC Profile

Version information

The version of the TwelveMonkeys ImageIO library in use. 3.7.0
The exact output of java --version (or java -version for older Java releases).

java version "1.8.0_271" Java(TM) SE Runtime Environment (build 1.8.0_271-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
Extra information about OS version, server version, standalone program or web application packaging, executable wrapper, etc. Please state exact version numbers where applicable.

To Reproduce Steps to reproduce the behavior:

Copy the code to WebPImageReaderTest
Compile the below sample code
Download the sample image file
Run the test
See error

Expected behavior The image should have vibrant colors. The colors are dull

Example code

    @Test
    public void testReadAndApplyICCProfile() throws IOException {
        WebPImageReader reader = createReader();

        try (ImageInputStream stream = ImageIO.createImageInputStream(getClassLoaderResource("/webp/photo-iccp-adobergb.webp"))) {
            reader.setInput(stream);

            // We'll read a small portion of the image into a a destination type that use sRGB
            ImageReadParam param = new ImageReadParam();
            param.setDestinationType(ImageTypeSpecifier.createFromBufferedImageType(BufferedImage.TYPE_3BYTE_BGR));
            param.setSourceRegion(new Rectangle(20, 20));

            BufferedImage image = reader.read(0, param);
            assertRGBEquals("RGB values differ, incorrect ICC profile or conversion?", 0XFFDC9100, image.getRGB(10, 10), 10);
        }
        finally {
            reader.dispose();
        }
    }

Sample file(s) Attach any sample files needed to reproduce the problem. Use a ZIP-file if the format is not directly supported by GitHub.

photo-1525966222134-fcfa99b8ae77.webp.zip

created time in 20 days

push eventharaldk/TwelveMonkeys

Oliver Schmidtmer

commit sha ba5c667b6c40616bd3091471f55ce0526c057d8e

#579 Deeper EOL search in the CCITT stream

view details

Oliver Schmidtmer

commit sha cd42d81817cdeb1d59c1d0efd8eba2cbf3bb5ff6

Invert EOF check

view details

Harald Kuhr

commit sha eab24890ca6a2ee412dc115789a18715e6b9f5e8

Merge pull request #608 from Schmidor/ccitt_eol_search #579 Deeper EOL search in the CCITT stream

view details

push time in 24 days

PR merged haraldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

I've got other TIFFs which have some junk at the beginning of the CCITT stream, which is even longer than before. In an extrem case almost 300 bytes.

So I propose to increase the read limit for the CCITT type detection even further, but only read on demand till a EOL is found or the limit is reached.

Also relates to #535

+30 -21

2 commit in Schmidor/TwelveMonkeys/tree/ccitt_eol_search haraldk/TwelveMonkeys/tree/master

1 comment

1 changed file

Schmidor

pr closed time in 24 days

Pull request review commentharaldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

 public CCITTFaxDecoderStream(final InputStream stream, final int columns, final     static int findCompressionType(final int type, final InputStream in) throws IOException {         // Discover possible incorrect type, revert to RLE         if (type == TIFFExtension.COMPRESSION_CCITT_T4 && in.markSupported()) {-            byte[] streamData = new byte[32];+            int limit = 500;              try {-                in.mark(streamData.length);+                in.mark(limit); -                int offset = 0;-                while (offset < streamData.length) {-                    int read = in.read(streamData, offset, streamData.length - offset);-                    if (read <= 0) {-                        break;-                    }--                    offset += read;+                int first = in.read();+                int second = in.read();+                if (first == -1 || second == -1) {+                    // stream to short+                    return type;                 }-            }-            finally {-                in.reset();-            }+                else if (first == 0 && (((byte) second) >> 4 == 1 || ((byte) second) == 1)) {+                    // correct, starts with EOL or byte aligned EOL+                    return type;+                }+                short b = (short) (((((byte) first) << 8) + ((byte) second)) >> 4);+                int limitBits = limit * 8;+                int read = second;+                byte streamByte = (byte) read;+                for (int i = 12; i < limitBits; i++) {+                    if (i % 8 == 0) {+                        read = in.read();

Fair enough! 😀

Schmidor

comment created time in a month

pull request commentharaldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

I have a file, where the EOL is a bit later than on our samples: EOL_needs_39bytes.zip All RICOH scanners with as it seems real data junk before the first line :) Unfortunately I can't share the really bad examples with 100 bytes or even ~300 till EOL.

Schmidor

comment created time in a month

Pull request review commentharaldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

 public CCITTFaxDecoderStream(final InputStream stream, final int columns, final     static int findCompressionType(final int type, final InputStream in) throws IOException {         // Discover possible incorrect type, revert to RLE         if (type == TIFFExtension.COMPRESSION_CCITT_T4 && in.markSupported()) {-            byte[] streamData = new byte[32];+            int limit = 500;              try {-                in.mark(streamData.length);+                in.mark(limit); -                int offset = 0;-                while (offset < streamData.length) {-                    int read = in.read(streamData, offset, streamData.length - offset);-                    if (read <= 0) {-                        break;-                    }--                    offset += read;+                int first = in.read();+                int second = in.read();+                if (first == -1 || second == -1) {+                    // stream to short+                    return type;                 }-            }-            finally {-                in.reset();-            }+                else if (first == 0 && (((byte) second) >> 4 == 1 || ((byte) second) == 1)) {+                    // correct, starts with EOL or byte aligned EOL+                    return type;+                }+                short b = (short) (((((byte) first) << 8) + ((byte) second)) >> 4);+                int limitBits = limit * 8;+                int read = second;+                byte streamByte = (byte) read;+                for (int i = 12; i < limitBits; i++) {+                    if (i % 8 == 0) {+                        read = in.read();

I've changed it this way, so we don't always read a big block just for this check. I think using the "on demand" read from stream and a few bytes of buffer would make it just more complex, not necessarily faster. 500 bytes is the worst case after which it aborts for incorrect files (missing EOL or RLE), for correct files only 2 are read.

Schmidor

comment created time in a month

Pull request review commentharaldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

 public CCITTFaxDecoderStream(final InputStream stream, final int columns, final     static int findCompressionType(final int type, final InputStream in) throws IOException {         // Discover possible incorrect type, revert to RLE         if (type == TIFFExtension.COMPRESSION_CCITT_T4 && in.markSupported()) {-            byte[] streamData = new byte[32];+            int limit = 500;              try {-                in.mark(streamData.length);+                in.mark(limit); -                int offset = 0;-                while (offset < streamData.length) {-                    int read = in.read(streamData, offset, streamData.length - offset);-                    if (read <= 0) {-                        break;-                    }--                    offset += read;+                int first = in.read();+                int second = in.read();+                if (first == -1 || second == -1) {+                    // stream to short+                    return type;                 }-            }-            finally {-                in.reset();-            }+                else if (first == 0 && (((byte) second) >> 4 == 1 || ((byte) second) == 1)) {+                    // correct, starts with EOL or byte aligned EOL+                    return type;+                }+                short b = (short) (((((byte) first) << 8) + ((byte) second)) >> 4);+                int limitBits = limit * 8;+                int read = second;+                byte streamByte = (byte) read;+                for (int i = 12; i < limitBits; i++) {+                    if (i % 8 == 0) {+                        read = in.read();+                        if (read > -1) {

Done :)

Schmidor

comment created time in a month

Pull request review commentharaldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

 public CCITTFaxDecoderStream(final InputStream stream, final int columns, final     static int findCompressionType(final int type, final InputStream in) throws IOException {         // Discover possible incorrect type, revert to RLE         if (type == TIFFExtension.COMPRESSION_CCITT_T4 && in.markSupported()) {-            byte[] streamData = new byte[32];+            int limit = 500;              try {-                in.mark(streamData.length);+                in.mark(limit); -                int offset = 0;-                while (offset < streamData.length) {-                    int read = in.read(streamData, offset, streamData.length - offset);-                    if (read <= 0) {-                        break;-                    }--                    offset += read;+                int first = in.read();+                int second = in.read();+                if (first == -1 || second == -1) {+                    // stream to short+                    return type;                 }-            }-            finally {-                in.reset();-            }+                else if (first == 0 && (((byte) second) >> 4 == 1 || ((byte) second) == 1)) {+                    // correct, starts with EOL or byte aligned EOL+                    return type;+                }+                short b = (short) (((((byte) first) << 8) + ((byte) second)) >> 4);+                int limitBits = limit * 8;+                int read = second;+                byte streamByte = (byte) read;+                for (int i = 12; i < limitBits; i++) {+                    if (i % 8 == 0) {+                        read = in.read();

Using as many as 500 single-byte reads over one array read might impact performance negatively, but I guess it's not a deal breaker.

But would it be hard to read blocks of bytes instead?

Schmidor

comment created time in a month

Pull request review commentharaldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

 public CCITTFaxDecoderStream(final InputStream stream, final int columns, final     static int findCompressionType(final int type, final InputStream in) throws IOException {         // Discover possible incorrect type, revert to RLE         if (type == TIFFExtension.COMPRESSION_CCITT_T4 && in.markSupported()) {-            byte[] streamData = new byte[32];+            int limit = 500;              try {-                in.mark(streamData.length);+                in.mark(limit); -                int offset = 0;-                while (offset < streamData.length) {-                    int read = in.read(streamData, offset, streamData.length - offset);-                    if (read <= 0) {-                        break;-                    }--                    offset += read;+                int first = in.read();+                int second = in.read();+                if (first == -1 || second == -1) {+                    // stream to short+                    return type;                 }-            }-            finally {-                in.reset();-            }+                else if (first == 0 && (((byte) second) >> 4 == 1 || ((byte) second) == 1)) {+                    // correct, starts with EOL or byte aligned EOL+                    return type;+                }+                short b = (short) (((((byte) first) << 8) + ((byte) second)) >> 4);+                int limitBits = limit * 8;+                int read = second;+                byte streamByte = (byte) read;+                for (int i = 12; i < limitBits; i++) {+                    if (i % 8 == 0) {+                        read = in.read();+                        if (read > -1) {

Invert the if, then you won't need the else, for better readability.

Schmidor

comment created time in a month

PR opened haraldk/TwelveMonkeys

#579 Deeper EOL search in the CCITT stream

I've got other TIFFs which have some junk at the beginning of the CCITT stream, which is even longer than before. In an extrem case almost 300 bytes.

So I propose to increase the read limit for the CCITT type detection even further, but only read on demand till a EOL is found or the limit is reached.

Also relates to #535

+32 -21

1 commit in Schmidor/TwelveMonkeys/tree/ccitt_eol_search haraldk/TwelveMonkeys/tree/master

0 comment

1 changed file

pr created time in a month

created repositoryneo4j-graph-examples/twitch

Twitch Streamer Analysis, see Twitchverse https://towardsdatascience.com/twitchverse-a-network-analysis-of-twitch-universe-using-neo4j-graph-data-science-d7218b4453ff

created time in a month

startedsatarsa/rmpfit

started time in a month

issue openedrmuller/infomas-asl

Release 3.1.x

Hi. I came from Stackoverflow https://stackoverflow.com/questions/259140/scanning-java-annotations-at-runtime I would like to try your library, but it's still in SNAPSHOT for 7 years. Can you please maybe release a 3.1.x version to maven central? It wouldn't matter if there are still features/issues open, at least I could try it out.

created time in a month

issue commentharaldk/TwelveMonkeys

imageio-jpeg seemingly not registered when using Executors.newWorkStealingPool vs Executors.newFixedThreadPool

No new input, closing for now. Feel free to reopen if you have more information or report back if you solved this issue.

ldeck

comment created time in a month

issue closedharaldk/TwelveMonkeys

imageio-jpeg seemingly not registered when using Executors.newWorkStealingPool vs Executors.newFixedThreadPool

I recently made a change to our app, configuring its ExecutorService bean to return a new work-stealing pool instead of the previously used fixed-thread pool.

With that change we then started seeing the following exception for JPGs with CMYK color encoding.

Caused by: javax.imageio.IIOException: Unsupported Image Type
	at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(Unknown Source)
	at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.read(Unknown Source)
	at java.desktop/javax.imageio.ImageIO.read(Unknown Source)
	at java.desktop/javax.imageio.ImageIO.read(Unknown Source)

Any ideas why this might be the case? Is there something special about the initialisation of work-stealing thread-pool's threads?

I've got the following dependencies:

            <dependency>
                <groupId>com.twelvemonkeys.imageio</groupId>
                <artifactId>imageio-jpeg</artifactId>
                <version>3.7.0</version>
            </dependency>
            <dependency>
                <groupId>com.twelvemonkeys.servlet</groupId>
                <artifactId>servlet</artifactId>
                <version>3.7.0</version>
            </dependency>

And

public class OurApplication extends SpringBootServletInitializer {
...
    @Override
    public void onStartup(ServletContext servletContext) throws ServletException {
        super.onStartup(servletContext);
        servletContext.addListener(IIOProviderContextListener.class);
    }

closed time in a month

ldeck

created repositorycodahale/usl-rs

A Rust crate and CLI tool which simplifies calculation of Universal Scalability Law parameters given system measurements.

created time in a month

fork codahale/googapis

mechiru/googapis codahale/googapis

fork in a month

created repositorycodahale/cpace

A CPACE-inspired PAKE using ristretto255 and STROBE.

created time in a month

pull request commentcommonmark/commonmark-java