0

I'm trying to learn how to use the jpeg-turbo library. And I'm have a devil of a time getting started. The example.c example in the doc folder, and every single example I find on the web, crashes in VS2013 when I try to read a .jpg file. They compile fine. But when I run them they crash with an access violation error.

What I really need is a tiny working (beginner friendly) example that is known to run properly in VS2013 x64. Including the main(){} code block code. And if there's anything special in the VS project properties that I might need to set that could be causing this crashing.

I'm pulling my hair out just trying to get one simple example working.

Thanks for the help.

*Edit-- Here is a very small example. I've also tried to get jpeglib to run with and without using Boost/GIL But it always crashes when loading the image: exception at 0x00000000774AE4B4 (ntdll.dll)

#include <stdio.h>
#include <assert.h>
#include <jpeglib.h>

#pragma warning(disable: 4996)

int main(int argc, char* argv[])
{
    struct jpeg_decompress_struct cinfo;
    struct jpeg_error_mgr jerr;
    JSAMPARRAY buffer;
    int row_stride;

    //initialize error handling
    cinfo.err = jpeg_std_error(&jerr);

    FILE* infile;
    infile = fopen("source.jpg", "rb");
    assert(infile != NULL);

    //initialize the decompression
    jpeg_create_decompress(&cinfo);

    //specify the input
    jpeg_stdio_src(&cinfo, infile);

    //read headers
    (void)jpeg_read_header(&cinfo, TRUE);

    jpeg_start_decompress(&cinfo); <----This guy seems to be the culprit

    printf("width: %d, height: %d\n", cinfo.output_width, cinfo.output_height);

    row_stride = cinfo.output_width * cinfo.output_components;

    buffer = (*cinfo.mem->alloc_sarray)
        ((j_common_ptr)&cinfo, JPOOL_IMAGE, row_stride, 1);

    JSAMPLE firstRed, firstGreen, firstBlue; // first pixel of each row, recycled
    while (cinfo.output_scanline < cinfo.output_height)
    {
        (void)jpeg_read_scanlines(&cinfo, buffer, 1);
        firstRed = buffer[0][0];
        firstBlue = buffer[0][1];
        firstGreen = buffer[0][2];
        printf("R: %d, G: %d, B: %d\n", firstRed, firstBlue, firstGreen);
    }

    jpeg_finish_decompress(&cinfo);

    return 0;
}
ScottA
  • 61
  • 1
  • 6
  • Welcome to Stack Overflow.You can't ask for example code or off site resources here, sorry. – πάντα ῥεῖ Jan 03 '16 at 21:46
  • Why don't you post the code that you tried and any error messages and maybe someone will see why it is not working? – Galik Jan 03 '16 at 21:48
  • I didn't post any code because not even the sample that comes with the library works. But if you need code. Then here's a very simple example that crashes (access violation error) when it runs. *edit..I'm sorry but I'm new to Stack Overflow and I'm having trouble posting code – ScottA Jan 03 '16 at 22:02
  • Debug the code in the debugger to get a hint of why there is an access violation. You have the full source, nothing stops you from debugging it. At least it gives others something to work with other than "I get an access violation". Even if it's something like "hey, the array is declared as 10, but the code is accessing index 100" or something like that -- that is what you should be able to find out. How to fix it is another story, but at least discover why the violation occurs. – PaulMcKenzie Jan 03 '16 at 22:36
  • Guys. I would be happy to post a code example for you to look at. But I'm new here and I'm have a hard time getting my code to post properly. The includes get mangled. This is very unusual forum software. Typically on other forums I just surround my code with a [code] [/code] and it works just fine. This place is much more picky. I need to figure out how to do it...sorry. I hate being a newb. – ScottA Jan 03 '16 at 22:46
  • Use the debugger to step into the `jpeg_start_decompress` function to determine which line is causing the access violation. – PaulMcKenzie Jan 03 '16 at 23:09
  • This is the error: exception at 0x00000000774AE4B4 (ntdll.dll) in gil.exe: 0xC0000005: Access violation writing location 0x0000000000000024. It happens whenever I try to read a .jpg image. Even when using GIL in Boost (which also uses the same jpeglib library). And jpeg_read_image() is found in the jpeg_io.hpp file. Not usre if that helps? – ScottA Jan 03 '16 at 23:16

2 Answers2

1

I found the problem.

In my VS project's Linker->Input->Additional Dependencies. I changed it to use turbojpeg-static.lib. Or jpeg-static.lib when I'm using the non turbo enhanced libraries.

The turbojpeg.lib or jpeg.lib crashes for some reason when reading the image.

FYI, I am using the libjpeg-turbo-1.4.2-vc64.exe version with VS2013. And this is how I got it to work.

ScottA
  • 61
  • 1
  • 6
  • Is the turbojpeg.lib / jpeg.lib import libraries or static libraries? In other words, did the application use external DLL's to access the jpeg routines? If so, then the possible reason for the crash is due to different heaps being used by the application and the DLL. – PaulMcKenzie Jan 04 '16 at 17:39
  • I really don't know. I'm fairly new to this. All I can tell you is that there is a .dll file in the bin folder next to a bunch of .exe files. And when I try to use the non static jpeg.lib version in my properties. I do need to put a copy of this .dll file in my Release folder for it to even launch(similar to using Qt). But for some reason it crashes when trying to read(decompress) images. Using the static version seems to work fine. So that's what I'm going to use from now on....Now I just have to learn how to use it ;-). – ScottA Jan 04 '16 at 19:07
1

One more very important thing that I learned that I'd like to share. When writing to a new .jpg image. If the new image size is different than the source image. It will typically crash. Especially if the new size is larger than the source. I'm guessing this happens because it takes a much longer time to re-sample the color data to a different size. So this type of action might require it's own thread to prevent crashing.

I wasted a lot of time chasing code errors and compiler settings due to this one. So watch out for that one.

ScottA
  • 61
  • 1
  • 6