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
|
|
From: Lluís Batlle i Rossell <viriketo@gm...> - 2010-10-30 22:40:37
|
Hello, I'm trying to make a program that will not decode full pictures into a single big JSAMPARRAY. So if the user wants to see only 10% of the lines, then I want to be able to decode 10% of the lines. I've tried to set output_scanline to something bigger than zero, but that looks like making zero effect - the lines I get with jpeg_read_scanline start from 0 regardless of the initial output_scanline value. What can I do to get only some specific scanlines decoded? I'm using libjpeg-8. Thank you, Lluís. |
|
From: linux newbie <linux.newbie79@gm...> - 2010-06-29 01:15:58
|
Hi, I am using latest libjpeg and I need to know how to do scaling. My embedded target screen resolution is 640x240 and my jpeg picture is of 800x600. On doing decompression, I belive I need to set the values in jpeg_decompress_struct for scaling, but not sure. can anyone let me know with an example? Thanks |
|
From: Markus Messmer <mamessme@ht...> - 2010-06-17 08:02:35
|
Tom Lane <tgl@...>: > > is there a way to get the unquantized coefficients from libjpeg during a > > compression process? What I want to do is to see how the coefficients got > > rounded after they got divided with the quantization table. How could I > > achieve this? > > Insert some printf's, maybe? There's certainly no provision for > exposing that to the application. I meant an interface to libjpeg, so a calling application has direct access to the intermediate steps, eg coefficients before rounding. But yes, as you said, this is not a common use case, maybe I'm better of writing a simple jpeg compressor with this feature for my application. best Markus |
|
From: Tom Lane <tgl@ss...> - 2010-06-17 03:32:09
|
Markus Messmer <mamessme@...> writes: > is there a way to get the unquantized coefficients from libjpeg during a > compression process? What I want to do is to see how the coefficients got > rounded after they got divided with the quantization table. How could I > achieve this? Insert some printf's, maybe? There's certainly no provision for exposing that to the application. regards, tom lane |
|
From: Markus Messmer <mamessme@ht...> - 2010-06-16 12:07:02
|
Hi all, is there a way to get the unquantized coefficients from libjpeg during a compression process? What I want to do is to see how the coefficients got rounded after they got divided with the quantization table. How could I achieve this? Best regards Markus |
|
From: Galileo`s <liujian883@qq...> - 2010-05-16 03:25:42
|
hi,all.im from China,im doing a project which applies this LibJpeg to convert RGB to JPEG.mealwhile,im using uCGUI(know ucOSII??),but uCGUI only uses the part of decompression.i wanna send the data compressed by LibJpeg to my phone via MMS.i have a OV9650 camera .it can transferes (SCCB interface)RGB data to my s3c2440 ARM core. i have a little about LibJpeg and JPEG ,i read the introduce to LibJpeg. i wonder whether the data compressed by LibJpeg is the .jpg format.can it be read by phone directly??if not ,is it means that i must add some other info to the data compressed by LibJpeg. can you give me some suggestion? im sorry for my poor english. |
|
From: Galileo`s <liujian883@qq...> - 2010-05-14 12:32:32
|
hi,all.im from China,im doing a project which applies this LibJpeg to convert RGB to JPEG.mealwhile,im using uCGUI(know ucOSII??),but uCGUI only uses the part of decompression.i wanna send the data compressed by LibJpeg to my phone via MMS.i have a OV9650 camera .it can transferes (SCCB interface)RGB data to my s3c2440 ARM core. i have a little about LibJpeg and JPEG ,i read the introduce to LibJpeg. i wonder whether the data compressed by LibJpeg is the .jpg format.can it be read by phone directly??if not ,is it means that i must add some other info to the data compressed by LibJpeg. can you give me some suggestion? im sorry for my poor english. |
|
From: Tom Lane <tgl@ss...> - 2010-04-29 22:42:24
|
Justin Wetherell <phishman3579@...> writes: > I believe there is a memory leak in the jpeg_write_scanlines() function. The > code below takes a frame image from a dc1394 camera and turns it into a jpeg > inside a while loop. The memory usage increases 0.1% about every 5 seconds > on an embedded ARM processor with very little memory and processor power. I'm not sure what jpeg_mem_dest is --- it's not part of libjpeg 6b. I'd bet the leak is within the code installed by that. It is very highly unlikely that a leak in jpeg_write_scanlines proper would have escaped notice for all these years. (But are you sure it's a leak at all? I assume from the name that this is code meant to store the resulting JPEG data in memory. Perhaps you're just watching the accumulation of output data?) regards, tom lane |
|
From: Tom Lane <tgl@ss...> - 2010-04-29 22:41:29
|
Justin Wetherell <phishman3579@...> writes: > Actually, sorry I am using the libjpeg v8a version which is where the > jpeg_mem_dest. I didn't realize this is the specific v6 distro list. Is > there a v8 mailing list that you know of? I don't know of one. I'd suggest reporting the problem to Guido directly --- I assume there's a contact address in the v8 docs ... regards, tom lane |
|
From: Justin Wetherell <phishman3579@gm...> - 2010-04-29 22:37:16
|
Actually, sorry I am using the libjpeg v8a version which is where the jpeg_mem_dest. I didn't realize this is the specific v6 distro list. Is there a v8 mailing list that you know of? On Thu, Apr 29, 2010 at 6:23 PM, Tom Lane <tgl@...> wrote: > Justin Wetherell <phishman3579@...> writes: > > I believe there is a memory leak in the jpeg_write_scanlines() function. > The > > code below takes a frame image from a dc1394 camera and turns it into a > jpeg > > inside a while loop. The memory usage increases 0.1% about every 5 > seconds > > on an embedded ARM processor with very little memory and processor power. > > I'm not sure what jpeg_mem_dest is --- it's not part of libjpeg 6b. > I'd bet the leak is within the code installed by that. It is very > highly unlikely that a leak in jpeg_write_scanlines proper would > have escaped notice for all these years. > > (But are you sure it's a leak at all? I assume from the name that > this is code meant to store the resulting JPEG data in memory. > Perhaps you're just watching the accumulation of output data?) > > regards, tom lane > |
|
From: Justin Wetherell <phishman3579@gm...> - 2010-04-29 21:19:47
|
I believe there is a memory leak in the jpeg_write_scanlines() function. The
code below takes a frame image from a dc1394 camera and turns it into a jpeg
inside a while loop. The memory usage increases 0.1% about every 5 seconds
on an embedded ARM processor with very little memory and processor power.
static struct jpeg_compress_struct cinfo;
static struct jpeg_error_mgr jerr;
static JSAMPROW row_pointer[1];
cinfo.err = jpeg_std_error( &jerr );
jpeg_create_compress(&cinfo);
while( !pglobal->stop ) {
pthread_mutex_lock( &pglobal->db );
err = dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT,
&frames[0]);
memcpy(latestFrame, frames[0]->image, frameWidth * frameHeight);
static unsigned char *jpeg = NULL;
static long unsigned jpegSize = 0;
jpeg_mem_dest(&cinfo, &jpeg, &jpegSize);
cinfo.image_width = frameWidth;
cinfo.image_height = frameHeight;
cinfo.input_components = 1;
cinfo.in_color_space = JCS_GRAYSCALE;
jpeg_set_defaults( &cinfo );
jpeg_start_compress( &cinfo, TRUE );
while( cinfo.next_scanline < cinfo.image_height ) {
row_pointer[0] = &latestFrame[ cinfo.next_scanline *
cinfo.image_width * cinfo.input_components];
jpeg_write_scanlines( &cinfo, row_pointer, 1 );
}
jpeg_finish_compress( &cinfo );
err = dc1394_capture_enqueue(camera, frames[0]);
pglobal->size = jpegSize;
memcpy(pglobal->buf, jpeg, pglobal->size);
pthread_cond_broadcast(&pglobal->db_update);
pthread_mutex_unlock( &pglobal->db );
if(trigger==0)usleep(1000*delay);
}
jpeg_destroy_compress( &cinfo );
If I comment out the code from "jpeg_start_compress( &cinfo, TRUE );" to
"jpeg_finish_compress( &cinfo );" (like below) the memory usage stays
consistent.
//jpeg_set_defaults( &cinfo );
//jpeg_start_compress( &cinfo, TRUE );
//while( cinfo.next_scanline < cinfo.image_height ) {
// row_pointer[0] = &latestFrame[ cinfo.next_scanline *
cinfo.image_width * cinfo.input_components];
// jpeg_write_scanlines( &cinfo, row_pointer, 1 );
//}
//jpeg_finish_compress( &cinfo );
Any help would be appreciated,
-Justin
|
|
From: Tom Lane <tgl@ss...> - 2010-02-27 02:53:47
|
Jonathan Wallace <jwallace@...> writes: > There is a glaring omission from it which anyone who uses *nix will notice right away. > ./configure > make > sudo make install What's wrong with that? > You can never install anything on the Mac without going through the > superuser. Sure, that's what the "sudo" is for. regards, tom lane |
|
From: Bob Friesenhahn <bfriesen@si...> - 2010-02-26 21:59:11
|
On Fri, 26 Feb 2010, Jonathan Wallace wrote: > There is a glaring omission from it which anyone who uses *nix will notice right away. > ./configure > make > sudo make install > > You can never install anything on the Mac without going through the > superuser. I'm fairly certain it's the same way on all *nix > distribution. How this hasn't been fixed yet is beyond me. This is not true. The person building the software could use an installation prefix where their user ID has write access. I am glad that you were able to figure this out even though the documentation is lacking. Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Jonathan Wallace <jwallace@li...> - 2010-02-26 19:52:53
|
There is a glaring omission from it which anyone who uses *nix will notice right away. ./configure make sudo make install You can never install anything on the Mac without going through the superuser. I'm fairly certain it's the same way on all *nix distribution. How this hasn't been fixed yet is beyond me. |
|
From: Guido Vollbeding <guido@jp...> - 2009-10-07 13:08:07
|
Hello Allan > > And even v7 is fading fast into history. > > v8 is ready here and will be released on 1-Jan-2010. > > > > Is there going to be api changes this time? No. That's why it was good to release v7 so that the changes can be resolved now. No further adaptions should be necessary for v8. But there are of course reasons for the jump from v7 to v8: Applications need again to be recompiled, due to extension of the parameter master records, and there will be a format extension which will introduce new flavors of JPEG files, similar to adding progressive support in v6 and arithmetic support in v7. > The libjpeg6 to 7 upgrade was complicated by the change in scaling. > > jpeg-6b: Currently, the only supported scaling ratios are 1/1, 1/2, 1/4, > and 1/8. > jpeg-7: Currently, the supported scaling ratios are 8/N with all N from > 1 to 16. It was not complicated, but people just got confused that scaling has now been introduced also for the compression side. The 8/N figure is for *compression*! For decompression it is N/8 and the old cases are a subset thereof (N=8,4,2,1). > Also, is there a mailing list for the development of libjpeg apart from > this one? There is no mailing list. I will make available pre-release versions of v8 on jpegclub.org in some weeks (when adaptions of the Jpegcrop sample program are finished), similar as done with v7. Regards Guido |
|
From: Allan McRae <mcrae_allan@ho...> - 2009-10-07 12:56:33
|
Guido Vollbeding wrote: > I have noticed that jpeg-7 is available on Google Code under GhostScript > (will find this when searching for "ijg jpeg-7" on google). > And even v7 is fading fast into history. > v8 is ready here and will be released on 1-Jan-2010. > Is there going to be api changes this time? The libjpeg6 to 7 upgrade was complicated by the change in scaling. jpeg-6b: Currently, the only supported scaling ratios are 1/1, 1/2, 1/4, and 1/8. jpeg-7: Currently, the supported scaling ratios are 8/N with all N from 1 to 16. Also, is there a mailing list for the development of libjpeg apart from this one? Allan |
|
From: Guido Vollbeding <guido@jp...> - 2009-10-07 08:04:58
|
Bob Friesenhahn wrote: > > It seems that the IJG JPEG license is not OSI-Approved. The > libjpeg-devel-6x project (based on jpeg 6b sources) is a SourceForge > project. 6b is long outdated. I don't care about this anymore, and people who do so are simply ignorant. I have not initiated the SourceForge project, so those people who did should take the responsibility to make an appropriate update. The only actual reference for current libjpeg code is http://www.ijg.org. I have noticed that jpeg-7 is available on Google Code under GhostScript (will find this when searching for "ijg jpeg-7" on google). And even v7 is fading fast into history. v8 is ready here and will be released on 1-Jan-2010. It is not my task to fulfill certain conditions of any repository site. I don't care about this, so this has to be done by others if they set value on it. Regards Guido |
|
From: Lee Howard <faxguy@ho...> - 2009-10-07 05:02:13
|
Tom Lane wrote: > bailing out of sourceforge might be the best strategy. I have to believe that they'll get a clue shortly, and in the end this will all just be a small bump with Sourceforge being the most-jostled. I don't plan on pulling my other projects until I see an eviction notice, but I strongly doubt that it would go that far. Thanks, Lee. |
|
From: Tom Lane <tgl@ss...> - 2009-10-07 04:49:24
|
Bob Friesenhahn <bfriesen@...> writes: > It seems that the IJG JPEG license is not OSI-Approved. So submit it ... it's not materially different from, say, http://www.opensource.org/licenses/zlib-license.php so it's hard to believe they wouldn't approve it. I actually thought that it *was* OSI approved already. I woulda sworn that it was on their list way back when. > The libjpeg-devel-6x project (based on jpeg 6b sources) is a > SourceForge project. Of course, in light of all the other interesting stuff going on there, bailing out of sourceforge might be the best strategy. regards, tom lane |
|
From: Bob Friesenhahn <bfriesen@si...> - 2009-10-07 04:15:51
|
It seems that the IJG JPEG license is not OSI-Approved. The libjpeg-devel-6x project (based on jpeg 6b sources) is a SourceForge project. SourceForge is planning that by October 19th, all SourceForge projects must use an OSI-Approved license (see https://sourceforge.net/apps/trac/sitelegal/wiki/Terms_of_Use). Besides SourceForge, Google Code already requires that projects use an OSI-Approved license (but only a subset). It is pretty common that libjpeg becomes embedded in larger projects which could end up on an OSI-only site like SourceForge or Google Code. By the end of the month it will be a violation of site usage policy to upload a package which inludes libjpeg. This seems to be a continuing trend. What should be done about this situation? Bob -- Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Frank Warmerdam <warmerdam@po...> - 2009-07-27 19:50:17
|
Frank Warmerdam wrote: > Folks, > > I thought I had pretty much slain the 12bit jpeg dragon until my client > actually tried compressing with high quality values. At this point I > start getting "Bogus Huffman table definition" which appears to reflect > some sort of table size overflow. > > I am wondering if anyone else is using libjpeg to compress 12bit jpeg > data and could suggest ways of resolving this problem? > > The file in question is: > > http://download.osgeo.org/gdal/data/pnm/mandril_12bit.pnm > > Try compressing it like: > > cjpeg -quality 90 -outfile out.jpg mandril_12bit.pnm > > after building libjpeg and cjpeg in 12bit mode of course. If appropriate > I can seek client funding for meaningful assistance. Folks, It turns out the problem was only occuring when I was adapting the optimized huffman table, not with normal optimized huffman tables. I found a bug in the way I was adapting them, which I have corrected and I have updated the 12bit default table accordingly in jcparam.c. The issue now seems to be resolved. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Jon Ciesla <limb@jc...> - 2009-07-16 12:21:16
|
Allan McRae wrote: > Jon Ciesla wrote: >> I was not aware that libjpeg7 had been released yet. Did I miss it? > > Seems so: http://www.ijg.org/ > > > I see nothing on SourceForge. Guido, assuming this is the fruit of your efforts, can I be of assistance publishing this on SF, as many libjpeg pacakgers look there for new releases, and understand that to be the official distribution point? Jon -- in your fear, speak only peace in your fear, seek only love -d. bowie |
|
From: Frank Warmerdam <warmerdam@po...> - 2009-07-15 21:27:53
|
Folks, I thought I had pretty much slain the 12bit jpeg dragon until my client actually tried compressing with high quality values. At this point I start getting "Bogus Huffman table definition" which appears to reflect some sort of table size overflow. I am wondering if anyone else is using libjpeg to compress 12bit jpeg data and could suggest ways of resolving this problem? The file in question is: http://download.osgeo.org/gdal/data/pnm/mandril_12bit.pnm Try compressing it like: cjpeg -quality 90 -outfile out.jpg mandril_12bit.pnm after building libjpeg and cjpeg in 12bit mode of course. If appropriate I can seek client funding for meaningful assistance. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Jon Ciesla <limb@jc...> - 2009-07-15 15:57:50
|
Allan McRae wrote: > Hi all, > > I thought people subscribed to this list may like to know about how the > transition to libjpeg7 went for Arch Linux. There were no issues > compiling against it but some programs have issues displaying images. > > - Konqueror: jpeg images are shown at twice their size if height and > width properties are not set [1]. > - GTK+: some apps display images that a blurry or black (e.g. geenie > [2], eog). It may be related to the use of gdk-pixbuf to load jpegs, > although other apps using that seem fine... > - openjdk6: dlopen's libjpeg and then crashes. > > Otherwise, the transition was fairly straight forward given the large > numbers of packages that link to this library. > > Regards, > Allan > > [1] https://bugs.kde.org/show_bug.cgi?id=198779 > [2] > http://sourceforge.net/tracker/?func=detail&aid=2819892&group_id=222125&atid=1054680 > > > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Libjpeg-devel-6x mailing list > Libjpeg-devel-6x@... > https://lists.sourceforge.net/lists/listinfo/libjpeg-devel-6x > I was not aware that libjpeg7 had been released yet. Did I miss it? -- in your fear, speak only peace in your fear, seek only love -d. bowie |
|
From: Allan McRae <allan@ar...> - 2009-07-15 15:31:32
|
Hi all, I thought people subscribed to this list may like to know about how the transition to libjpeg7 went for Arch Linux. There were no issues compiling against it but some programs have issues displaying images. - Konqueror: jpeg images are shown at twice their size if height and width properties are not set [1]. - GTK+: some apps display images that a blurry or black (e.g. geenie [2], eog). It may be related to the use of gdk-pixbuf to load jpegs, although other apps using that seem fine... - openjdk6: dlopen's libjpeg and then crashes. Otherwise, the transition was fairly straight forward given the large numbers of packages that link to this library. Regards, Allan [1] https://bugs.kde.org/show_bug.cgi?id=198779 [2] http://sourceforge.net/tracker/?func=detail&aid=2819892&group_id=222125&atid=1054680 |