Menu
▾
▴
libjpeg-devel-6x — Discussion around maintenance of libjpeg6.x
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: Guido V. <gu...@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 H. <fa...@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 L. <tg...@ss...> - 2009-10-07 04:49:24
|
Bob Friesenhahn <bfr...@si...> 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 F. <bfr...@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 bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Frank W. <war...@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, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Jon C. <li...@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 W. <war...@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, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Jon C. <li...@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 > Lib...@li... > 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 M. <al...@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 |
|
From: Farkas L. <lf...@lf...> - 2009-06-27 14:19:39
|
Frank Warmerdam wrote: > Farkas Levente wrote: > > hi, >> it's nice to see that someone still working on libjpeg. i'd be very >> happy if the next release solve somehow some of our biggest problem >> see in: >> http://sourceforge.net/mailarchive/message.php?msg_name=4A12C61E.9010701%40lfarkas.org >> >> http://sourceforge.net/mailarchive/message.php?msg_name=20090424140822.GA21954%40amd.home.annexia.org >> >> http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-May/001380.html >> >> in short the problem is when we try to compile libjpeg on win32 there >> are conflicts in windows system header files and libjpeg's header. >> is there any change that this will be also fixed? >> thanks. > > Farkas, > > As Tom mentioned in the thread, the intention is that libjpeg 6x is > intended to remain ABI compatible which makes me nervous about > changes to boolean or INT32 definitions. > > I have run into frequent issues with the boolean definition myself in > builds with libtiff and often have to futz with it. I'd like to improve > things but I don't want to alter the ABI. > > It might be a good idea to file a very clear summary ticket on the issue > in the libjpeg bug tracker. i do. > Hopefully this area of confusion will be dealt with in libjpeg 7x. just to be clear current code is not usable on win32, so any solution would be better then the current situation. -- Levente "Si vis pacem para bellum!" |
|
From: Frank W. <war...@po...> - 2009-06-27 13:19:13
|
Farkas Levente wrote: > hi, > it's nice to see that someone still working on libjpeg. i'd be very > happy if the next release solve somehow some of our biggest problem see in: > http://sourceforge.net/mailarchive/message.php?msg_name=4A12C61E.9010701%40lfarkas.org > http://sourceforge.net/mailarchive/message.php?msg_name=20090424140822.GA21954%40amd.home.annexia.org > http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-May/001380.html > in short the problem is when we try to compile libjpeg on win32 there > are conflicts in windows system header files and libjpeg's header. > is there any change that this will be also fixed? > thanks. Farkas, As Tom mentioned in the thread, the intention is that libjpeg 6x is intended to remain ABI compatible which makes me nervous about changes to boolean or INT32 definitions. I have run into frequent issues with the boolean definition myself in builds with libtiff and often have to futz with it. I'd like to improve things but I don't want to alter the ABI. It might be a good idea to file a very clear summary ticket on the issue in the libjpeg bug tracker. Hopefully this area of confusion will be dealt with in libjpeg 7x. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Farkas L. <lf...@lf...> - 2009-06-27 11:00:35
|
Frank Warmerdam wrote: > Folks, > > I have a project to support 8bit and 12bit jpeg compressed tiff files in > libtiff. Some details are at: > > http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG > > As part of this effort it is desirable to me to be able to build libjpeg > with the public api renamed so I can have two copies of libjpeg coexisting. > I have prepared a bug with a proposed patch to do this - similar to how > short names on platforms with brain damaged linkers used to be handled. > > https://sourceforge.net/tracker/?func=detail&aid=2809983&group_id=159521&atid=812162 > > I do not forsee this causing any disruption in the 6x libjpeg and would like > to incorporate the patch, possibly along with some changes to configure > to turn it and 12bit builds on. Does anyone have any thoughts or concerns > on this? hi, it's nice to see that someone still working on libjpeg. i'd be very happy if the next release solve somehow some of our biggest problem see in: http://sourceforge.net/mailarchive/message.php?msg_name=4A12C61E.9010701%40lfarkas.org http://sourceforge.net/mailarchive/message.php?msg_name=20090424140822.GA21954%40amd.home.annexia.org http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-May/001380.html in short the problem is when we try to compile libjpeg on win32 there are conflicts in windows system header files and libjpeg's header. is there any change that this will be also fixed? thanks. -- Levente "Si vis pacem para bellum!" |
|
From: Guido V. <gu...@jp...> - 2009-06-22 18:45:23
|
Bob Friesenhahn wrote: > > Like it or not, JPEG 6b will be with us for quite some time even when > JPEG 7 is available. It takes several years for conservative stable > Linux distributions (e.g. Debian) to update something as fundamental > as libjpeg, ... Actually the Debian libjpeg maintainer, Bill Allombert, was one of the most supportive forces for the v7 update! Particularly he has proposed the versioned symbol feature, to allow rapid installation of the new version and gradually update packages to use it without ABI compatibility issues. So I would expect rapid adoption in Linux distributions. Also notice that v8 is already announced for the next year, so 6b should vanish rather quickly. I have taken great care that v6b can be replaced seamlessly with v7, and even v8 will remain API compatible while introducing essential novelties. So lets look forward to the first update on Saturday, it should be there when you wake up and may be a good reason to celebrate... Regards Guido |
|
From: Bob F. <bfr...@si...> - 2009-06-22 16:09:03
|
On Mon, 22 Jun 2009, Bob Friesenhahn wrote: > > Like it or not, JPEG 6b will be with us for quite some time even when > JPEG 7 is available. It takes several years for conservative stable > Linux distributions (e.g. Debian) to update something as fundamental > as libjpeg, and many users are likely to lag by another year so we can > expect that JPEG 6b will remain dominant even on currently maintained > OSs for at least three years. Frank's approach allows for adding > simultaneous 12 bit support for specialized applications without upset > to the rest of the system. I should follow up by mentioning that since JPEG 7 provides a JPEG 6b compatible API, that if JPEG 7 incorporates the ability to be installed as an adjunct 12-bit library that it is possible for a library or application to use JPEG 6b for 8-bit JPEG and JPEG 7 for 12-bit JPEG. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Bob F. <bfr...@si...> - 2009-06-22 16:03:14
|
On Mon, 22 Jun 2009, Tom Lane wrote: > > Well, my thought is that you are never going to get anyone to build > libjpeg 6x that way because they aren't going to want to break all their > other applications. With v7 you have a chance to get the capability > into the "standard" build, where it might do you some good. My understanding of Frank's approach is that symbols are only renamed if libjpeg is built to support 12 bit JPEG, and a special configure flag is provided while building the library. The resulting library is built and installed with a unique foot-print. This means that it impacts virtually no-one in the world. Like it or not, JPEG 6b will be with us for quite some time even when JPEG 7 is available. It takes several years for conservative stable Linux distributions (e.g. Debian) to update something as fundamental as libjpeg, and many users are likely to lag by another year so we can expect that JPEG 6b will remain dominant even on currently maintained OSs for at least three years. Frank's approach allows for adding simultaneous 12 bit support for specialized applications without upset to the rest of the system. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Guido V. <gu...@el...> - 2009-06-22 09:34:43
|
Bob Friesenhahn wrote:
>
> Perhaps Guido can be convinced to include 12-bit symbol naming in the
> new library as well?
v7 supports versioned symbols.
Look in configure.ac and Makefile.am, by default it is enabled when available.
There is a file libjpeg.map in the distribution.
It has the content:
LIBJPEG_7.0 {
global:
*;
};
That way you can build different versions which can coexist without ABI
compatibility issues.
So if you choose another name than LIBJPEG_7.0 in that file, you can use
a different configuration in coexistence with the default version.
The default version will have only 8-bit support as usual. 12-bit is
not important enough for mainstream application, and there will be more
important features to implement preferential for v8 release next year.
> I understand that Guido Vollbeding is planning to release a libjpeg at
> release level 7 by the end of the month.
Yes, that's true. If no unexpected events happen, I will update www.ijg.org
on 27-Jun-2009 with the IJG JPEG 7 release from the current (17-Jun-2009)
pre-release: http://jpegclub.org/jpegsrc.v7pre.tar.gz
Regards
Guido
|
|
From: Frank W. <war...@po...> - 2009-06-22 05:14:03
|
Tom Lane wrote: > Frank Warmerdam <war...@po...> writes: >> Tom Lane wrote: >>> Yeah, ISTM that fooling with the API/ABI at all is not in the charter >>> for libjpeg 6x at this point. It would be better to try to address >>> this need in v7, if Guido doesn't feel that that's set in stone yet. > >> I would note that the proposed changes do not change the API or ABI >> in a normal build - only when things are built in a special way. I >> do not feel that it counts as an API/ABI change in the usual >> compatability sense. > > Well, my thought is that you are never going to get anyone to build > libjpeg 6x that way because they aren't going to want to break all their > other applications. With v7 you have a chance to get the capability > into the "standard" build, where it might do you some good. Tom, It will get built that way in a couple cases I care about! But I agree that it could be appealing to make this naming the default in 7x so it appears that way in various distributions. I have no arguments against that. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Tom L. <tg...@ss...> - 2009-06-22 05:11:58
|
Frank Warmerdam <war...@po...> writes: > Tom Lane wrote: >> Yeah, ISTM that fooling with the API/ABI at all is not in the charter >> for libjpeg 6x at this point. It would be better to try to address >> this need in v7, if Guido doesn't feel that that's set in stone yet. > I would note that the proposed changes do not change the API or ABI > in a normal build - only when things are built in a special way. I > do not feel that it counts as an API/ABI change in the usual > compatability sense. Well, my thought is that you are never going to get anyone to build libjpeg 6x that way because they aren't going to want to break all their other applications. With v7 you have a chance to get the capability into the "standard" build, where it might do you some good. regards, tom lane |
|
From: Frank W. <war...@po...> - 2009-06-22 04:57:25
|
Tom Lane wrote: > Bob Friesenhahn <bfr...@si...> writes: >> Perhaps Guido can be convinced to include 12-bit symbol naming in the >> new library as well? > > Yeah, ISTM that fooling with the API/ABI at all is not in the charter > for libjpeg 6x at this point. It would be better to try to address > this need in v7, if Guido doesn't feel that that's set in stone yet. Tom, I would note that the proposed changes do not change the API or ABI in a normal build - only when things are built in a special way. I do not feel that it counts as an API/ABI change in the usual compatability sense. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Tom L. <tg...@ss...> - 2009-06-22 04:48:15
|
Bob Friesenhahn <bfr...@si...> writes: > Perhaps Guido can be convinced to include 12-bit symbol naming in the > new library as well? Yeah, ISTM that fooling with the API/ABI at all is not in the charter for libjpeg 6x at this point. It would be better to try to address this need in v7, if Guido doesn't feel that that's set in stone yet. regards, tom lane |
|
From: Bob F. <bfr...@si...> - 2009-06-22 01:18:23
|
On Sun, 21 Jun 2009, Frank Warmerdam wrote: > > As part of this effort it is desirable to me to be able to build libjpeg > with the public api renamed so I can have two copies of libjpeg coexisting. > I have prepared a bug with a proposed patch to do this - similar to how > short names on platforms with brain damaged linkers used to be handled. I understand that Guido Vollbeding is planning to release a libjpeg at release level 7 by the end of the month. I have been running it here on various architecture types without noticing any important issues. I do notice that PSNR improves with the updated library. The subsampling algorithm is more advanced so results are not identical to JPEG 6b and images re-compressed from the originals may provide better quality. Perhaps Guido can be convinced to include 12-bit symbol naming in the new library as well? Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Frank W. <war...@po...> - 2009-06-21 20:23:57
|
Folks, I have a project to support 8bit and 12bit jpeg compressed tiff files in libtiff. Some details are at: http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG As part of this effort it is desirable to me to be able to build libjpeg with the public api renamed so I can have two copies of libjpeg coexisting. I have prepared a bug with a proposed patch to do this - similar to how short names on platforms with brain damaged linkers used to be handled. https://sourceforge.net/tracker/?func=detail&aid=2809983&group_id=159521&atid=812162 I do not forsee this causing any disruption in the 6x libjpeg and would like to incorporate the patch, possibly along with some changes to configure to turn it and 12bit builds on. Does anyone have any thoughts or concerns on this? PS. This should be my last message for today! Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Frank W. <war...@po...> - 2009-06-21 20:13:56
|
Tom Lane wrote: > Frank Warmerdam <war...@po...> writes: >> The std_huff_tables() function has a comment reading: > >> /* Set up the standard Huffman tables (cf. JPEG standard section K.3) */ >> /* IMPORTANT: these are only valid for 8-bit data precision! */ > >> So, my question is, does anyone know appropriate comparable tables to use >> for 12bit images? > > AFAIK the JPEG committee never did propose any default Huffman tables > for 12-bit mode :-( ... that's why libjpeg is set up to forcibly compute > a table in that mode. Tom, Thanks. I have successfully developed a huffman table that seems to work ok for a variety of 12 bit images. I basically picked a reference image, computed the symbol histogram, and added "1" to each bucket in the histogram and computed an optimal table based on that. I don't know how good this is, but at least it works and saves me a preprocessing pass which is difficult in the context of libtiff. I have prepared a patch for this, and attached it to a new ticket. I would appreciate feedback on it before I apply it. http://sourceforge.net/tracker/?func=detail&aid=2809979&group_id=159521&atid=812162 Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Frank W. <war...@po...> - 2009-06-21 19:49:56
|
Folks, I have added the existing libjpeg developers as candidate assignees on the Bugs tracker. https://sourceforge.net/tracker/?func=browse&group_id=159521&atid=812162 I have discovered a bug with the 16bit pnm support in libjpeg with regard to byte order. I have filed a bug on this: http://sourceforge.net/support/tracker.php?aid=2809967 and committed a fix in CVS head. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, war...@po... light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent |
|
From: Tom L. <tg...@ss...> - 2009-06-11 05:17:26
|
Frank Warmerdam <war...@po...> writes: > The std_huff_tables() function has a comment reading: > /* Set up the standard Huffman tables (cf. JPEG standard section K.3) */ > /* IMPORTANT: these are only valid for 8-bit data precision! */ > So, my question is, does anyone know appropriate comparable tables to use > for 12bit images? AFAIK the JPEG committee never did propose any default Huffman tables for 12-bit mode :-( ... that's why libjpeg is set up to forcibly compute a table in that mode. regards, tom lane |
3 messages has been excluded from this view by a project administrator.
