qizhrj / openjpeg Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/openjpeg
License: Other
Automatically exported from code.google.com/p/openjpeg
License: Other
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 issue reported on code.google.com by [email protected]
on 22 Nov 2010 at 8:42
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 19 Nov 2010 at 7:50
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
Original issue reported on code.google.com by [email protected]
on 24 Mar 2010 at 12:36
Attachments:
Download-Date: 17.05.2010
winfried
Original issue reported on code.google.com by [email protected]
on 18 May 2010 at 1:19
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 26 May 2010 at 5:44
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
Original issue reported on code.google.com by mathieu.malaterre
on 8 Jun 2009 at 8:18
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
Original issue reported on code.google.com by [email protected]
on 4 Dec 2010 at 8:14
Attachments:
Currently the Visual Studio builds are broken in the SVN. Attached a patch to
fix this issue.
Original issue reported on code.google.com by [email protected]
on 21 Oct 2010 at 8:24
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 20 Jan 2010 at 3:04
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
Original issue reported on code.google.com by [email protected]
on 3 Oct 2010 at 10:15
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
Original issue reported on code.google.com by [email protected]
on 23 May 2010 at 1:49
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 22 Nov 2010 at 10:18
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
Original issue reported on code.google.com by [email protected]
on 15 May 2010 at 2:41
Attachments:
Attached is mj2_convert.c.dif.7z . The original code creates a segfault.
winfried
Original issue reported on code.google.com by [email protected]
on 30 Mar 2010 at 5:33
Attachments:
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?v
iew=markup
similar issue for Apple/GCC users:
http://sources.gentoo.org/media-libs/openjpeg/files/openjpeg-1.3-darwin.patch?vi
ew=markup
Original issue reported on code.google.com by [email protected]
on 20 Mar 2010 at 6:07
(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
Original issue reported on code.google.com by [email protected]
on 31 Jul 2009 at 3:14
Attachments:
pclr,cmap,colr,ICC profile patch.
winfried
Original issue reported on code.google.com by [email protected]
on 21 Jun 2010 at 12:23
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 10 Mar 2010 at 7:50
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 25 Feb 2010 at 9:07
Please integrate those patches:
http://groups.google.com/group/openjpeg/browse_thread/thread/cb22538b0327f514/46
3f7504255e4d29?q=
Thanks
Original issue reported on code.google.com by mathieu.malaterre
on 18 Dec 2009 at 10:47
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
Original issue reported on code.google.com by mathieu.malaterre
on 8 Jun 2009 at 8:33
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/....
Original issue reported on code.google.com by [email protected]
on 20 Mar 2010 at 5:49
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=%2Fg
roup%2Fopenjpeg%2Fbrowse_frm%2Fmonth%2F2008-07%3F&
Original issue reported on code.google.com by mathieu.malaterre
on 7 Oct 2009 at 8:47
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
Original issue reported on code.google.com by [email protected]
on 22 Sep 2010 at 2:42
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 2 Jul 2009 at 8:17
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
Original issue reported on code.google.com by antonin
on 25 Sep 2009 at 4:24
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
Original issue reported on code.google.com by [email protected]
on 29 Apr 2010 at 4:40
Attachments:
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
Original issue reported on code.google.com by mathieu.malaterre
on 8 Jun 2009 at 8:31
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.
Original issue reported on code.google.com by [email protected]
on 29 Sep 2010 at 2:29
Attachments:
Original code, imagetopng(), line 6:
int has_alpha, w, h;
Please change to:
int has_alpha = 0, w, h;
winfried
Original issue reported on code.google.com by [email protected]
on 30 Mar 2010 at 5:30
OpenJpeg currently doesn't compile in C++ Builder.
Patch to fix this is attached.
Original issue reported on code.google.com by [email protected]
on 26 Jan 2010 at 1:03
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 2 Jul 2010 at 12:20
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
Original issue reported on code.google.com by [email protected]
on 12 May 2010 at 1:11
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 16 May 2010 at 4:06
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 5 May 2010 at 2:28
The header "openjpegConfigure.h" appears to be missing from the repository in
trunk.
Original issue reported on code.google.com by [email protected]
on 8 Sep 2010 at 8:39
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
Original issue reported on code.google.com by [email protected]
on 10 Mar 2010 at 5:48
Attachments:
Added a patch to support the MSVC Win 64 builds
Original issue reported on code.google.com by [email protected]
on 21 Oct 2010 at 8:45
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 6 Nov 2009 at 5:09
Attachments:
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?
Original issue reported on code.google.com by [email protected]
on 4 Nov 2010 at 5:43
Attachments:
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
Original issue reported on code.google.com by antonin
on 25 Sep 2009 at 4:23
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.
Original issue reported on code.google.com by [email protected]
on 15 Sep 2010 at 7:44
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
Original issue reported on code.google.com by mathieu.malaterre
on 7 Oct 2009 at 8:45
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...
Original issue reported on code.google.com by [email protected]
on 16 May 2010 at 9:35
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 30 Mar 2010 at 5:35
Attachments:
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);
Original issue reported on code.google.com by [email protected]
on 13 Mar 2010 at 1:56
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...
Original issue reported on code.google.com by [email protected]
on 25 Aug 2009 at 6:03
Attachments:
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?
Original issue reported on code.google.com by [email protected]
on 3 Sep 2010 at 3:51
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
Original issue reported on code.google.com by [email protected]
on 30 Nov 2010 at 3:17
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) ?
Original issue reported on code.google.com by [email protected]
on 15 Jun 2010 at 6:52
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.