Skip to main content

J2K Lossy setEncodingRate Issue

13 replies [Last post]
justinfalk
Offline
Joined: 2008-05-21

Hello,

As described in jai-imageio-core issue 151 there is a problem with setEncodingRate. In the CodecLib encoder it intreprets this value as bits / pixel but doesn't go above 1.0. Thus you cannot lossy compress images greater than 1.0 bits / pixel by any means other than using the pure java implementation.

https://jai-imageio-core.dev.java.net/issues/show_bug.cgi?id=151

I am confused on the status of the issue for a couple reasons. 1) It seems like a simple fix as suggested in the issue. 2) There is a suggestion that the issue is a duplicate of issue 151 which is a Macintosh platform issue. This is not specific to the Mac platform. 3) It hasn't been touched since 9/07.

Could somebody clarify this and let me know what the status of this issue is?

Thanks,

Justin

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
robert engels

I will look at getting the code/patch together.

Are you certain that you aren't using an image that just compresses
very well (.e. lots of blocks). If that is the case, you are going to
always get a small file.

On Jun 24, 2008, at 12:04 AM, jai-imageio@javadesktop.org wrote:

> Robert,
>
> I don't believe the fix in issue 150 will correct the problem. I
> recompiled the 1.1 version of JAI core the the patch specified
> above. Here are the results of my tests. I started with a 2mb
> uncompressed image and passed the following values to setEncodingRate
>
> values for setEncodingRate => resulting file size
>
> Double.MAX_VALUE => 748kb (lossless)
> .1 => 62kb
> .2 => 62kb
> .3 => 62kb
> ...
> .9 => 62kb
>
> Then I tried to set the level of compression by specifying the
> desired stream size by modifying
> J2KImageWriterCodecLib.setParameters to pass the following into
>
> encoder.setRate(rate, size)
>
> (-1, 10000) => 11kb
> (-1, 20000) => 11kb
> (-1, 30000) => 28kb
> (-1, 40000) => 28kb
> (-1, 50000) => 28kb
> (-1, 60000) => 28kb
> (-1, 70000) => 62kb
> (-1, 80000) => 62kb
> ...
> (-1, 990000) => 62kb
> (-1, 1000000) => 62kb
> ...
> (-1, 2040000) => 62kb
> (-1, 2050000) => 62kb
>
>
> Regardless of what I set the encoding rate or size to the resulting
> lossy compressed images aren't bigger than 62k from a 2mb image.
> That's WAY too lossy and the image quality is very poor. Am I
> missing something fundamental about J2K lossy here?
>
> If you have a solution for this problem that you're using, could
> you post a patch and/or example?
>
> Thanks,
>
> Justin
> [Message sent by forum member 'justinfalk' (justinfalk)]
>
> http://forums.java.net/jive/thread.jspa?messageID=282152
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

robert engels

Attached is the patch I used. You ned to use the generic
setCompressionQuality() on the ImageWriteParam.

[patch.txt]

On Jun 24, 2008, at 8:31 AM, robert engels wrote:

> I will look at getting the code/patch together.
>
> Are you certain that you aren't using an image that just compresses
> very well (.e. lots of blocks). If that is the case, you are going
> to always get a small file.
>
> On Jun 24, 2008, at 12:04 AM, jai-imageio@javadesktop.org wrote:
>
>> Robert,
>>
>> I don't believe the fix in issue 150 will correct the problem. I
>> recompiled the 1.1 version of JAI core the the patch specified
>> above. Here are the results of my tests. I started with a 2mb
>> uncompressed image and passed the following values to setEncodingRate
>>
>> values for setEncodingRate => resulting file size
>>
>> Double.MAX_VALUE => 748kb (lossless)
>> .1 => 62kb
>> .2 => 62kb
>> .3 => 62kb
>> ...
>> .9 => 62kb
>>
>> Then I tried to set the level of compression by specifying the
>> desired stream size by modifying
>> J2KImageWriterCodecLib.setParameters to pass the following into
>>
>> encoder.setRate(rate, size)
>>
>> (-1, 10000) => 11kb
>> (-1, 20000) => 11kb
>> (-1, 30000) => 28kb
>> (-1, 40000) => 28kb
>> (-1, 50000) => 28kb
>> (-1, 60000) => 28kb
>> (-1, 70000) => 62kb
>> (-1, 80000) => 62kb
>> ...
>> (-1, 990000) => 62kb
>> (-1, 1000000) => 62kb
>> ...
>> (-1, 2040000) => 62kb
>> (-1, 2050000) => 62kb
>>
>>
>> Regardless of what I set the encoding rate or size to the
>> resulting lossy compressed images aren't bigger than 62k from a
>> 2mb image. That's WAY too lossy and the image quality is very
>> poor. Am I missing something fundamental about J2K lossy here?
>>
>> If you have a solution for this problem that you're using, could
>> you post a patch and/or example?
>>
>> Thanks,
>>
>> Justin
>> [Message sent by forum member 'justinfalk' (justinfalk)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=282152
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-
>> imageio.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

justinfalk
Offline
Joined: 2008-05-21

Robert & James,

Thanks to your help I believe I have this working. My problem was twofold. First, I checked out the 1.1 root branch assuming it was the latest, rather than the 1.1-fcs branch, when I applied Robert's changes. Secondly, the 1.1 root branch doesn't have the numDecompositionLevels property in the J2KImageWriteParam so I didn't see that as an option. The numDecompositionLevels made a huge difference.

Thank you for all your assistance!

Justin

justinfalk
Offline
Joined: 2008-05-21

More questions...

Is the source for the clib_jiio.dll library available?
Is that maintained by Sun?
What does the second parameter in setEncodingRate specify? It is always passed in as 0 in the J2K code.

Thanks in advance for any information you can provide.

Justin

jxc
Offline
Joined: 2005-02-24

> Is the source for the clib_jiio.dll library available?

Not publicly available at this time.

> Is that maintained by Sun?

Yes.

> What does the second parameter in setEncodingRate
> specify? It is always passed in as 0 in the J2K code.

Here is the javadoc for the native method setRate

public final void setRate(double rate, int size)

Sets the compression rate. Note: This method, if used, should be called before any encode method is called.

Parameters:
rate - the compression rate. The target rate is defined by size if rate < 0.0; otherwise it is reverted to compression rate, i.e. rate should be 0.1 for 10:1 compression rate. Default value is 0.0.
size - the target code stream length in bytes. Default value is 0.

HTH,
-James

justinfalk
Offline
Joined: 2008-05-21

Thank you for the quick response James. Do you have any thoughts on the problem I'm seeing with setEncodingRate in J2K above?

Thanks again,

Justin

robert engels

For what it is worth, I am fairly certain the bug is correct (I filed
it).

We use the "fix" outlined in the bug report and it works fine. It
does not require changes to the libraries - you just need to call
with parameters that are "not correct" according to the javadoc.

On Jun 23, 2008, at 9:17 PM, jai-imageio@javadesktop.org wrote:

> Thank you for the quick response James. Do you have any thoughts
> on the problem I'm seeing with setEncodingRate in J2K above?
>
> Thanks again,
>
> Justin
> [Message sent by forum member 'justinfalk' (justinfalk)]
>
> http://forums.java.net/jive/thread.jspa?messageID=282136
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

justinfalk
Offline
Joined: 2008-05-21

Thanks Robert. Is there any chance this fix will be incorporated into a release anytime soon?

Justin

robert engels

I have no idea... the fix in bug 150 is (I think) the proper fix.

On Jun 23, 2008, at 10:14 PM, jai-imageio@javadesktop.org wrote:

> Thanks Robert. Is there any chance this fix will be incorporated
> into a release anytime soon?
>
> Justin
> [Message sent by forum member 'justinfalk' (justinfalk)]
>
> http://forums.java.net/jive/thread.jspa?messageID=282142
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

justinfalk
Offline
Joined: 2008-05-21

Robert,

I don't believe the fix in issue 150 will correct the problem. I recompiled the 1.1 version of JAI core the the patch specified above. Here are the results of my tests. I started with a 2mb uncompressed image and passed the following values to setEncodingRate

values for setEncodingRate => resulting file size

Double.MAX_VALUE => 748kb (lossless)
.1 => 62kb
.2 => 62kb
.3 => 62kb
...
.9 => 62kb

Then I tried to set the level of compression by specifying the desired stream size by modifying J2KImageWriterCodecLib.setParameters to pass the following into

encoder.setRate(rate, size)

(-1, 10000) => 11kb
(-1, 20000) => 11kb
(-1, 30000) => 28kb
(-1, 40000) => 28kb
(-1, 50000) => 28kb
(-1, 60000) => 28kb
(-1, 70000) => 62kb
(-1, 80000) => 62kb
...
(-1, 990000) => 62kb
(-1, 1000000) => 62kb
...
(-1, 2040000) => 62kb
(-1, 2050000) => 62kb

Regardless of what I set the encoding rate or size to the resulting lossy compressed images aren't bigger than 62k from a 2mb image. That's WAY too lossy and the image quality is very poor. Am I missing something fundamental about J2K lossy here?

If you have a solution for this problem that you're using, could you post a patch and/or example?

Thanks,

Justin

jxc
Offline
Joined: 2005-02-24

Maybe you have to call setNumDecompositionLevels(int) to use more
than the default 5 decomposition levels for better lossy results.

justinfalk
Offline
Joined: 2008-05-21

I don't believe that issue 150/151 has been accurately described. In the codec implementation of J2K lossy the encoding rate seems not to work at any value above 1.0. The issue states that it is simply being translated incorrectly before being passed to the codec.

This is the actual code:
...
rate /= ImageUtil.getElementSize(sampleModel);
encoder.setRate(rate, 0);

This is the proposed code in the issue:
...
encoder.setRate(rate, 0);

However, as a test I tried recompiling the JAI core jar with the proposed fix and the result was the same. In fact, even hard coding various different values never resulted in an encoding rate of greater than 1 bit per pixel. It seems that the encoding rate works correctly up to a value of 1.0, but for any value greater than 1.0 it encodes the image at a rate of 1 bit per pixel.

Is it possible that the codec itself does not process the encoding rate correctly for J2K lossy in Windows? Is anyone else using this?

Also, the second part of my original question was regarding the status of this issue. It's nearly a year old now. Are there any plans to fix this? It seems odd that nobody wants to use the codec version of J2K lossy with a reasonable encoding rate.

Thanks,

Justin

justinfalk
Offline
Joined: 2008-05-21

> The second issue you cite is not a Mac platform issue - it is incorrectly classified as that.
>
> I filed the issue - I should know :)
>
> I am fairly certain it IS a duplicate.

Thanks for the response Robert. Yes, I agree it looks like a duplicate of 150 now that it's not classified as a Macintosh platform issue.

Do you have any idea when this will be implemented? Is there a target date for "milestone 1"?

Thanks,

Justin