On Mon, Mar 14, 2005 at 10:37:09PM -0500, Mathieu Malaterre wrote:
> 1) the lossless jpeg patch.
>
> correct this is the one from:
> http://www.oceana.com/ftp/ljpeg/
>
> 2) a custom patch from Gdcm.
>
> correct. It fixes some issues, fixes some compile warnings (-Wall)
>
> 3) another patch from Gdcm that add support for 16bit.
>
> Well this is really your 4). The patch for this is included with 2) anyway
Prisitine libjpeg sources does not support 16bit, AFAICS.
> 4) three builds, one for 8,12 and 16 bit.
>
> correct. The build process is managed by cmake to avoid duplicating
> source or copying source file within a directory a compile time.
> Basically it changes a #define in a header file, include a specific
> header file that mangle all the name.
>
> Therefore if the old lossy 8bits had symbol foo. When build with my
> patch it will be called: foo8, foo12 and foo16. Which will all be in
> three different library: libjpeg8, libjpeg12 and libjpeg16.
So it is 4 distinct ABI (and maybe 4 API as well):
current libjpeg, libjpeg8, libjpeg12 and libjpeg16.
If you really need that, I suggest we reassign this report as an RFP. It
seems too drastic a change for the base libjpeg library: given the
number of packages using it, any mistake here is critical.
A separate source package for libjpeg{8,12,16} could be easier to
work with.
> Mathieu
> Ps: as a side note 16bits is lossless only (does not make sense to do
> lossy and coded on 16 bits).
You mean 16bit support is in the lossless patch ?
Cheers,
--
Bill. <[EMAIL PROTECTED]>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
