Question About Grayscale Output

19 views
Skip to first unread message

Kevin McBride

unread,
Jul 3, 2021, 10:48:35 PM7/3/21
to libjpeg-turbo User Discussion/Support
Good evening,

I am working on my project stick2xyz  http://sourceforge.net/projects/stick2xyz
and I have an image that is mirroring itself after the source buffer has been passed to tjCompress2 with the following args:

tjCompress2(
        jpeghandle,
        srcbuf,
        x,  // x is 320
        y * 1,
        y,  // y is 240
        TJPF_GRAY,
        &jpegBuf,
        &jpegSize,
        TJSAMP_GRAY,
        100,
        TJFLAG_STOPONWARNING)

I am using version 2.0.90 from Fedora.  Attached is the memory dump of srcbuf in hex as well as the output jpeg I got.

I do not want the image data duplicated to the right of the image while in tjCompress2.


output00001.jpeg
test.txt

DRC

unread,
Jul 4, 2021, 9:51:08 AM7/4/21
to libjpeg-t...@googlegroups.com
At first glance, it appears as if you are setting the pitch argument incorrectly. Should that not be x * 1 rather than y * 1?

On Jul 3, 2021, at 8:48 PM, 'Kevin McBride' via libjpeg-turbo User Discussion/Support <libjpeg-t...@googlegroups.com> wrote:


<output00001.jpeg>

--
You received this message because you are subscribed to the Google Groups "libjpeg-turbo User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libjpeg-turbo-u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libjpeg-turbo-users/ba7a1531-7b23-4631-b084-1c890d432de2n%40googlegroups.com.
<test.txt>
<output00001.jpeg>

Kevin McBride

unread,
Jul 4, 2021, 3:45:49 PM7/4/21
to libjpeg-turbo User Discussion/Support
I changed the call to tcCompress2 to the following and still do not get the expected result:

tjCompress2(
        jpeghandle,
        srcbuf,
        x,
        x * tjPixelSize[TJPF_GRAY],
        y,

        TJPF_GRAY,
        &jpegBuf,
        &jpegSize,
        TJSAMP_GRAY,
        100,
        TJFLAG_STOPONWARNING)

output00001.jpeg

Kevin McBride

unread,
Jul 4, 2021, 4:38:38 PM7/4/21
to libjpeg-turbo User Discussion/Support
I found the problem in my code.  I was not correctly converting the image data into a single dimension unsigned char array.  I changed the code to the following, and I managed to get the PNG-style array converted into the array that TurboJPEG accepts.  I also corrected the pitch.

srcbuf2 = srcbuf = (unsigned char *)calloc(x, y);
    if ( srcbuf == NULL )
        return 0;
    /* Fill the jpeg buffer. */
    for ( i=0; i < y; i++ )
    {
        memcpy(srcbuf2, image[i], x);
        srcbuf2 += x;
    }

Now the image comes out looking the same as the PNG.  First image is the JPEG, second image is the PNG.
output00001.jpegoutput00001.png

Thank you for the help, DRC.

DRC

unread,
Jul 5, 2021, 11:14:20 AM7/5/21
to libjpeg-t...@googlegroups.com
You can probably avoid that memcpy() and thus improve performance if you set the pitch argument to the actual distance between the rows in the multi-dimensional array, but without knowing the specifics of the multi-dimensional array, I couldn’t tell you the appropriate pitch to use.

On Jul 4, 2021, at 3:38 PM, 'Kevin McBride' via libjpeg-turbo User Discussion/Support <libjpeg-t...@googlegroups.com> wrote:


I found the problem in my code.  I was not correctly converting the image data into a single dimension unsigned char array.  I changed the code to the following, and I managed to get the PNG-style array converted into the array that TurboJPEG accepts.  I also corrected the pitch.

srcbuf2 = srcbuf = (unsigned char *)calloc(x, y);
    if ( srcbuf == NULL )
        return 0;
    /* Fill the jpeg buffer. */
    for ( i=0; i < y; i++ )
    {
        memcpy(srcbuf2, image[i], x);
        srcbuf2 += x;
    }

Now the image comes out looking the same as the PNG.  First image is the JPEG, second image is the PNG.
<output00001.jpeg>
<output00001.png>
To view this discussion on the web visit https://groups.google.com/d/msgid/libjpeg-turbo-users/7a60d672-f2cf-438c-bb83-4b45cd08ff58n%40googlegroups.com.
<output00001.jpeg>
<output00001.png>

Kevin McBride

unread,
Jul 5, 2021, 11:32:39 PM7/5/21
to libjpeg-turbo User Discussion/Support
In stick2xyz, there are three modules that the main program goes through to output an image file.  The Input module reads the source data that needs processing.  The Pane2D module organizes the source data into an image.  And finally, the Output2D module takes the data processed inside Pane2D and generates the image file.

In Pane2D, there is code that converts the stored image data from uint8_t * to uint8_t **.  The latter array is what libpng requires.  Maybe I should make another function that can convert the uint8_t * to different formats, such as unsigned char * that JPEG Turbo requires.


In that source file is where the conversion to uint8_t ** occurs.

- Kevin McBride

DRC

unread,
Jul 6, 2021, 11:07:28 AM7/6/21
to libjpeg-t...@googlegroups.com

uint8_t * is the same as unsigned char *, so the TurboJPEG API can read directly from that.  libjpeg-turbo can also read directly from an array of uint8_t pointers, much like libpng can, but you would have to use the libjpeg API rather than the TurboJPEG API in order to do that.  I would suggest that you avoid the uint8_t * --> uint8_t ** conversion unless using libpng.

Reply all
Reply to author
Forward
0 new messages