I'm also using theijl functions for JPEG decoding (ijlRead, etc..)
I'm using these functions to decode JPEG's i receive from a camera and display and archive them.
My problem is that eventually after a certain amount of image decoding one of my threads keep getting IJL errors -1.
I'm still debugging it but so far i've found that it gets into a state of only producing exceptions every time i try and decode the image, but when i save it to disk it looks fine, then i take the image and load it up separately into another IJLRead and it works fine.
Looking through my archives i've found some images where it started giving me the exception problem so i tested them out separately.
The images are all timestamped and in order
#1. 12967928601265.jpeg - a good image, windows can display it fine
#2. 12967928601296.jpeg - windows cannot display, something is wrong with it
#3. 12967928601328.jpeg- windows cannot display, something is wrong with it
#4. 12967928601359.jpeg- windows cannot display, something is wrong with it
#5. 12967928601390.jpeg - a good image, windows can display it fine
Test 1: loading 4,5. I get an IJL Data Error when trying to load #4 then #5 loads fine.
Test 2: load 2,3,4,5. I get Data errors for 2,3,4 and 5 loads fine.
Test 3: load 1,2,3,4,5. they all load with IJL_OK returned --very weird?
Is it possible that my camera sends me wrong data, or i parse it incorrectly and that causes some part of IJL to keep crashing?
----As this problem is occuring(get IJL Exception message) i have 2 other cameras that are receiving and decoding
you did not specify what IJL library did you use. Was it IJL product (the latest version was 1.51 released many years ago) or it was IPP sample which reimplemented IJL interface but internally called IPP functions?
Please note that since IJL time we had implemented Unified Image Codec (UIC) framework, which have a number of improvements over IJL (it supports number of image codecs, including JPEG, JPEG2000 and JPEG-XR, it support threading on codec level and it has improved robustness). I would recommend you to migrate to this new image codec API keeping in mind all these improvements.