You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
(1) |
Jun
(17) |
Jul
(5) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
(3) |
Mar
|
Apr
(4) |
May
(3) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(3) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Zvi V. <ver...@gm...> - 2024-03-29 22:41:51
|
Hello, I have a 20 years old system currently using version 80b. I'm required to use 9f and using the code samples I ran the attached code: The pointer: jHeader is a 329 bytes used by the old system to decompress into a 192x192 gray scale image. But with the latest library I got: --------------------------------------------------------------------------------------------- Corrupt JPEG data: 1143 extraneous bytes before marker 0xcb Unsupported JPEG process: SOF type 0xcb ---------------------------------------------------------------------------------------------- Upon calling to* jpeg_finish_decompress*. Can you please tell what is wrong in my code ? If required, I can send also the compressed image and the jpeg header. Thank you, Zvika |
From: Bob F. <bfr...@si...> - 2020-06-06 18:17:50
|
On Wed, 3 Jun 2020, Gabriel Ryan wrote: > Thanks for the response! > > This was the email list linked from the IJG website so I thought it might > be still be in use. I will try using the contact form on the IJP instead. This might be the only IJG JPEG mailing list available so there is no harm from using it. The only concern was that Guido Vollbeding is not likely subscribed to this list and IJG JPEG is essentially developed by one person. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Gabriel R. <ga...@cs...> - 2020-06-03 12:18:48
|
Thanks for the response! This was the email list linked from the IJG website so I thought it might be still be in use. I will try using the contact form on the IJP instead. Best, Gabe On Tue, Jun 2, 2020 at 3:20 PM Bob Friesenhahn <bfr...@si...> wrote: > On Tue, 2 Jun 2020, Gabriel Ryan wrote: > > > Hi, > > > > I'm reaching to report 4 integer overflow errors in libjpeg-9c. POC > inputs > > along with directions to reproduce the errors are included in the > attached > > zip. > > I doubt that Guido Vollbeding (IJG JPEG maintainer) is watching this > list. Note that this list is for libtiff 6x, which is essentially > anchient history now. > > Bob > -- > Bob Friesenhahn > bfr...@si..., http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > |
From: Bob F. <bfr...@si...> - 2020-06-02 19:20:11
|
On Tue, 2 Jun 2020, Gabriel Ryan wrote: > Hi, > > I'm reaching to report 4 integer overflow errors in libjpeg-9c. POC inputs > along with directions to reproduce the errors are included in the attached > zip. I doubt that Guido Vollbeding (IJG JPEG maintainer) is watching this list. Note that this list is for libtiff 6x, which is essentially anchient history now. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Gabriel R. <ga...@cs...> - 2020-06-02 18:31:56
|
Hi, I'm reaching to report 4 integer overflow errors in libjpeg-9c. POC inputs along with directions to reproduce the errors are included in the attached zip. Directions for replicating and errors below. Best, Gabe ========================================= We built the jpeg-9c library with -O0 -g -fsanitize=address,undefined -fno-omit-frame-pointer Our environmeent is x86_64 Linux with Kernel version 4.15.0-66-generic. We use clang 7.0.0 to build. ----------------------- Folder 1. Command Line: djpeg id:003426,src:003255,op:flip1,pos:276,+cov.input.0 Error: Corrupt JPEG data: 18 extraneous bytes before marker 0xda ../../src/jdarith.c:389:45: runtime error: left shift of negative value -1 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../src/jdarith.c:389:45 in ----------------------- Folder 2. Command Line: djpeg id:001480,src:000791,op:flip4,pos:295,+cov.input.0 Error: Premature end of JPEG file ../../src/jdarith.c:308:53: runtime error: left shift of negative value -1 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../src/jdarith.c:308:53 in ----------------------- Folder 3. Command Line: djpeg djpeg_bug id:003755,src:003543,op:flip1,pos:251,+cov.input.0 Error: Corrupt JPEG data: 10 extraneous bytes before marker 0xda ../../src/jdhuff.c:940:15: runtime error: left shift of negative value -1 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../src/jdhuff.c:940:15 in ----------------------- POC 4. Download from https://drive.google.com/file/d/1Xez2AWX-QI5Xj5VUp4EjerfHz1hTQPtD/view?usp=sharing Command Line: djpeg output Error: P5 57188 32772 255 ../../src/jdhuff.c:530:32: runtime error: left shift of 69288182312683848 by 8 places cannot be represented in type 'bit_buf_type' (aka 'long') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../src/jdhuff.c:530:32 in |
From: Travis S. <he...@ya...> - 2019-10-11 23:44:13
|
Hello, I was very interest in using this api for my programming purposes but ran into an unusual problem along the way. From compression. after decompressing image and re-compressing, the returned image had a strange neon greenish color. After performing some test to see if this could be remedied by supplying the rgb values in buffer with a fixed number to zero out the deviated value. It seemed to have changed. it seems there is no consistency on this. In example, if i set all rgb values to say 0 0 and 0 the returned value of the image is 0 -121 0 after supplying it with 0 121 and 0 i got -124 94 0 for all values and this got even worse after placing random numbers in. I am very complexed by this issue and would like some guidance on how to fix this.Sincerely, Travis |
From: Adam F. <ada...@uk...> - 2018-05-21 08:54:58
|
Hi Bob, Thanks for the quick reply. :) The fix is trivial, and worth including in 6x if a commit is a simple ask. In the meantime, I'll follow up with the IJG "jpegclub.org" group to get the fix into 9x. Best Regards Adam > On Fri, 18 May 2018, Adam Farley8 wrote: > > > > P.S. It would be great to get this source into the latest IJG source as > > well (e.g. 9c), but their contact page (url below) doesn't appear to work. > > A spinny thingy appears when you click send, but nothing else happens. > > > > http://jpegclub.org/reference/contact/ > > > > Here's hoping the IJG, or someone with a line to them, is monitoring this > > list so we can get the fix across. > > This project/list really is about IJG JPEG 6x, which dates from 1998. > This project was spun-up because IJG JPEG was temporarily (for a long > time) without a maintainer and there was a need for a way to support > the old release. This project is totally independent of the IJG > project. > > Bob > -- > Bob Friesenhahn > bfr...@si..., http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
From: Bob F. <bfr...@si...> - 2018-05-18 17:10:36
|
On Fri, 18 May 2018, Adam Farley8 wrote: > > P.S. It would be great to get this source into the latest IJG source as > well (e.g. 9c), but their contact page (url below) doesn't appear to work. > A spinny thingy appears when you click send, but nothing else happens. > > http://jpegclub.org/reference/contact/ > > Here's hoping the IJG, or someone with a line to them, is monitoring this > list so we can get the fix across. This project/list really is about IJG JPEG 6x, which dates from 1998. This project was spun-up because IJG JPEG was temporarily (for a long time) without a maintainer and there was a need for a way to support the old release. This project is totally independent of the IJG project. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Adam F. <ada...@uk...> - 2018-05-18 16:10:12
|
Hi There, I'm trying to fix a bug whereby compiling jchuff.c (link below, to avoid ambiguity) causes the OpenJDK build to fail due to the array-bounds warning generated when these criteria are met: - The platform is pLinux or zLinux - The gcc version is 4.8.5 (default release on many linux-based OS'). - The optimization level is -O3 OpenJDK's copy of jchuff: http://hg.openjdk.java.net/jdk/jdk/file/d9bc8557ae16/src/java.desktop/share/native/libjavajpeg/jchuff.c After some poking around, I discovered that making a simple change to jchuff.c can prevent the warning. http://cr.openjdk.java.net/%7Estuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/src/java.desktop/share/native/libjavajpeg/jchuff.c.udiff.html The OpenJDK community is willing to accept the change, but is concerned that the next merge from your upstream source will splat the change. Could I impose on you to add this change to your source, thus preventing said splat? Best Regards Adam P.S. It would be great to get this source into the latest IJG source as well (e.g. 9c), but their contact page (url below) doesn't appear to work. A spinny thingy appears when you click send, but nothing else happens. http://jpegclub.org/reference/contact/ Here's hoping the IJG, or someone with a line to them, is monitoring this list so we can get the fix across. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU |
From: Bob F. <bfr...@si...> - 2018-01-03 16:29:32
|
Distributions like Debian likely have security patches for 6b but the Independent JPEG Group (Guido Vollbeding) is definitely not supporting it. While it was used for a great many years, 6b is an antique version and should no longer be used. Volunteers have produced updated versions of formal IJG releases and they are available as lettered versions at http://www.ijg.org/files/. Many people/distributions are using TurboJPEG, which is not supported by IJG. There are other variants of libjpeg which are also not supported by IJG. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Wayne D. <way...@cu...> - 2018-01-03 15:27:21
|
-- *WAYNE DAVIES* | Developer *CURVE DENTAL *A Fresh, Web-based Alternative to Dental Software www.curvedental.com |
From: Reka S. <rek...@gm...> - 2016-11-02 11:56:38
|
Hi All, I am very new for libjpeg and mailing list also. I am trying to decompress jpg image using following code. Input parameters are image name, width and height. return type is custom structure called IMG_MATRIX. typedef struct img_matrix{ int x; int y; int intensity_r; int intensity_g; int intensity_b; } IMG_MATRIX; I need to get pixel values (R,G,B) and create new jpeg image. Issue is i got blurred image when I try generate new new jpeg image. (see attachments) I think issue is having my decompress code. because I can generate correct image if I read image using OpenCv. If anyone can help to solve this issue It would be grate. Best Regards, *my code of read jpeg as follows. * IMG_MATRIX *katussa_read_jpeg(char *watermarked_image_name, int width, int height) { // Using this uninitialized pointer later to store raw, uncompressd image unsigned char *raw_image = NULL; char *filename = watermarked_image_name; // Dimensions of the image we want to write //int width = 512; //int height = 512; int bytes_per_pixel = 3; /* or 1 for GRACYSCALE images */ int color_space = JCS_RGB; /* or JCS_GRAYSCALE for grayscale images */ int index = width*height*41; IMG_MATRIX *img_matrix = NULL; img_matrix = (IMG_MATRIX*) malloc(index); // variables for cordinates of img_matrix int x, y; int total_pixel = width*height; // These are standard libjpeg structures for reading(decompression) struct jpeg_decompress_struct cinfo; struct jpeg_error_mgr jerr; // libjpeg data structure for storing one row, that is, scanline of an image JSAMPROW row_pointer[1]; FILE *infile = fopen( filename, "rb" ); unsigned long *location; int i = 0; if ( !infile ) { printf("Error opening jpeg file %s\n!", filename ); exit; } // Here we set up the standard libjpeg error handler cinfo.err = jpeg_std_error( &jerr ); // Setup decompression process and source, then read JPEG header jpeg_create_decompress( &cinfo ); // This makes the library read from infile jpeg_stdio_src( &cinfo, infile ); // Reading the image header which contains image information jpeg_read_header( &cinfo, TRUE ); // Start decompression jpeg here jpeg_start_decompress( &cinfo ); // Allocate memory to hold the uncompressed image raw_image = (unsigned char*)malloc( cinfo.output_width*cinfo.output_height*cinfo.num_components ); // Now actually read the jpeg into the raw buffer row_pointer[0] = (unsigned char *)malloc( cinfo.output_width*cinfo.num_components ); location = (unsigned long*)malloc( cinfo.output_width*cinfo.output_height*cinfo.num_components ); // Read one scan line at a time long long int pixel_index = -1; y = 0; unsigned long count = 0; while( cinfo.output_scanline < cinfo.image_height ) { jpeg_read_scanlines( &cinfo, row_pointer, 1 ); x = 0; for( i=0; i<cinfo.image_width*cinfo.num_components; i++){ location[count] = row_pointer[0][i]; if((count%3)==0) { pixel_index++; img_matrix[pixel_index].x = x; img_matrix[pixel_index].y = y; img_matrix[pixel_index].intensity_r = row_pointer[0][i]; x++; } if((count%3)==1) { img_matrix[pixel_index].intensity_g = row_pointer[0][i]; } if((count%3)==2) { img_matrix[pixel_index].intensity_b = row_pointer[0][i]; } count++; } y++; //break; } // Wrap up decompression, destroy objects, free pointers and close open files jpeg_finish_decompress( &cinfo ); jpeg_destroy_decompress( &cinfo ); free( row_pointer[0] ); fclose( infile ); return img_matrix; } -- Reka Sandaruwan Senior Engineer WSO2 |
From: Tom L. <tg...@ss...> - 2016-09-20 03:30:20
|
Dinesh Iyer <dsi...@gm...> writes: >> I am using libjpeg 6b in my application and I am getting an error when I >> am attempting to read a JPEG file that has the byte sequence FF 21 as part >> of the COM marker. I get the error: >> "Unsupported marker type 0x21" 0x21 isn't a valid JPEG marker code. >> only when I use my own data source manager instead of jpg_stdio_src. That strongly suggests that your data source manager code is losing sync with the input, ie, eating more or fewer bytes than it should. Impossible to diagnose more specifically with this amount of info; but if you think that FF 21 is part of some COM marker and not part of the main data stream, then I'd say you broke consumption of the COM marker. regards, tom lane |
From: Bob F. <bfr...@si...> - 2016-09-19 22:01:16
|
On Mon, 19 Sep 2016, Dinesh Iyer wrote: > Apologies for the improper subject line earlier. No problem. This notification from libjpeg is likely a warning rather than an error so usually the suitable response would be to simply ignore it, or log the warning somewhere, and then ignore it. Bob > > Dinesh > > On Mon, Sep 19, 2016 at 4:30 PM, Dinesh Iyer <dsi...@gm...> wrote: > >> Hi everyone, >> I am using libjpeg 6b in my application and I am getting an error when I >> am attempting to read a JPEG file that has the byte sequence FF 21 as part >> of the COM marker. I get the error: >> >> "Unsupported marker type 0x21" >> >> only when I use my own data source manager instead of jpg_stdio_src. The >> reason I need to use my own data source manager is that this JPEG image >> is part of a Motion JPEG AVI file. >> >> I have extracted the JPEG image from the AVI file using VirtualDub and it >> can be found here: >> >> https://drive.google.com/file/d/0BxHH6-OjP-PqTHdYQnpVT0Y0WTA/view?usp= >> sharing >> >> Would appreciate your help on this. >> >> Regards, >> Dinesh >> > -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Dinesh I. <dsi...@gm...> - 2016-09-19 21:32:13
|
Apologies for the improper subject line earlier. Dinesh On Mon, Sep 19, 2016 at 4:30 PM, Dinesh Iyer <dsi...@gm...> wrote: > Hi everyone, > I am using libjpeg 6b in my application and I am getting an error when I > am attempting to read a JPEG file that has the byte sequence FF 21 as part > of the COM marker. I get the error: > > "Unsupported marker type 0x21" > > only when I use my own data source manager instead of jpg_stdio_src. The > reason I need to use my own data source manager is that this JPEG image > is part of a Motion JPEG AVI file. > > I have extracted the JPEG image from the AVI file using VirtualDub and it > can be found here: > > https://drive.google.com/file/d/0BxHH6-OjP-PqTHdYQnpVT0Y0WTA/view?usp= > sharing > > Would appreciate your help on this. > > Regards, > Dinesh > |
From: Dinesh I. <dsi...@gm...> - 2016-09-19 20:31:03
|
Hi everyone, I am using libjpeg 6b in my application and I am getting an error when I am attempting to read a JPEG file that has the byte sequence FF 21 as part of the COM marker. I get the error: "Unsupported marker type 0x21" only when I use my own data source manager instead of jpg_stdio_src. The reason I need to use my own data source manager is that this JPEG image is part of a Motion JPEG AVI file. I have extracted the JPEG image from the AVI file using VirtualDub and it can be found here: https://drive.google.com/file/d/0BxHH6-OjP-PqTHdYQnpVT0Y0WTA/view?usp=sharing Would appreciate your help on this. Regards, Dinesh |
From: Mathieu C. <mch...@gm...> - 2016-08-23 18:22:30
|
Hi Tom, Thanks for your reply. I don't know much about JPEG marker bytes or hex in general, but surprisingly, the marker type in the error has so far never been the same. I just checked on a dozen files and these are the types that came up: 0x49 / 0x1d / 0x18 / 0x3a / 0xbb / 0x53 / 0x69 / 0x61 / 0x63 / 0x40 / 0x43 / 0x7d / 0x6d In the three files that I posted, the types were 0x20, 0x10 and 0x06 I also tried opening the files with a hex editor, but couldn't get much out of it. Are there any other linux or windows programs I could use to test these files? Any other ideas would also be very welcome. Thanks, Mathieu On Tue, Aug 23, 2016 at 6:30 PM, Tom Lane <tg...@ss...> wrote: > Mathieu Chellat <mch...@gm...> writes: > > The error message I get is "Error interpreting JPEG image file > (Unsupported > > marker type 0x20)". > > Which sounds more like it does not recognize the file as a jpg file. > > No, that sounds more like a corrupted file. 0x20 is not a legal JPEG > marker byte. > > (The fact that you can read it with some other library does not alter the > conclusion that it's not a valid JPEG file. Some code is pretty forgiving > about ignoring garbage; libjpeg is less so.) > > regards, tom lane > |
From: Tom L. <tg...@ss...> - 2016-08-23 17:21:06
|
Mathieu Chellat <mch...@gm...> writes: > The error message I get is "Error interpreting JPEG image file (Unsupported > marker type 0x20)". > Which sounds more like it does not recognize the file as a jpg file. No, that sounds more like a corrupted file. 0x20 is not a legal JPEG marker byte. (The fact that you can read it with some other library does not alter the conclusion that it's not a valid JPEG file. Some code is pretty forgiving about ignoring garbage; libjpeg is less so.) regards, tom lane |
From: Mathieu C. <mch...@gm...> - 2016-08-23 07:34:10
|
Hi Scott, Thanks for your quick reply. I just took two very simple pictures, one with the front camera <https://dl.dropboxusercontent.com/u/488552/front.jpg> and one with the back camera <https://dl.dropboxusercontent.com/u/488552/back.jpg>. As you can see, they are much smaller (5 and 1 MB, respectively), but still fail to load in Frogr. So it doesn't look like it is a size problem The error message I get is "Error interpreting JPEG image file (Unsupported marker type 0x20)". Which sounds more like it does not recognize the file as a jpg file. Any other ideas? Thanks, Mat On Mon, Aug 22, 2016 at 9:47 PM, Scott Weber <sco...@sb...> wrote: > Mathieu. > I am not a JPEG developer, but I did take one of my windows applications, > and opened that large (9 meg) image without any problem. I am using a > build from jpeg9-a. > > I also loaded a simple GTK test program, and it displayed the image, > although much larger than my monitor could handle. > > I would suspect that the way GTK developers coded it to handle a large > image is the problem. The image is 48meg in RAM when uncompressed. > > > > > ------------------------------ > *From:* Mathieu Chellat <mch...@gm...> > *To:* lib...@li... > *Sent:* Monday, August 22, 2016 2:07 PM > *Subject:* [Libjpeg-devel-6x] Unrecognized jpg file > > Hi, > > I recently got a new phone (Moto X Play) and am unable to upload pictures > taken with it to Flickr using Frogr. > I have filed a bug report > <https://bugzilla.gnome.org/show_bug.cgi?id=768639> with the Frogr > developer, who told me it's a bug with the libjpeg library which is why I > am contacting you. > All the details along with a sample jpg file are in the bug report. > > Any help would be appreciated. > Thanks a lot, > > Mathieu > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Libjpeg-devel-6x mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libjpeg-devel-6x > > > |
From: Scott W. <sco...@sb...> - 2016-08-22 19:47:10
|
Mathieu.I am not a JPEG developer, but I did take one of my windows applications, and opened that large (9 meg) image without any problem. I am using a build from jpeg9-a. I also loaded a simple GTK test program, and it displayed the image, although much larger than my monitor could handle. I would suspect that the way GTK developers coded it to handle a large image is the problem. The image is 48meg in RAM when uncompressed. From: Mathieu Chellat <mch...@gm...> To: lib...@li... Sent: Monday, August 22, 2016 2:07 PM Subject: [Libjpeg-devel-6x] Unrecognized jpg file Hi, I recently got a new phone (Moto X Play) and am unable to upload pictures taken with it to Flickr using Frogr. I have filed a bug report with the Frogr developer, who told me it's a bug with the libjpeg library which is why I am contacting you. All the details along with a sample jpg file are in the bug report. Any help would be appreciated. Thanks a lot, Mathieu ------------------------------------------------------------------------------ _______________________________________________ Libjpeg-devel-6x mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libjpeg-devel-6x |
From: Mathieu C. <mch...@gm...> - 2016-08-22 19:08:25
|
Hi, I recently got a new phone (Moto X Play) and am unable to upload pictures taken with it to Flickr using Frogr. I have filed a bug report <https://bugzilla.gnome.org/show_bug.cgi?id=768639> with the Frogr developer, who told me it's a bug with the libjpeg library which is why I am contacting you. All the details along with a sample jpg file are in the bug report. Any help would be appreciated. Thanks a lot, Mathieu |
From: Tom L. <tg...@ss...> - 2016-06-29 19:25:34
|
Dinesh Iyer <dsi...@gm...> writes: > I am user of libjpeg 6b and I am observing a crash when reading a corrupt > JPEG image. This crash occurs only when I try to use my own data source > manager instead of using jpg_stdio_src. Presumably, this means your data source manager is doing something wrong. The location of the crash suggests it's probably associated with a resync_to_restart callback, which would be a likely place for bugs to lurk unnoticed since that function is never invoked except when seeing corrupted input data. You might find it useful to read the comments for jpeg_resync_to_restart(), which is the library's own version of resync_to_restart. regards, tom lane |
From: Dinesh I. <dsi...@gm...> - 2016-06-29 18:34:39
|
Hi everyone, I am user of libjpeg 6b and I am observing a crash when reading a corrupt JPEG image. This crash occurs only when I try to use my own data source manager instead of using jpg_stdio_src. The reason I need to use my own data source manager is that this JPEG image is part of a Motion JPEG AVI file. I have extracted the JPEG image from the AVI file using VirtualDub and it can be found here: https://drive.google.com/file/d/0BxHH6-OjP-Pqb3FBbmF6dDNnaGc/view?usp=sharing The crash trace is below: [ 0] 0x0000000000000000 [unknown function] at [unknown module] (no module specified) [ 1] 0x00000000acacd8a9 read_restart_marker at c:\temp\b3p0_338329_5444\batserve\win64\jpeg\jdmarker.c:1141 [ 2] 0x00000000acad99f3 process_restart at c:\temp\b3p0_338329_5444\batserve\win64\jpeg\jdshuff.c:186 [ 3] 0x00000000acad94bb decode_mcu at c:\temp\b3p0_338329_5444\batserve\win64\jpeg\jdshuff.c:235 [ 4] 0x00000000acad85fe decompress_onepass at c:\temp\b3p0_338329_5444\batserve\win64\jpeg\jdcoefct.c:169 [ 5] 0x00000000acacfd0a process_data_simple_main at c:\temp\b3p0_338329_5444\batserve\win64\jpeg\jdmainct.c:354 [ 6] 0x00000000acacb32c jpeg_read_scanlines at c:\temp\b3p0_338329_5444\batserve\win64\jpeg\jdapistd.c:174 <SNIP> Any thoughts on this would be appreciated. Regards, Dinesh |
From: Bob F. <bfr...@si...> - 2015-03-14 14:40:27
|
On Fri, 13 Mar 2015, Loganaden Velvindron wrote: > Hi libjpeg developers, > > I've been working on a diff to harden libjpeg memory handling. > > I'd like to submit it for review as it as a low performance impact. > > What is the best way to achieve this ? Are the patches against IJG JPEG 6b? (see http://jpegclub.org/support/). IJG JPEG 8d1 and and v9a seem pretty robust in terms of memory handling thus far. I have not tested the 6b version. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Scott W. <sco...@sb...> - 2015-03-14 02:06:47
|
No idea from me. I subscribed to this for advice too. It is an extremely quiet email list. -Scptt ________________________________ From: Loganaden Velvindron <log...@gm...> To: lib...@li... Sent: Friday, March 13, 2015 6:38 AM Subject: [Libjpeg-devel-6x] Submitting patches Hi libjpeg developers, I've been working on a diff to harden libjpeg memory handling. I'd like to submit it for review as it as a low performance impact. What is the best way to achieve this ? Kind regards, //Logan C-x-C-c -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Libjpeg-devel-6x mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libjpeg-devel-6x |