[OpenJPEG] opj_stream_set_user_data_length

[Hervé Guillemet]

Hello,

Two comments/questions about the API for reading from an arbitrary stream
and particularly opj_stream_set_user_data_length:

-The opj_stream_set_user_data_length name is quite misleading. It took me
quite some time to find out it's not meant to set the userdata length but
the total length of the byte stream.
- Wouldn't it be possible to get rid of this function ? There may be
situations where the length of the stream is not known in advance, and it
seems to me that the segmented JPEG codestream structure would allow to
decode without having this information.

--
Hervé

[Mathieu Malaterre]

Hervé,

Post by Hervé Guillemet
Hello,
Two comments/questions about the API for reading from an arbitrary stream
-The opj_stream_set_user_data_length name is quite misleading. It took me
quite some time to find out it's not meant to set the userdata length but
the total length of the byte stream.

Could you please sugggest a documentation update then ?

Post by Hervé Guillemet
- Wouldn't it be possible to get rid of this function ? There may be
situations where the length of the stream is not known in advance, and it
seems to me that the segmented JPEG codestream structure would allow to
decode without having this information.

I do not believe this would make sense. JPEG 2000 is reeally meant to
offer a structure for partial decoding (think PLT makers), so the
codebase need (should?) seeking, which will not work for pure-stream
interface. So for all other case lenght could be known in advance.

Comments ?

[Hervé Guillemet]

Post by Hervé Guillemet

Post by Hervé Guillemet
Two comments/questions about the API for reading from an arbitrary

stream

Post by Hervé Guillemet
-The opj_stream_set_user_data_length name is quite misleading. It took

me

Post by Hervé Guillemet
quite some time to find out it's not meant to set the userdata length

but

Post by Hervé Guillemet
the total length of the byte stream.

Could you please sugggest a documentation update then ?

opj_stream_set_stream_length would probably be a better name but I guess
it's too late to change the api.

Documentation change suggestion :

/**
* Sets the total length of the byte stream.
*
* @param p_stream the stream to modify
* @param stream_length length of the stream.
*/
OPJ_API void OPJ_CALLCONV opj_stream_set_user_data_length(opj_stream_t*
p_stream, OPJ_UINT64 stream_length);

Also I'd suggest to precise in the documentation that the skip and read
callback functions should return -1 on end of stream, and the seek callback
function should return false on end of stream.

Post by Hervé Guillemet

Post by Hervé Guillemet
- Wouldn't it be possible to get rid of this function ? There may be
situations where the length of the stream is not known in advance, and

it

Post by Hervé Guillemet
seems to me that the segmented JPEG codestream structure would allow to
decode without having this information.

I do not believe this would make sense. JPEG 2000 is reeally meant to
offer a structure for partial decoding (think PLT makers), so the
codebase need (should?) seeking, which will not work for pure-stream
interface. So for all other case lenght could be known in advance.

I'm not a JPEG 2000 specialist but I think JPEG 200 is also about streaming
and progression.
Would the stream length known in all streaming cases ?

My personnal concern is to build a Java Image I/O plugin that uses openjpeg
and in the most general case, Java provides the plugin with an
ImageImageStream that may not support the length() method call.

I'd say the main question is really whether this information is needed for
decoding or not. I guess it is since this call was implemented, but I'm
wondering why.

--
Hervé

[Aaron Boxer]

Hello Herve,

.....

Post by Hervé Guillemet

Post by Hervé Guillemet

Post by Hervé Guillemet
Two comments/questions about the API for reading from an arbitrary

stream

Post by Hervé Guillemet
-The opj_stream_set_user_data_length name is quite misleading. It took

me

Post by Hervé Guillemet
quite some time to find out it's not meant to set the userdata length

but

Post by Hervé Guillemet
the total length of the byte stream.

Could you please sugggest a documentation update then ?

opj_stream_set_stream_length would probably be a better name but I guess
it's too late to change the api.
/**
* Sets the total length of the byte stream.
*
*/
OPJ_API void OPJ_CALLCONV opj_stream_set_user_data_length(opj_stream_t*
p_stream, OPJ_UINT64 stream_length);
Also I'd suggest to precise in the documentation that the skip and read
callback functions should return -1 on end of stream, and the seek callback
function should return false on end of stream.

Post by Hervé Guillemet

Post by Hervé Guillemet
- Wouldn't it be possible to get rid of this function ? There may be
situations where the length of the stream is not known in advance, and

it

Post by Hervé Guillemet
seems to me that the segmented JPEG codestream structure would allow to
decode without having this information.

I do not believe this would make sense. JPEG 2000 is reeally meant to
offer a structure for partial decoding (think PLT makers), so the
codebase need (should?) seeking, which will not work for pure-stream
interface. So for all other case lenght could be known in advance.

I'm not a JPEG 2000 specialist but I think JPEG 200 is also about
streaming and progression.
Would the stream length known in all streaming cases ?
My personnal concern is to build a Java Image I/O plugin that uses
openjpeg and in the most general case, Java provides the plugin with an
ImageImageStream that may not support the length() method call.
Java Image IO support already exists in a branch I worked on a few years

ago (and it depends on another project of mine, imageio-generic).

https://github.com/CodecCentral/imageio-generic
https://github.com/CodecCentral/openjpeg/tree/java_imageio

The java_imageio branch also includes a simple java jpeg 2000 viewer, as a
test bed for the plugin.

If you want to stand in the "footsteps of giants" then please feel free to
use and extend this code. Unfortunately, I haven't the time
to support it. Also be aware that several people have tried merging this
code into the OpenJPEG mainline, without success.

Cheers,
Aaron