需要在VS2013 x64中工作的jpeglib turbo的示例

Question

我正在学习如何使用jpeg-turbo库。我开始的时候真是太麻烦了。doc文件夹中的example.c示例，以及我在网上找到的每一个示例，在VS2013中当我尝试读取.jpg文件时都会崩溃。它们汇编得很好。但当我运行它们时，它们会因访问违规错误而崩溃。

我真正需要的是一个可以在VS2013 x64中正常运行的小型工作（初学者友好）示例。包括main（）｛｝代码块代码。如果VS项目属性中有什么特殊的东西，我可能需要设置，这可能会导致崩溃。

我只是想让一个简单的例子发挥作用。

谢谢你的帮助。

*编辑--这是一个非常小的例子。我还尝试过让jpeglib在使用和不使用Boost/GIL的情况下运行但它在加载图像时总是崩溃：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: %dn", 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: %dn", firstRed, firstBlue, firstGreen);
    }
    jpeg_finish_decompress(&cinfo);
    return 0;
}

Answer 1

我发现了问题。

在我的VS项目的Linker->Input->Additional Dependencies中。我把它改为使用turbojpeg-static.lib。或者在使用非turbo增强库时使用jpeg-stasic.lib。

turbojpeg.lib或jpeg.lb在读取图像时由于某种原因崩溃。

仅供参考，我使用的是带有VS2013的libjpeg-turbo-1.4.2-vc64.exe版本。这就是我工作的方式。

Answer 2

我学到了一件非常重要的事情，我想与大家分享。写入新的.jpg图像时。如果新图像的大小与源图像的大小不同。它通常会崩溃。特别是如果新的大小大于源的大小。我猜发生这种情况是因为将颜色数据重新采样到不同大小需要更长的时间。因此，这种类型的操作可能需要它自己的线程来防止崩溃

由于这个原因，我浪费了很多时间来查找代码错误和编译器设置。所以要小心那个。