uclouvain / openjpeg Goto Github PK

What steps will reproduce the problem?
1. Checkout branch v2
2. Open DllOpenJPEG.sln in Visual Studio 2005.
3. Build Debug and Release configurations.

What is the expected output? What do you see instead?
- Expected: libraries compile without error.
- Actual: multiple errors reported (details at the bottom).

What version of the product are you using? On what operating system?
- Clean checkout from http://openjpeg.googlecode.com/svn/branches/v2
- Windows 7 Pro

Please provide any additional information below.
- Patch includes:
  + Corrected missing source code files in DllOpenJPEG.vcproj
  + Corrected missing OPJ_CALLCONV macro on some function definitions in cio.c and
openjpeg.c 

- Before applying the patch the following errors were reported:
1>openjpeg.c
1>.\libopenjpeg\openjpeg.c(377) : error C2373: 'opj_write_tile' : redefinition; different
type modifiers
1>        c:\source\openjpeg\v2\libopenjpeg\openjpeg.h(842) : see declaration of 'opj_write_tile'
1>.\libopenjpeg\openjpeg.c(425) : error C2373: 'opj_read_tile_header' : redefinition;
different type modifiers
1>        c:\source\openjpeg\v2\libopenjpeg\openjpeg.h(871) : see declaration of 'opj_read_tile_header'
1>.\libopenjpeg\openjpeg.c(470) : error C2373: 'opj_decode_tile_data' : redefinition;
different type modifiers
1>        c:\source\openjpeg\v2\libopenjpeg\openjpeg.h(896) : see declaration of 'opj_decode_tile_data'
1>.\libopenjpeg\openjpeg.c(540) : error C2373: 'opj_set_decode_area' : redefinition;
different type modifiers
1>        c:\source\openjpeg\v2\libopenjpeg\openjpeg.h(915) : see declaration of 'opj_set_decode_area'
1>.\libopenjpeg\openjpeg.c(870) : error C2373: 'opj_set_MCT' : redefinition; different
type modifiers
1>        c:\source\openjpeg\v2\libopenjpeg\openjpeg.h(978) : see declaration of 'opj_set_MCT'
1>cio.c
1>.\libopenjpeg\cio.c(228) : error C2373: 'opj_stream_create' : redefinition; different
type modifiers
1>        c:\source\openjpeg\v2\libopenjpeg\openjpeg.h(721) : see declaration of 'opj_stream_create'
1>.\libopenjpeg\cio.c(272) : error C2373: 'opj_stream_default_create' : redefinition;
different type modifiers
1>        c:\source\openjpeg\v2\libopenjpeg\openjpeg.h(720) : see declaration of 'opj_stream_default_create'

After correcting the compiler errors the linker reporting missing symbols for the source
files that have been added to DllOpenJPEG.vcproj.
1>   Creating library .\Release/OpenJPEG.lib and object .\Release/OpenJPEG.exp
1>j2k.obj : error LNK2019: unresolved external symbol _opj_procedure_list_destroy referenced
in function _j2k_destroy
1>jp2.obj : error LNK2001: unresolved external symbol _opj_procedure_list_destroy
1>j2k.obj : error LNK2019: unresolved external symbol _opj_procedure_list_clear referenced
in function _j2k_exec
1>jp2.obj : error LNK2001: unresolved external symbol _opj_procedure_list_clear
1>j2k.obj : error LNK2019: unresolved external symbol _opj_procedure_list_get_first_procedure
referenced in function _j2k_exec
1>jp2.obj : error LNK2001: unresolved external symbol _opj_procedure_list_get_first_procedure
1>j2k.obj : error LNK2019: unresolved external symbol _opj_procedure_list_get_nb_procedures
referenced in function _j2k_exec
1>jp2.obj : error LNK2001: unresolved external symbol _opj_procedure_list_get_nb_procedures
1>j2k.obj : error LNK2019: unresolved external symbol _opj_procedure_list_create referenced
in function _j2k_create_decompress
1>jp2.obj : error LNK2001: unresolved external symbol _opj_procedure_list_create
1>j2k.obj : error LNK2019: unresolved external symbol _opj_procedure_list_add_procedure
referenced in function _j2k_setup_header_reading
1>jp2.obj : error LNK2001: unresolved external symbol _opj_procedure_list_add_procedure
1>tcd.obj : error LNK2019: unresolved external symbol __ProfStop referenced in function
_tcd_encode_tile
1>tcd.obj : error LNK2019: unresolved external symbol __ProfStart referenced in function
_tcd_encode_tile
1>Release/OpenJPEG.dll : fatal error LNK1120: 8 unresolved externals

Download-Date: 17.05.2010

winfried

To:[email protected]
Subject:[OpenJPEG] PNG codec for OpenJPEG_v1_3

This could have been the final version for OpenJPEG_v1_3. But the
'tiled image' case and other cases are unsolved.

This codec has been tested with bit_depth: 16, 8, 4, 2; with/without
alpha transparency; with color/gray. In both directions: 
PNG --> J2K --> reversePNG .

READ:
=====
16 Bit and parameters->cp_cinema are not used: I do not know what
cp_cinema is.

1,2,4 Bits are expanded to 8 Bits: I do not know whether the library
accepts these depths.


READ/WRITE:
===========
Time and Text are not used: I do not know whether the library accepts
Time/Text.


If this version should be accepted, I could write the codec for
OpenJPEG_v2.

winfried

Hi everybody,

I'm not sure of that but I detected what I believe to be little mistakes in 
pi.c source file 
(http://code.google.com/p/openjpeg/source/browse/trunk/libopenjpeg/pi.c) :

at line 212:
if (!((pi->y % (comp->dy << rpy) == 0) || ((pi->y == pi->ty0) && ((try0 << 
levelno) % (1 << rpx))))){

shouldn't rpx be rpy at the end of the line ?

line 219:
if ((res->pw==0)||(res->pw==0)) continue;

res->pw twice ? I think it should be if ((res->pw==0)||(res->ph==0)) ..

the same mistakes (if they are mistakes) are reproduced at lines : 293, 300, 372 and
379

thanks

on powerpc hosts running gcc and utilizing altivec, the stdbool types are
defined to take advantage of the hardware.  however, this requires headers
include stdbool.h to get the optimized definitions.

openjpeg.h relies on an external define (HAVE_STDBOOL_H) in order to
determine whether to pull in stdbool.h.  if this doesnt exist, it falls
back to redefining the stdbool interfaces.  this causes problems because
the stdbool namespace is in the compiler / C library realm and arbitrary
packages shouldnt be doing this kind of thing.

specifically, this code:
#include <openjpeg.h>
#include <stdbool.h>

will fail on a powerpc host like so:
In file included from test.c:1:
/usr/include/openjpeg.h:246: error: expected specifier-qualifier-list
before ‘bool’
/usr/include/openjpeg.h:406: error: expected specifier-qualifier-list
before ‘bool’
/usr/include/openjpeg.h:440: error: expected specifier-qualifier-list
before ‘bool’
/usr/include/openjpeg.h:454: error: expected specifier-qualifier-list
before ‘bool’
/usr/include/openjpeg.h:463: error: expected specifier-qualifier-list
before ‘bool’
/usr/include/openjpeg.h:891: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘opj_encode’
/usr/include/openjpeg.h:900: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘opj_encode_with_info’

so the solution imo is to do the stdbool.h check at build time and mung the
installed header so that it has an '#if 1' or '#if 0'.  so something like:
openjpeg.h:#if @HAVE_STDBOOL_H@
install:
  sed -e 's:@HAVE_STDBOOL_H@:$(HAVE_STDBOOL_H):' openjpeg.h > /installpath/....

I've developped a OpenJPEG based driver for GDAL. In the process of testing
it with other GDAL drivers enabled, I got crashes when both libopenjpeg and
libjasper are linked with GDAL. I've then realized that there's a name
conflict with symbols from Jasper... Namely jp2_decode and jp2_encode.
Those symbols are public symbols for Jasper, but internal ones for
OpenJPEG. So the attached patch adds a opj_ prefix in front of them, to
avoid segmentation faults when running GDAL autotests...

gcc from MinGW does not define WIN32. And anyway, using WIN32 is not so portable. The
correct way is to use _WIN32. It's defined on any Windows compiler.

In addition, if one uses the autotools, then OPJ_API is not well defined. DLL_EXPORT
should be used to set it correctly (DLL_EXPORT is passed to the preprocessor by libtool
for the object files used for the creation of the DLL).

I didn't touch libopenjpeg/CMakeLists.txt as I don't know cmake stuff. But I think
that WIN32 should be replaced by _WIN32 too.

Original code, imagetopng(), line 6:
    int has_alpha, w, h;

Please change to:
   int has_alpha = 0, w, h;

winfried

Arnaud,

do you have decided how 'pclr', 'colr', 'cmap' shall be coded ?

I have finally finished the code for the restricted ICC Profile.

The code has been tested with the testfiles:

 file5.jp2
   (XYZ to Restricted ICC profile describing ROMM-RGB)
 file7.jp2
   (XYZ to 16-bit e-sRGB JP2 restricted (to sRGB) profile)
 file8.jp2
   (XYZ to Restricted ICC profile describing greyscale version of ROMM-RGB)

Untested is the case enumCS 18: sYCC. I do not have a respective testfile.

The change is attached.

winfried

Hi all,

I'm a developer for blender(www.blender.org) were using openjpeg and
were also getting scans from coverity.
It detected a mem leak in t2.c

at line 617 it should free pi before returning -999

I can provide the details of the report if needed just let me know.
(They are a bit hard to read
and I figured this one is pretty straight forward)
its:
CID: 570
Checker: RESOURCE_LEAK (help)
File: base/src/extern/libopenjpeg/t2.c
Function: t2_encode_packets
Description: Variable "pi" not freed or pointed-to in function
"pi_create_encode"




There is one other report about some dead code this one I'm providing
the extra details.  I
haven't really looked at this one but figured I'd forward it on.  If
you fix these please note in your svn comments that it was detected by
coverity.  Let me know if this doesn't make sense.

CID: 566
Checker: DEADCODE (help)
File: base/src/extern/libopenjpeg/t1.c
Function: t1_encode_cblk
Description: Assigning "0" to "type"

Event const: After this line, the value of "type" is equal to 0
Event assignment: Assigning "0" to "type"
Also see events: [dead_error_begin][dead_error_condition][assignment]

835                     type = ((bpno < (cblk->numbps - 4)) && (passtype <
2) &&
(cblksty & J2K_CCP_CBLKSTY_LAZY)) ? T1_TYPE_RAW : T1_TYPE_MQ;
836
837                     switch (passtype) {
838                             case 0:
839                                     t1_enc_sigpass(t1, bpno, orient,
&nmsedec, type, cblksty);
840                                     break;
841                             case 1:
842                                     t1_enc_refpass(t1, bpno, &nmsedec,
type, cblksty);
843                                     break;
844                             case 2:
845                                     t1_enc_clnpass(t1, bpno, orient,
&nmsedec, cblksty);
846                                     /* code switch SEGMARK (i.e. SEGSYM) */
847                                     if (cblksty & J2K_CCP_CBLKSTY_SEGSYM)
848                                             mqc_segmark_enc(mqc);
849                                     break;
850                     }
851
852                     /* fixed_quality */
853                     tempwmsedec = t1_getwmsedec(nmsedec, compno, level,
orient,
bpno, qmfbid, stepsize, numcomps);
854                     cumwmsedec += tempwmsedec;
855                     tile->distotile += tempwmsedec;
856
857                     /* Code switch "RESTART" (i.e. TERMALL) */
858                     if ((cblksty & J2K_CCP_CBLKSTY_TERMALL) &&
!((passtype == 2)
&& (bpno - 1 < 0))) {
859                             if (type == T1_TYPE_RAW) {
860                                     mqc_flush(mqc);
861                                     correction = 1;
862                                     /* correction =
mqc_bypass_flush_enc(); */
863                             } else {                        /*
correction = mqc_restart_enc(); */
864                                     mqc_flush(mqc);
865                                     correction = 1;
866                             }
867                             pass->term = 1;
868                     } else {
869                             if (((bpno < (cblk->numbps - 4) &&
(passtype > 0))
870                                     || ((bpno == (cblk->numbps - 4)) &&
(passtype == 2))) &&
(cblksty & J2K_CCP_CBLKSTY_LAZY)) {

Event dead_error_condition: On this path, the condition "type == 1"
could not be true
Also see events: [dead_error_begin][const][assignment]

871                                     if (type == T1_TYPE_RAW) {

Event dead_error_begin: Cannot reach dead code beginning here
Also see events: [dead_error_condition][const][assignment]

872                                             mqc_flush(mqc);




Anyway thanks for the good work and keep it up.

Kent Mein

16 bits lossless compression in OpenJPEG is ok, but not lossy.

See ref:
* http://groups.google.com/group/openjpeg/browse_thread/thread/924077905bc53368
* http://groups.google.com/group/openjpeg/browse_thread/thread/c3379b3aa0d0a1a9

*
http://groups.google.com/group/openjpeg/tree/browse_frm/month/2008-07?_done=%2Fgroup%2Fopenjpeg%2Fbrowse_frm%2Fmonth%2F2008-07%3F&

What steps will reproduce the problem?
1. Attempt to redirect console output to a GUI
2.
3.

What is the expected output? What do you see instead?
Expected: See image_to_j2k output in my app
Instead: Nothing until it has completed

What version of the product are you using? On what operating system?
v1.3 image_to_j2k on Win XP SP3

Please provide any additional information below.
After reading, apparently this behaviour is because the console 
application is buffering text into a pipe instead of simply printing.
Apprently, in C++, setting the following will correct this issue:
setvbuf(stdout, NULL, _IONBF, 0);
setvbuf(stderr, NULL, _IONBF, 0);

Currently the Visual Studio builds are broken in the SVN. Attached a patch to fix this
issue.

OpenJpeg currently doesn't compile in C++ Builder.
Patch to fix this is attached.

The attached patch had been sent to the LIST on 01.03.2010,
but is missing in OpenJPEG-1.4-revision-577. The test file
can be found here: J2KP4files/codestreams_profile0/p0_07.j2k

---------------- WITHOUT PATCH ----------------
./j2k_to_image -i p0_07.j2k -o p0_07.pnm

[INFO] tile 1 of 256
[ERROR] Expected EPH marker
[WARNING] Expected SOP marker
Error : expected EPH marker
(...)
Error : expected EPH marker
[WARNING] Expected SOP marker
Segmentation fault

---------------- WITH PATCH ----------------

./j2k_to_image -i p0_07.j2k -o p0_07.pnm

[INFO] tile 1 of 256
[ERROR] Expected EPH marker
[ERROR] tcd_decode: incomplete bistream
[INFO] - tiers-1 took 0.008001 s
[INFO] - dwt took 0.000000 s
[INFO] - tile decoded in 0.008001 s
ERROR -> j2k_to_image: failed to decode image!
------------------------------------------------------

winfried
------------------------------------------------------
--- OpenJPEG-1.4-revision-577/libopenjpeg/t2.c.orig 2010-06-15 07:36:36.000000000 +0200
+++ OpenJPEG-1.4-revision-577/libopenjpeg/t2.c  2010-06-15 07:38:15.000000000 +0200
@@ -494,6 +494,7 @@
    if (tcp->csty & J2K_CP_CSTY_EPH) {
        if ((*hd) != 0xff || (*(hd + 1) != 0x92)) {
            opj_event_msg(t2->cinfo, EVT_ERROR, "Expected EPH marker\n");
+           return -999;
        } else {
            hd += 2;
        }
@@ -711,7 +712,8 @@
            } else {
                e = 0;
            }
-
+           if(e == -999) return -999;
+
            /* progression in resolution */
            image->comps[pi[pino].compno].resno_decoded =
                (e > 0) ?

Compiling the svn/trunk of 12.05.2010 I have seen that it is version 1.4 .
Two corrections follow.

1. The jpwl/Makefile is missing '-lpng'

2. The codec/convert.c contains the imagetopng/pngtoimage I had withdrawn.

Attached are the corrections.

winfried   

I have sent you already two reports concerning the problem that
'j2k_to_image' does not correctly handle a tiled image.

The (sent) image 'p0_06.j2k' contains 4 tiles:

   j2k_to_imge -i p0_06.j2k -o p0_06.ppm

creates 4 PPM images.

Reading ISO/IEC FCD15444-1 : 2000(V1.0, 16 March 2000), I am sure
that a tiled image is what PNG calls an interlaced image: only if
all components are combined, a single image becomes visible.

But the image 'p0_06.j2k' shows that the library does not handle
tiling correctly: the fourth PPM image is upside down.

So it seems that 

   1. the tiling algorithm of the library must be repaired.

   2. codec/convert.c must be repaired to combine all tiles such
      that finally one image is created.

The attached file convert_tile.c.7z is a proposal only. It uses
'imagetopnm' to combine the first three (!) tiles of 'p0_06.j2k':

   j2k_to_imge -i p0_06.j2k -o p0_06.ppm

The resulting single PPM file is a fairly good approximation.

winfried

What steps will reproduce the problem?
1. Set cp_reduce to non-zero value.
2. Decode a J2K file

What is the expected output? What do you see instead?
+ Expected: setting cp_reduce value to one decodes all layers except the most detailed
one. Setting cp_reduce value to two decodes all layers except the two more detailed
layers.
+ Actual: setting cp_reduce value to any non-zero value causes buffer overflow or crash.

What version of the product are you using? On what operating system?
+ Clean checkout from http://openjpeg.googlecode.com/svn/branches/v2
+ Windows 6 Pro, 64 bit.

Please provide any additional information below.
+ Patch corrects a problem in t2_skip_packet_data
+ The following steps were used to identify the problem.
++ Temporarily add two print statements to t2_decode_packets. 
+++ Print the value of l_nb_bytes_read returned by t2_decode_packet. 
+++ Print the value of l_nb_bytes_read returned by t2_skip_packet. 
++ Record the results from a full decode (cp_reduce is zero).
++ Record the results from a partial decode (cp_reduce is non-zero).
++ Compare the bytes read from the full and partial decodes.
+++ Too few bytes were being skipped on some packets.
++ Compare the source code for t2_read_packet_data to t2_skip_packet_data.
+++ Increment of l_band was missing from t2_skip_packet_data function.

Feature request.

In frames_to_mj2.c line 661 I see:
"  mj2_parameters.prec = 8;         /* Because in YUV files, components have 8-bit depth
*/"

Since YUV files may be made at higher bit depths (for instance `ffmpeg -i 16bitvideofile.mov
-f rawvideo -pix_fmt yuv422p16be 16bit.yuv`), can bit depth of the YUV components be
offered as an argument for frames_to_mj2?
Dave Rice

RFC 3745 seems to be the last document that validates
MIME types for JPEG2000.

4.1 Still Image Registration

Suffixes jp2 and jpg2 are possible; jp2 is preferred
MIME type: image/jp2

4.2 Extended Still Image Registration

The recommended file suffix is jpf; jpx is acceptable
MIME type: image/jpx

4.3 Motion Registration

Suffixes mj2 and mjp2 are possible
MIME type: video/mj2

4.4 Compound Image Registration

Suffixes jpm and jpgm are possible
MIME type: image/jpm

The binaries in the codec and mj2 directory of OpenJPEG
ignore the suffixes jpg2, jpf, jpgm and mjp2.

winfried

Hello guys

I wonder why JPEG2000 is still not popular and JPEG dating from 1992 is popular. If
we look at the video encoding world, no one uses such an old codec as MPEG-1 or MPEG-2.
How is it that JPEG2000 still couldn't replace JPEG?

What steps will reproduce the problem?
see http://groups.google.com/group/openjpeg/t/fb7692b5c3cff373 ("JPWL crash
in marker reallocation(+patch), segfault while decoding image with main
header protection" in openjpeg group)

What is the expected output? What do you see instead?
* marker reallocation should not seqfault
* JPWL header protection should work

What version of the product are you using? On what operating system?
SVN trunk on linux x86_64

Please provide any additional information below.

I have now made changes in jp2.c and jp2.h to handle pclr, cmap and
cdef. The files are attached as a whole.

jp2_read_colr(), jp2_read_jp2h() and jp2_decode() have been changed.

The changes are in jp2.c between 'begin INSERTION' and 'end INSERTION'.

First I inserted the necessary structures into opj_jp2_t . But then
I learned that MJ2 was unhappy with this decision. I have now made
the structures static in jp2.c . I suppose they can be inserted
into the opj_image_t, if static structures are unwanted.

It seems that I completely misunderstand the channel model of JP2.
Section I.5.3.6 in Part 1 suggest that there may be multiple opacity
channels. Until now I understood that there is either no channel or 
one channel for opacity, i.e. transparency.

I have found the four test files in the fdis_j2kp4files.zip archives.

testfiles_jp2/file2.jp2 contains a 'cdef' box:
===============================================
[0]cn(0) typ(0) asoc(3)
[1]cn(1) typ(0) asoc(2)
[2]cn(2) typ(0) asoc(1)

The color space is sYCC. Ignoring 'cdef' means: using the wrong color
for Y resp. Cr. The image had false colors. It looked ugly. Now it
looks nice.

testfiles_jp2/file9.jp2 contains a 'pclr' and a 'cmap' box:
===========================================================
The color space is sRGB. The image has one component: the index channel.
Ignoring 'pclr' and 'cmap' means: using the index channel as the color
channel. The result looked ugly. Now it looks nice.

testfiles_jp2/file5.jp2 and testfiles_jp2/file7.jp2 both contain an
===================================================
ICC Profile. I have written a simple program that reads the profile
correctly. But I do not know how to include the profile into jp2.c :
WHERE/WHEN shall the profile be read, WHO shall use the values, ...

Nice enterprise for someone else.

winfried

 AFAIK j2k.h and jp2.h header files are not installed on a standard
openjpeg installation. Is this intended ?
  Here is the issue I am currently facing, in order to reject lossy
JP2/J2K stream in clinical trial environment I had to code the
following:

  int reversible;
  opj_j2k_t* j2k = NULL;
  opj_jp2_t* jp2 = NULL;

  switch(parameters.decod_format)
    {
  case J2K_CFMT:
    j2k = (opj_j2k_t*)dinfo->j2k_handle;
    assert( j2k );
    reversible = j2k->cp->tcps->tccps->qmfbid;
    break;
  case JP2_CFMT:
    jp2 = (opj_jp2_t*)dinfo->jp2_handle;
    assert( jp2 );
    reversible = jp2->j2k->cp->tcps->tccps->qmfbid;
    break;
  default:
    gdcmErrorMacro( "Impossible happen" );
    return false;
    }
  LossyFlag = !reversible;

Unfortunately I need to include j2k.h  / jp2.h which is completely
non-standard on linux distribution.

What other people recommend for this situation:

- Extend openjpeg installation mechanism to install j2k.h / jp2.h
- Extend openjpeg.h API to return the reversible flag.

Thanks for suggestion 

Hello all,

I propose a small improvement for the /OPJ_COLOR_SPACE/ enum: when
reading a jp2 file, the /color_space/ member of the /opj_image/
structure is correctly set to one of the supported color spaces or
/CLRSPC_UNKNOWN/ if it's one of the color modes that is not supported by
the library.
On the other hand, when reading a j2k file (which, as far as I know,
doesn't contain any color space information), the /color_space/ field is
set to 0 as a consequence of the initial zeroing that happens when the
/opj_image/ object is allocated, since, after that moment, that field is
left untouched by the j2k decoder.
What I propose is to make official this behavior, and add to the
/COLOR_SPACE/ enum the member /CLRSPC_UNSPECIFIED = 0/. In this way a
library user that use common code to decode j2k and jp2 files can
reliably distinguish if the color space is not specified by the file (so
guessing is ok, since there is no other option) or if it is unsupported
by the library: when absolute fidelity to the original file is required,
in this last case failing may be a better choice than guessing.
The modify is really simple: just change the enum (file openjpeg.h, line
147) in this way:

/**

Supported image color spaces

*/

typedef enum COLOR_SPACE {

    CLRSPC_UNKNOWN = -1,    /**< not supported by the library */

    CLRSPC_UNSPECIFIED = 0,        /** < not specified in the file */

    CLRSPC_SRGB = 1,        /**< sRGB */

    CLRSPC_GRAY = 2,        /**< grayscale */

    CLRSPC_SYCC = 3            /**< YUV */

} OPJ_COLOR_SPACE;

By the way, is OpenJPEG supposed to support also the ICC mode of jp2 in
the near future?

Regards,
Matteo Italia 

Added a patch to support the MSVC Win 64 builds

Whatever the bitdepth specified in the header of pnm,pgm,ppm files, it will consider
255. 
Should change to read the specific bitdepth.

Functions affected :
* pnmtoimage
* imagetopnm

Whatever the bitdepth specified in the header of pnm,pgm,ppm files, it will consider
255. 
Should change to read the specific bitdepth.

Functions affected :
* pnmtoimage
* imagetopnm

What steps will reproduce the problem?

svn co http://www.openjpeg.org/svn/trunk
  cd trunk
  mkdir bin
  cd bin
  cmake .. -DBUILD_EXAMPLES:BOOL=ON



What is the expected output? What do you see instead?

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
  Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindTIFF.cmake:31 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  codec/CMakeLists.txt:40 (FIND_PACKAGE)



What version of the product are you using? On what operating system?

Checked out revision 606.
Fedora release 13 (Goddard)
Linux dcptest 2.6.33.3-85.fc13.x86_64



Please provide any additional information below.

Help

This is coverity ERROR CID: 570   (for blender)
Checker: RESOURCE_LEAK (help)
File: base/src/extern/libopenjpeg/t2.c
Function: t2_encode_packets
Description: Variable "pi" not freed or pointed-to in function
"pi_create_encode"

I've included a simple patch, not sure if its correct though...

As an alternative to using the "little CMS" library for color management, it would be
nice to expose the raw ICC profile information embedded in some images. The attached
patch adds two parameters to the opj_image_t struct - a pointer to a buffer for the
raw data, and an integer for the length of that buffer. The JP2 decode function then
sets these parameters if an ICC profile was present in the image. Finally image.c was
modified to free the buffer, it if exists, when calling opj_image_destroy, rather than
destroying it immediately after applying the profile. 

Presently I believe that an image with an embedded ICC profile will be marked as "CLRSPC_UNKNOWN"
regardless of wether the ICC was actually successfully applied to the image or not.
I think that if the ICC profile is being exposed to the user, they would want to know
wether the raw data in the component arrays has been transformed by the ICC profile
or not (to avoid applying it twice, or perhaps simply to be able to convey more information
about an image's color space to an end-user). Perhaps something like "CLRSPC_IMAGE_ICC"
in addition to CLRSPC_UNKNOWN? 

I have four jp2 images. All are incorrectly handled by 'j2k_to_image'.

Image 1:
========
It has a 'pclr' and a 'cmap' box. 'j2k_to_image' gets an image with
only one component and a CLRSPC_SRGB. The index values of the
component are used as color values.

Image 2:
========
It has three components and a 'cdef' box. 'j2k_to_image' creates an
image with false colors.

Image 3:
========
It has an ICC Profile that is skipped in 'jp2_read_colr'. 'j2k_to_image'
creates an image that is veiled. Nice, but incorrect.

Image 4:
========
It has an ICC Profile that is skipped in 'jp2_read_colr'. 'j2k_to_image'
creates an image where the bricks of buildings are not red-brown (correct)
but grey-brown (incorrect).



What is appended is not a patch but a proposal: jp2.c.7z is what I
wrote to get the values of 'pclr', 'cmap' and 'cdef'.

1. Structures must be created/changed to integrate the values found.
   I am sure that such a change is up to you. Is this condition TRUE?

2. 'pclr' has a parameter Bi with the description:'Palette column
   bit depth = value + 1. From 1 bit deep to 38 bits deep ..."
   38 bits for a pixel? ( ISO/IEC 15444-1:2004 (E), Table I.13 )

winfried

The attached JP2 image is a color image with YCbCr components, the Cb and
Cr components subsampled. The image renders fine with kdu_render, but
j2k_to_image seems to get stuck in an infinite loop.

What steps will reproduce the problem?
1. j2k_to_image -i reference.jp2 -o foo.ppm

What is the expected output? What do you see instead?
I've attached a .png version of the output that I get from kdu_render.

What version of the product are you using? On what operating system?
OpenJPEG V2 Alpha, on Linux/x86_64 (SuSE 10.3)

Please provide any additional information below.

Attached is mj2_convert.c.dif.7z . The original code creates a segfault.

winfried

The header "openjpegConfigure.h" appears to be missing from the repository in trunk.

What steps will reproduce the problem?
1. Set precincts as follow :
    parameters.res_spec =1;
    parameters.prcw_init[0] = 64;
    parameters.prch_init[0] = 64;
2. Compress an image 

What is the expected output? What do you see instead?
-Program crash with Access violation

What version of the product are you using? On what operating system?
- V2 branch from SVN (17 NOV)

Please provide any additional information below.
Crash occur on in j2k.c after line 8037 :
8014:for (j = tccp->numresolutions - 1; j >= 0; j--) {
...
8037:  tccp->prcw[j] = int_floorlog2(size_prcw); 

Because of the "for" condition j rolls over to 4292778402; this results in an access
violation when tccp->prcw[j] is written. Changing the condition from "j >= 0" to "j
> 0" should fix this issue.

the current opj_malloc.h code assumes malloc.h is available when __GNUC__
is available when really this check should be like __GLIBC__.

at any rate, here's a patch:
http://sources.gentoo.org/media-libs/openjpeg/files/openjpeg-1.3-freebsd.patch?view=markup

similar issue for Apple/GCC users:
http://sources.gentoo.org/media-libs/openjpeg/files/openjpeg-1.3-darwin.patch?view=markup

Attached is 'wrap_j2k_in_mj2.c.7z'.

The original code uses two times index 1: that does not
make sense.

By the way: only RGB is considered. Why not RGBA ?

winfried

This is in 2.0 SDK. I'm reading the headers of 55 jp2 files.

valgrind indicates that the memory allocated in jp2_read_header_procedure()

    l_current_data = opj_malloc(l_last_data_size);

is leaked. I can't see how this memory is intended to be freed.


==19281== 56,320 bytes in 55 blocks are definitely lost in loss record 218 of 218
==19281==    at 0x4A05E13: malloc (vg_replace_malloc.c:195)
==19281==    by 0x8A10898: jp2_read_header_procedure (jp2.c:508)
==19281==    by 0x8A12743: jp2_exec (jp2.c:1664)
==19281==    by 0x8A12966: jp2_read_header (jp2.c:1752)
==19281==    by 0x8A15929: opj_read_header (openjpeg.c:507)

Here is a (big) patch about autotools. There are some modifications of source files
because missing WIN32 --> _WIN32 changes.

It is the first step, though, as:

 * make distcheck does not pass in doc/ (the Makefile.am should be rewritten)
 * the compilation (mainly linkage, but also windirent.h) fails on Windows.

Maybe the parts where source files are modified can be applied first. The other part
need testing

Hello,

t2.c
line 568 :

cblk->data = (unsigned char*) opj_realloc(cblk->data, (cblk->len + seg-
>newlen) * sizeof(unsigned char*)); // <-- I believe this was meant to be 
sizeof(unsigned char)

Looking at the jp2_read_jp2h function in openjpeg I see that PCLR
(Palette Color) is not handled. Is this correct ? Is there a way for
me from the openjpeg/jp2 struct to retrieve whether or not the jp2
file contained a palette color ? I understand that openjpeg does not
support file such as
jpeg2000testimages/Part4TestStreams/testfiles_jp2/file9.jp2, but it
would be nice if one could detect that, and report an error early on.

Thank you,
-- 
Mathieu 

Please integrate those patches:

http://groups.google.com/group/openjpeg/browse_thread/thread/cb22538b0327f514/463f7504255e4d29?q=

Thanks

pclr,cmap,colr,ICC profile patch.

winfried

The function leaks the l_current_data it allocates. This was revealed with
Valgrind. 

Attached a patch that fixes the issue (I haven't checked if the leak is in
trunk, as I'm currently working with v2 branch)

It would be very useful to be able to specify a rectangular region of interest to be
extracted when using j2k_to_image. This is especially useful when working with very
large images where only small portions of the images are needed.

What steps will reproduce the problem?
1. Checkout Sourcecode Revision 570 on Kubuntu 64
2. Compile & Install Library
3. cd ./codec; gcc convert.c image_to_j2k.c -o image_to_j2k -lopenjpeg -I
../libopenjpeg/ -lm -ltiff

What is the expected output? What do you see instead?
Should compile right, but gives ~20 errors about undefined references, e.g.:
convert.c:(.text+0x87c8): undefined reference to `png_create_read_struct'

What version of the product are you using? On what operating system?
2.x Revision 570

Please provide any additional information below.
Standard installation
Kubuntu 10.04 x86_64
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Linux version 2.6.32-22-generic

usr@MPC0:/usr/lib64$ ls /usr/lib64 | grep jpeg
libjpeg.a
libjpeg.la
libjpeg.so
libjpeg.so.62
libjpeg.so.62.0.0
liblavjpeg-1.9.so.0
liblavjpeg-1.9.so.0.0.0
libmjpegutils-1.9.so.0
libmjpegutils-1.9.so.0.0.0
libopenjpeg-2.1.3.0.so
libopenjpeg-2.1.4.0.so
libopenjpeg.a
libopenjpeg.so.2

please feel free to contact me over [email protected] for more
information

To:[email protected]
Subject: [OpenJPEG] OpenJPEG_v13: tiled image part 2

The appended archive contains five files. 

speed_00000.j2k is the first of 200 files extracted from the example
                movie Speedway.mj2 using extract_j2k_from_mj2 .
                geometry:352 x 288

j2k_to_image -i speed_00000.j2k -o speed.ppm created three files:
0.speed.ppm 352 x 288
1.speed.ppm 176 x 144
2.speed.ppm 176 x 144

speed_00000.bmp has been created by jasper using:
jasper --force-srgb --input speed_00000.j2k --output speed_00000.bmp

winfried

http://groups.google.com/group/openjpeg/browse_thread/thread/f1d6068fd5dd5058

Hello,

Could some one shed light on the maximum bit depth supported by the
OpenJPEG implementation of JP3D ?

I've been able to successfully compress SHORT and CHAR images.

However INT images (even those with a bpp <= 31) (I've tried 30 and
31) seem to segfault. FLOAT  segfaults as well.

Thanks
-- 
karthik

------------------
Here is the stacktrace:

Program received signal SIGSEGV, Segmentation fault.
0x00002b7c8165e9ff in t1_encode_cblks (t1=0x2b7cd5e98010,
tile=0x60b710, tcp=0x60a2c0)
    at /home/karthik/OpenJPEG/src/trunk/jp3d/libjp3dvm/t1.c:1008
1008                                            t1->data[k][j][i] =
(gdb) bt
#0  0x00002b7c8165e9ff in t1_encode_cblks (t1=0x2b7cd5e98010,
tile=0x60b710, tcp=0x60a2c0)
    at /home/karthik/OpenJPEG/src/trunk/jp3d/libjp3dvm/t1.c:1008
#1  0x00002b7c8166fffa in tcd_encode_tile (tcd=0x60b680, tileno=0,
dest=0x2b7c9a39c087 "", len=398458759,
    volume_info=0x60a200) at /home/karthik/OpenJPEG/src/trunk/jp3d/
libjp3dvm/tcd.c:1513
#2  0x00002b7c81652399 in j3d_write_sod (j3d=0x60a0e0,
tile_coder=0x60b680)
    at /home/karthik/OpenJPEG/src/trunk/jp3d/libjp3dvm/jp3d.c:1409
#3  0x00002b7c81655eb8 in j3d_encode (j3d=0x60a0e0, cio=0x60b300,
volume=0x60a010,
    index=0x7fff29683b70 "/home/karthik/Data/JPEG2000/JP3D/Cardiac/Int/
Compressed/Cardiac-INT-LE.Idx")
    at /home/karthik/OpenJPEG/src/trunk/jp3d/libjp3dvm/jp3d.c:2303
#4  0x00002b7c81657d4c in opj_encode (cinfo=0x60a0b0, cio=0x60b300,
volume=0x60a010,
    index=0x7fff29683b70 "/home/karthik/Data/JPEG2000/JP3D/Cardiac/Int/
Compressed/Cardiac-INT-LE.Idx")
    at /home/karthik/OpenJPEG/src/trunk/jp3d/libjp3dvm/openjpeg.c:200
#5  0x0000000000403dd3 in main (argc=11, argv=0x7fff29683dc8)
    at /home/karthik/OpenJPEG/src/trunk/jp3d/codec/volume_to_jp3d.c:
861 

(OpenJPEG 1.3, Vista Business)

On some gray16 images (conceivably which have too many different colors)
j2k encoder crashes while freeing memory in tcd_free_encode(opj_tcd_t *tcd)
on this string:
   opj_free(prc->cblks.enc[cblkno].data - 2);

dbgheap.c
> image_to_j2k.exe!_CrtIsValidHeapPointer(const void *
pUserData=0x01069f20)

Version 1.2 didn't crash on such images, but i tested it less than 1.3,
since i need lossless j2k.

Steps to reproduce: try to encode attached file (random.tif) with
image_to_j2k.exe