Welcome! Log In Create A New Profile

Advanced

JPEG issue

Posted by Aruskano 
JPEG issue
February 01, 2010 09:52AM
Hello,

I would love to know if anyone knows why when I try to display this I get this.

Notes:
-The first image works correctly in my computer.
-It's not my code. (WiiXplorer displays it incorrectly, too. The code is pretty simple, I'm sure it's not my fault).
-Image's dimensions are multiple of 4 (it's the exact file that I uploaded)
-Second image is a screenshot, ignore the background and focus on the white square: the problem is that LOLZ should be centered and only displayed once, also there are weird pixels being displayed across the image.
-->The image is the output of saving a powerpoint slide as a jpg (using powerpoint itself). I think the problem is here, I would like to know if anyone knows anything about this.

Hints of any kind are very welcome.

Aruskano,
Re: JPEG issue
February 01, 2010 02:17PM
Instead of 960px × 720px, did you try to use the resolution of your Wii. It might be 640x480 pixels. If you need to put it in the middle of the screen, it's better if it fits the screen.
Re: JPEG issue
February 01, 2010 08:48PM
Well, this is for a slideshow-presentation simulator. I am (and will be) working with kids in a regular basis... since all the technology I have in the classroom is a TV and since I'll be using wii homebrew with educational purposes anyway, I coded this simple "simulator". All it does is display images with a transition effect between them.

I found powerpoint2007 gives you the option to save your presentation as JPGs, it saves all your slides (960x720pixels) as Slide1.jpg, Slide2.jpg and so on. I would prefer to use those images "as is" because that would be very comfortable to me (giving me an identical presentation just copying the output folder to the sd card, which would take me less than a minute).

Also, I can perfectly display a 960x720 image created with gimp but if I edit (draw something on) one of these powerpoint's jpg it stills display incorrectly. I think the header used by powerpoint and libjpeg aren't friends (or something like that) and posted this hoping someone would know something about it.

Thanks for the reply :)
Re: JPEG issue
February 01, 2010 10:10PM
What version of libjpeg are you using?

Last week I added an Installer for libjpeg version 8 in GRRLIB, check this page: [code.google.com]
Re: JPEG issue
February 01, 2010 10:11PM
My first bet would be that you don't get the pixel output format that you are expecting. You might get 24bpp while you expect 32bpp or even 8bit. I've toyed with libjpeg a while back I this was causing problems for me I remember. And it depends on the input what kind of output you get.
Re: JPEG issue
February 01, 2010 10:54PM
@Crayon: I'm using a libjpeg gotten from grrlib's svn about a month ago, do you really think that could be the problem?

@Daid: I don't know anything about the inners of JPG format but when I stated what I wrote about the "header or something like that" I meant something like what you just said.
Quote
Daid
And it depends on the input what kind of output you get.
Do you mean that depending on what's on the slide when I save it as a JPG image I'll get an output or another? or do you mean that depending on which pixel format I input to my wii I'll get an output or another? Do you have any suggestions of how to force/convert a format or/to another?

Something curious: The slide I uploaded was created by a friend (at his own computer) and didn't work properly, I saved some slides as JPGs in my sister's computer and they all work well. Does this relies on the hardware? Graphic settings? Was it my friend's fault? Who knows! (personally, none of the 3 makes sense to me) I will ask people to test the program with their own slides once I code a way to browse to the slides' folder (currently hard coded so it's not that useful), I don't know if anyone needs "powerpoint slideshows" on their TV but I hope some people help me to test it :P.

Thanks you, both.
Re: JPEG issue
February 01, 2010 11:15PM
The version you have is 6b. This are the changes since that revision. I don't think updating will solve your problem, but we never know.
Quote
change.log
Version 8 10-Jan-2010
----------------------

jpegtran now supports the same -scale option as djpeg for "lossless" resize.
An implementation of the JPEG SmartScale extension is required for this
feature. A (draft) specification of the JPEG SmartScale extension is
available as a contributed document at ITU and ISO. Revision 2 or later
of the document is required (latest document version is Revision 3).
The SmartScale extension will enable more features beside lossless resize
in future implementations, as described in the document (new compression
options).

Add sanity check in BMP reader module to avoid cjpeg crash for empty input
image (thank to Isaev Ildar of ISP RAS, Moscow, RU for reporting this error).

Add data source and destination managers for read from and write to
memory buffers. New API functions jpeg_mem_src and jpeg_mem_dest.
Thank to Roberto Boni from Italy for the suggestion.


Version 7 27-Jun-2009
----------------------

New scaled DCTs implemented.
djpeg now supports scalings N/8 with all N from 1 to 16.
cjpeg now supports scalings 8/N with all N from 1 to 16.
Scaled DCTs with size larger than 8 are now also used for resolving the
common 2x2 chroma subsampling case without additional spatial resampling.
Separate spatial resampling for those kind of files is now only necessary
for N>8 scaling cases.
Furthermore, separate scaled DCT functions are provided for direct resolving
of the common asymmetric subsampling cases (2x1 and 1x2) without additional
spatial resampling.

cjpeg -quality option has been extended for support of separate quality
settings for luminance and chrominance (or in general, for every provided
quantization table slot).
New API function jpeg_default_qtables() and q_scale_factor array in library.

Added -nosmooth option to cjpeg, complementary to djpeg.
New variable "do_fancy_downsampling" in library, complement to fancy
upsampling. Fancy upsampling now uses direct DCT scaling with sizes
larger than 8. The old method is not reversible and has been removed.

Support arithmetic entropy encoding and decoding.
Added files jaricom.c, jcarith.c, jdarith.c.

Straighten the file structure:
Removed files jidctred.c, jcphuff.c, jchuff.h, jdphuff.c, jdhuff.h.

jpegtran has a new "lossless" cropping feature.

Implement -perfect option in jpegtran, new API function
jtransform_perfect_transform() in transupp. (DP 204_perfect.dpatch)

Better error messages for jpegtran fopen failure.
(DP 203_jpegtran_errmsg.dpatch)

Fix byte order issue with 16bit PPM/PGM files in rdppm.c/wrppm.c:
according to Netpbm, the de facto standard implementation of the PNM formats,
the most significant byte is first. (DP 203_rdppm.dpatch)

Add -raw option to rdjpgcom not to mangle the output.
(DP 205_rdjpgcom_raw.dpatch)

Make rdjpgcom locale aware. (DP 201_rdjpgcom_locale.dpatch)

Add extern "C" to jpeglib.h.
This avoids the need to put extern "C" { ... } around #include "jpeglib.h"
in your C++ application. Defining the symbol DONT_USE_EXTERN_C in the
configuration prevents this. (DP 202_jpeglib.h_c++.dpatch)
Re: JPEG issue
February 04, 2010 11:35AM
Crayon, could you please give me a downlaod link to the new version of libjpeg? :)
Re: JPEG issue
February 04, 2010 04:32PM
Quote
diego_pmc
Crayon, could you please give me a downlaod link to the new version of libjpeg? :)
I gave the link to the GRRLIB repository previously: [code.google.com]

If you want to download it from the official Web site but some manipulation are required to compiled it.
Re: JPEG issue
February 06, 2010 12:49AM
Some jpeg library dunno which one have problems with meta data in the jpeg files. Re-saving jpeg files through irfanview or similar program and getting rid of that meta data helps.



Edited 1 time(s). Last edit at 02/06/2010 12:50AM by I.R.on.
Re: JPEG issue
February 06, 2010 07:32AM
Hi there,

Sorry for my late answer. I updated my libjpeg to v8 and, as you predicted, it didn't help [but it feels great to feel up2date! :D! haha].

I was just going to post that I wasn't that interested in finding the solution to this matter when I did my last try and found what was the problem. I read the headers of 2 images with jhead (a tool I found after a looooooong 2 second search) and found that the images that weren't working properly were "black and white". Instead of having 3 color components (red, green, blue) those images have just 1 (grayscale[?]). Apparently those images can not be handled by libjpeg. Since my friend just wrote random words (such as "LOLZ" in the image I uploaded) in black (default color) his powerpoint kindly decided to save some kilobytes to our hard drives and wrote grayscale values instead of RGB values, how cute! I asked him to use any color and his slides worked fine.

Now I'm just wondering why my powerpoint isn't as kind as his,
Thanks a lot for your replies/time.
Re: JPEG issue
February 06, 2010 08:19AM
You can transform from grayscale to full color during decompression if you set the jpeg_color_space value. e.g.:

struct jpeg_decompress_struct info;
// JPEG init stuff removed
if ( info.jpeg_color_space == JCS_GRAYSCALE ) {
         info.out_color_space = JCS_RGB;
}
// continue with decompression
Re: JPEG issue
February 06, 2010 09:29AM
Hello,

I couldn't get that to work. I'm using GRRLIB and the colorspace of the working images is YCbCr. Is there any other thing, besides cinfo.out_color_space = JCS_YCbCr; needed?

Edit: I'm writing that line in GRRLIB_LoadTextureJPGEx(), just clearing that out... :P

Thanks,



Edited 1 time(s). Last edit at 02/06/2010 09:48AM by Aruskano.
Re: JPEG issue
February 07, 2010 12:32AM
I checkout out GRRLIB and I noticed the jpeg loading code was attributed to me! How nice! Anyway, try replacing the GRRLIB_LoadTextureJPGEx with this modified (and untested!) version:
GRRLIB_texImg*  GRRLIB_LoadTextureJPGEx (const u8 *my_jpg, const int my_size) {
    struct jpeg_decompress_struct cinfo;
    struct jpeg_error_mgr jerr;
    GRRLIB_texImg *my_texture = calloc(1, sizeof(GRRLIB_texImg));
    unsigned int i;

    if(my_texture == NULL)
        return NULL;

    jpeg_create_decompress(&cinfo);
    cinfo.err = jpeg_std_error(&jerr);
    cinfo.progress = NULL;
    jpeg_mem_src(&cinfo, (unsigned char *)my_jpg, my_size);
    jpeg_read_header(&cinfo, TRUE);
    if (cinfo.jpeg_color_space == JCS_GRAYSCALE) {
        cinfo.out_color_space = JCS_RGB;
    }
    jpeg_start_decompress(&cinfo);
    unsigned char *tempBuffer = malloc(cinfo.output_width * cinfo.output_height * cinfo.output_components);
    JSAMPROW row_pointer[1];
    row_pointer[0] = malloc(cinfo.output_width * cinfo.output_components);
    size_t location = 0;
    while (cinfo.output_scanline < cinfo.output_height) {
        jpeg_read_scanlines(&cinfo, row_pointer, 1);
        for (i = 0; i < cinfo.image_width * cinfo.output_components; i++) {
            /* Put the decoded scanline into the tempBuffer */
            tempBuffer[ location++ ] = row_pointer[0];
        }
    }
    /* Create a buffer to hold the final texture */
    my_texture->data = memalign(32, cinfo.output_width * cinfo.output_height * 4);
    RawTo4x4RGBA(tempBuffer, my_texture->data, cinfo.output_width, cinfo.output_height);
    /* Done - Do cleanup and release allocated memory */
    jpeg_finish_decompress(&cinfo);
    jpeg_destroy_decompress(&cinfo);
    free(row_pointer[0]);
    free(tempBuffer);

    my_texture->w = cinfo.output_width;
    my_texture->h = cinfo.output_height;
    GRRLIB_SetHandle( my_texture, 0, 0 );
    GRRLIB_FlushTex( my_texture );
    return my_texture;
}
Re: JPEG issue
February 07, 2010 02:11AM
That worked fine. I assume that since changing the output color_space wasn't featured there wasn't any difference between calculating the necessary memory to allocate with the input or the output so the code was calculating it with the input which brought problems when the output was different (correct me if I'm wrong, I want to learn :P). Those cinfo.output_components did de trick. Thank you. Something else you should be credited for? :)

@Crayon: Add this to the SVN? Since grayscale aren't being displayed correctly I don't think anyone would get mad if GRRLIB forces RGB.

Thanks again.
Re: JPEG issue
February 08, 2010 05:28PM
Quote
Aruskano
@Crayon: Add this to the SVN? Since grayscale aren't being displayed correctly I don't think anyone would get mad if GRRLIB forces RGB.
I did the changes in GRRLIB in revision 313.

@DrTwox: Thanks for the fix :)
Sorry, only registered users may post in this forum.

Click here to login