JPEG issue

[ed.vi...@gmail.com]

Hello

I have a JPEG image which I display in an Fl_Box. On most platforms, it displays correctly. There is no issue displaying the image using any other software. However, on my Intel MacBook Pro (OS 12.6), I get the following error: 

JPEG file "meshlogo.jpg" is too large or contains errors!

Any ideas?

Cheers

Ed

[Matthias Melcher]

I have an M1 MacBook pro with 12.6. If you like, send me the jpeg and the code that is supposed to read it and fails. My email address is fltk@m*a*t*t*h*I*a*s*m.com without the asterisks.

 - Matthias

[Ian MacArthur]

Aside from Matt's offer, if the image is not too big, and not private, you could post it here for all to have a shot!

My initial thought is:- Which JPEG lib is your build using? Is it using the fltk built-in JPEG, or is it using the macOS system JPEG lib?

I have a vague idea that Apple changed some of their system libs, so if that is the case then building your fltk lib to use the built-in JPEG lib might change things around somewhat.

Worth a try and cheap to do anyway!

[ed.vi...@gmail.com]

Hi

Here is the image. I set the button with fluid:

      Fl_Box {} {
        image {meshlogo.jpg} xywh {10 9 555 156} align 16
      }

which gets translated to this in the .cc file:

static const unsigned char idata_meshlogo[] =
{255,216,255,224,0,16,74,70,73,70,0,1,1,2,0,118,0,118,0,0,255,219,0,67,0,3,
2,2,2,2,2,3,2,2,2,3,3,3,3,4,6,4,4,4,4,4,8,6,6,5,6,9,8,10,10,9,8,9,9,10,12,15,
12,10,11,14,11,9,9,13,17,13,14,15,16,16,17,16,10,12,18,19,18,16,19,15,16,16,16,
255,219,0,67,1,3,3,3,4,3,4,8,4,4,8,16,11,9,11,16,16,16,16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,16,16,16,16,16,255,192,0,17,8,0,137,2,42,3,1,17,0,2,17,
1,3,17,1,255,196,0,30,0,1,0,2,2,2,3,1,0,0,0,0,0,0,0,0,0,0,9,8,7,6,5,2,1,4,10,
3,255,196,0,95,16,0,1,3,4,1,3,1,5,3,5,7,12,14,6,11,0,1,2,3,4,5,0,17,6,7,8,18,
33,49,9,19,65,81,34,97,20,50,113,129,21,145,35,161,25,22,66,211,177,82,87,114,
51,148,56,117,23,55,36,118,179,209,54,115,130,147,149,178,195,210,52,98,53,146,
180,193,70,86,88,99,162,67,71,84,85,116,131,134,150,163,194,225,240,255,196,0,
28,1,1,0,1,5,1,1,0,0,0,0,0,0,0,0,0,0,0,5,2,3,4,6,7,1,8,255,196,0,...};

static Fl_Image *image_meshlogo() {
  static Fl_Image *image = new Fl_JPEG_Image("meshlogo.jpg", idata_meshlogo);
  return image;
}

Cheers

Ed

[ed.vi...@gmail.com]

I just checked and I am using the homebrew JPEG library:

    /usr/local/opt/jpeg-turbo/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.2.2)

Cheers

Ed

[Matthias Melcher]

I check the jpeg using the FLTK building jpeg library (current FLTK 1.4 on M1 macOS) and it works as expected. So this seems to be an issue with homebrew.

ed.vi...@gmail.com schrieb am Samstag, 12. November 2022 um 08:50:57 UTC+1:

static const unsigned char idata_meshlogo[] =
{255,216,255,224,0,16,74,70,73,70,0,1,1,2,0,118,0,118,0,0,255,219,0,67,0,3,

... 

28,1,1,0,1,5,1,1,0,0,0,0,0,0,0,0,0,0,0,5,2,3,4,6,7,1,8,255,196,0,...};

                                                                  ^^^^^

I assume that you shortened the output because the list is very long and Fluid doesn't create '...' unless there is a bug.

[lifeatt...@gmail.com]

Neither badpeggy nor Imagemagick identify show any issues with the image.

The only thing of interest vs a "typical" jpeg is (according to identify) meshlogo.jpg specifies the Resolution, Print size, and Units.

Those would be artifacts from the creation process, and I'm not sure how to change or clear those.

 

Here is the image.

 

Kevin

[Ian MacArthur]

Yeah, I’m not seeing any issues with the image either. It works fine for me in testing. The “metadata” should not generally affect subsequent processing of the image either, at least not to the extent of refusing to load, so I don’t think that would be a problem.

Certainly, on my old Mac it opens and displays just fine with the fltk built-in JPEG lib, and with various other image tools I tried.
I do not have the Homebrew version of the JPEG lib that the OP has though, so can not test with that, but my "best guesses" (and they are only a guesses) is that either the Homebrew JPEG is messed up in some way, or that somehow Ed’s code is corrupting the JPEG data during loading (although quite how you would do that I’m not sure - I’m envisaging some sort of corruption wherein a rogue pointer somehow trashes the data that fluid created, at some point between starting the app and reading the image data, which seems unlikely frankly...)

Anyway, as best I can tell the JPEG image is OK, and loads just fine with the fltk built-in JPEG on my Mac.
FWIW, the data generated by fluid in my test is *a lot* larger than that posted by Ed (unless that was trimmed for posting?)
My version is the same as posted, up until the ellipsis, but then carries on for a further 1021 lines before I get to the Fl_Image definition.

Ed, did you get a chance to test with the fltk built-in JPEG lib at all?



And, as a total aside, I note that the image has very few colours in it and not much in the way of gradients or etc., so it occurs to me that a PNG with a limited palette would probably make a better job, lossless and possibly smaller, of holding this image data than a JPEG does.
I’m always wary of storing line art in JPEG images because of the way the DCT compression messes with hard edges and introduces artefacts and so on. A few times I’ve been really messed up by JPEG in this area, so PNG for the win I say!

[Albrecht Schlosser]

On 11/12/22 10:31 ed.vi...@gmail.com wrote:

I just checked and I am using the homebrew JPEG library:

    /usr/local/opt/jpeg-turbo/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.2.2)

Hi Ed,

as written by others, we can't find an issue with your image file. I tested it with test/pixmap_browser on Linux (Intel) and macOS (M1: ARM) and it works fine.

I also tested the image with fluid so it is loaded from memory as in your case. This fluid file should create an executable that displays the image with a 10-pixel wide red border.

Please copy this tiny fluid file to your FLTK root directory:

# data file for the Fltk User Interface Designer (fluid)
version 1.0400
header_name {.h}
code_name {.cxx}
Function {make_window()} {open
} {
  Fl_Window {} {open
    xywh {45 422 574 157} type Double visible
  } {
    Fl_Box {} {
      image {meshlogo.jpg} xywh {0 0 574 157} box FLAT_BOX color 1
    }
  }
}

Function {} {open
} {
  code {Fl_Window *w = make_window();
w->show();} {selected
  }
}

Then test it using:

$ ./fluid/fluid meshlogo.fl
$ ./fltk-config --use-images --compile meshlogo.cxx
$ ./meshlogo

If this does not work with your old FLTK build and your JPEG library, then please use a fresh FLTK checkout and configure FLTK to use the bundled jpeg libraries, for instance:

$ make distclean
$ autoconf
$ ./configure  --enable-localjpeg --enable-localpng --enable-localzlib
$ make

Then execute test/pixmap_browser and try to load your image from disk. If this works we can conclude that the issue is not within FLTK.

You should also try the meshlogo.fl with this new build and report what you find out.