CharLS, a JPEG-LS library

Commented Issue: info.allowedlossyerror=1 fails [11721]

awik — Thu, 25 Apr 2013 09:55:45 GMT

Dear CharLS developer,

if I compress/decompress the attached image with info.allowedlossyerror=1, there are red/blue spread pixels on dark areas at output.

(modified test/util.cpp/TestRoundTrip and test/performance.cpp for testing).

Kind regards,
pink_letter
Comments: ** Comment from web user: awik **

It seems that this kind of artificats is a normal thing when JPEG-LS works in lossy mode (allowedlossyerror <> 0).
The higher value of "allowedlossyerror" property (up to 9) the more visible are these specific artificats.

Created Issue: info.allowedlossyerror=1 fails [11721]

pink_letter — Fri, 19 Apr 2013 16:03:58 GMT

Commented Issue: Uninitialised memory causing decode failure [11253]

psychon — Fri, 26 Oct 2012 14:31:48 GMT

Hi,

we recently stumbled upon an image which failed decoding with a message saying "Codec does not support the image's color transformation" (This is charLS' error UnsupportedColorTransform). Some printf-debugging figured out that the colorTransform was set to 0xCCCCCCCC. Some more debugging figured out that this was due to uninitialized memory.

The attached patch makes JpegMarkerReader zero out its JlsParameters instance before using it. As far as I can tell, this is the only place were a JlsParameters instance is constructed without getting assigned values from elsewhere. At first, I wanted to add a suitable default constructor to JlsParameters, but since this is in interface.h, this isn't possibly.

Feel free to come up with a less ugly patch for this issue (and perhaps even a comment explaining why this is necessary?).

Cheers,
Uli
Comments: ** Comment from web user: psychon **

This was seen with MSC6, so the compiler surely is not conformant.

According to [0], the default-initialisation rule was added in C++03, thus 5 years after MSC6 was released. So MSC6 can't really conform to that rule. :-)

[0]: http://stackoverflow.com/questions/4263904/c-pod-initialization-via-default-ctor

Commented Issue: Uninitialised memory causing decode failure [11253]

jdv — Thu, 25 Oct 2012 21:09:15 GMT

Hi.

Sorry for being unresponsive. With what compiler are you seeing this? Either it is not conformant, or I am overlooking something.

the initializer list item " _info() " should default-initialize the variable _info. As this is a struct with no user defined constructor, it should apply the generated default constructor. This calls the default constructor for all members, which are all primitive types, and default-initializing them will boil down to zero-initialize.

New Post: Convert from Bitmap

gioC — Tue, 16 Oct 2012 05:22:31 GMT

Could you please add a C# sample of decoding .jls files into .bmp?

New Post: Error at JPEGLSCodec.cs

gioC — Sun, 14 Oct 2012 11:31:33 GMT

Good day Sir, I'm using the CharLS_VS2010 and im trying to run it. I'm having errors at JPEGLSCodec.cs saying "Unable to load DLL 'CharLS.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"

What could be the possible problems, I've been working on this the whole day, It would really be appreciated if you answered.

Commented Issue: Uninitialised memory causing decode failure [11253]

awik — Fri, 12 Oct 2012 09:28:52 GMT

It seems that in CharLS 1.0 this patch should be applied in
JLSInputStream::JLSInputStream(const BYTE* pdata, size_t cbyteLength)
constructor body.

Created Issue: Redundant code in header.cpp (CharLS 1.0) [11258]

awik — Thu, 11 Oct 2012 20:43:51 GMT

In the function JLS_ERROR CheckParameterCoherent(const JlsParameters* pparams) below statements appear twice:
if (pparams->bitspersample < 6 || pparams->bitspersample > 16)
return ParameterValueNotSupported;

Created Issue: Uninitialised memory causing decode failure [11253]

psychon — Tue, 09 Oct 2012 08:19:40 GMT

New Post: I'm having a really hard time trying to use the JPEG-LS Library.

gioC — Sat, 06 Oct 2012 13:32:53 GMT

Good day, I'm a college student, using the CharLS_VS2010 C# for academic studies. I'm having a hard time trying to use this library. Can anyone provide me with a comprehensible example? Where maybe I'll just provide a path, and when I run the program it will compress the image? Thank you. I plan to use lossless mode of compression on color digital photographs. I'm using windows 32-bit.

Commented Issue: Hang when encoding 16-bit monochrome [11246]

etotheipi — Fri, 05 Oct 2012 03:33:37 GMT

Sorry, I couldn't figure out how to swap attachments. The first main.cpp was an older version I copied by accident from the wrong location. The second main.cpp is the correct one. On my system, it runs in release, but hangs in debug.

Created Issue: Hang when encoding 16-bit monochrome [11246]

etotheipi — Fri, 05 Oct 2012 03:21:43 GMT

This error is very inconsistent -- most importantly it hangs mostly in Debug mode, but not in Release mode (makes it 90% of the time in Release). I'm probably just doing something wrong, please tell me what it is.

The code is freezing at header.cpp:102, because _vecbyte.size() is approximately 3e10:

pstream->WriteBytes(_vecbyte);

I put the following in a main.cpp file and executed it on emptyfpa.txt.

--------------------------------------
int main(void)
{
ifstream is("emptyfpa.txt", ios::in);
unsigned short * imgUncompr = new unsigned short[512*512];

const int w = 512;
const int h = 512;
const int bps = sizeof(unsigned short);
const int imgBytes = w * h * bps;

int unpack;

for(int r=0; r> unpack;
imgUncompr[r*512+c] = (unsigned short)unpack;
}
}

JlsParameters img_info;
img_info.width = w;
img_info.height = h;
img_info.bitspersample = 8*bps;
img_info.bytesperline = bps*w;
img_info.components = 1;
img_info.allowedlossyerror = 0;
img_info.ilv = ILV_NONE;
img_info.colorTransform = 0;
img_info.outputBgr = 0;

BYTE* imgCompr = new BYTE[imgBytes];
size_t comprBytes;

JLS_ERROR errCode = JpegLsEncode((void*)imgCompr, imgBytes,
&comprBytes,
(void*)imgUncompr, imgBytes,
&img_info );

cout << "Error Code: " << errCode << endl;
if(errCode!=OK)
{
cout << "Encoding failed: Error code " << (int)errCode << endl;
exit(0);
}

cout << "Compressed image is " << comprBytes << " bytes" << endl;
return 0;
}
--------------------------------------

Source code checked in, #79962

Project Collection Service Accounts — Mon, 01 Oct 2012 21:14:48 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #79961

Project Collection Service Accounts — Mon, 01 Oct 2012 21:08:39 GMT

Checked in by server upgrade

New Post: DClunies and DICOM samples, fragment headers

khajj — Sat, 15 Sep 2012 21:58:23 GMT

Hello,

I have managed to extract the JPEG-LS things from DClunies sample files. The bad part is, that they cant be decoded. (Even real dicoms incoming from CTs have a similar issue)

Please, have a look at those files (in the link) and tell me what am I doing wrong, if you have any idea. I will appreciate it very much.

Anyway Iam, too, interested in jpeg-ls decoding, so I have sent a mail to dclunie (Attached below). As soon as he responses, i will post his answer too.

(BTW I saw a similar problem about fragmented headers here, so Iam posting the link to the extracted dclunies files for you too. If my dicom extractor is OK, I can help you too - feel free to send me another dicom samples to khajj@seznam.cz, i will extract the fragment headers for you)

Link to 2shared:

http://www.2shared.com/file/Y_7zx3t1/JPEGLSTESTS.html

Copy of mail to DClunie:

Hello,

i was studying your site for JPEG-LS decoding of DICOM images for work to school. Thank you for resources.

But I have a problem - after extracting jpeg-ls raw data from DICOM images (like removing the fragment headers) by a proper dicom parser, i send the JPEG-LS coded images through 2 decoders - CharLS and "original HP loco code".

The problem is, that every sample image (excluding "mr1") threw an error (like premature end of file, failed assertion on an constant etc) on both implementations (charLS,loco).

I would like to make an functional jpeg-ls decoder.

Can you please check, if I extracted the data right? (probably yes, thats the reason why mr1 succeeded)

What JPEG-LS decoder do you personally use? (Can you send me the code please?)

Attached link to 2shared, in the zip file there are included

1) original dicom images (yours)

2) extracted pure jpeg-ls data (named after serie name+.bin) - I would be gratefull, if you check them against your original images, maybe the error.

3) mr1out.bin result after completing loco code

4) my sample project of loco code in BCB5 (that is not currently downloadable by the way)

Thank you wery much,

Martin Holecek

Source code checked in, #79227

vbaderks — Tue, 28 Aug 2012 21:32:09 GMT

Updated for Visual Studio 2012 RTM

New Post: JPEG-LS video codec required

ranma500 — Thu, 12 Jul 2012 04:33:54 GMT

I need the creation of a video codec.

INPUT: 12-bit greyscale video at up to 35fps 1920x1080 resolution

COMPRESSION - Lossless or mild compression

TECHNOLOGY TO BE USED: JPEG LS

WRAPPER: Should use standard FourCC protocols and compatible with AVI wrapper.

SPECIAL: Will require spatial transform on the data prior to compression.

VARIABLES: pixel dimensions of incoming video
lossless/amount of acceptable loss
four spatial transform options

SPEED REQUIREMENTS: Must encode in real time

PLATFORM: PC - Windows 7 - Must be 64-bit compatible.

Anyone interested?

Paul Spurrier

paul@paulspurrier.com

Commented Issue: Failed assertion in EncodeStrategy [10742]

MarcoNeoL — Mon, 14 May 2012 15:00:32 GMT

Hi,

we received a bug report for the copy of CharLS that is part of the DCMTK:
http://forum.dcmtk.org/viewtopic.php?f=1&t=3412

I took a look at this file and I think that this is indeed a bug in CharLS.

The attached patch creates an EncoderStrategy instance and writes bits to it. This triggers the same assertion as the original test image. (Ignore my changes to encoderstrategy.h, that's just the debug output that I looked at for figuring this out):

encoderstrategy.h:95: void EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0' failed.

My analsysis of what is going on is part of the patch, so be sure to read the comments. :-)

I tried to come up with a patch that fixes this. This is the following part of the diff:

- if (bitpos >= 0)
+ if (bitpos > 0)

The idea here is that when 32 bits of input were read, we can Flush().

This should even fix a similar issue, where we have bitpos == 1 and add 31 input bits, so one bit gets added to valcurrent. If Flush() only writes out 30 bits, all the 30 bits of input left can go into the buffer.

Cheers,
Uli
Comments: ** Comment from web user: MarcoNeoL **

Hi.

as you certainly know, ASSERTs are disabled in Visual Studio when the "NDEBUG" symbol is defined, which is normally the case for "Release" builds.

Nevertheless, in our specific case we built OFFIS DCMTK (embedding CharLS) starting from OFFIS v3.6.0 CMake files, and for some reason our "Release" build of OFFIS DCMTK did NOT have the "NDEBUG" symbol defined. Not sure if this depended on some "peculiarities" of the makefiles...

Hence, we were having ASSERTs (which related aborts) also in Release mode.

Best regards,

Marco

Commented Issue: Failed assertion in EncodeStrategy [10742]

jdv — Mon, 14 May 2012 14:14:57 GMT

re decodability: When compiling with Visual Studio, all ASSERT()s are removed in release mode.

I thought it also worked that way for the cmake based build. Will check that later.

Commented Issue: Failed assertion in EncodeStrategy [10742]

MarcoNeoL — Mon, 14 May 2012 08:27:24 GMT

Hi Jan,

with reference to your sentence:

<< The funny thing is I got a similar bug report earlier this week. >>,

I think this is actually the same test case!
In fact, we reported the issue both to you and on the DCMTK forum.

What we do not know (and DCMTK developers certainly know better) is if/where the CharLS embedded into DCMTK is different from the "standard" CharLS.

If we can help further somehow, please let us know.
Thanks,

Marco