[Kde-graphics-devel] libjpeg 8 requirement considered harmful

Gilles Caulier caulier.gilles at gmail.com
Sat Jan 19 21:35:21 UTC 2013


Hi,

I try to do my best...

>From libraw 0.15 alpha changelog :

User-provided data streams (derived from LibRaw_abstract_datastream) should
implement jpeg_src() method to provide data source for JPEG decoder used in
lossy DNG processing. See src/libraw_datastream.cpp for sample
implementation.

... libjpeg is only used here to process specific DNG files...

For more information ask to libraw coordinator : alex tutubalin <lexa@
lexa.ru>

Best

Gilles Caulier


2013/1/19 Marcel Wiesweg <marcel.wiesweg at gmx.de>

> The commit which incremented the dependency (declared as optional, btw)
> was:
>
> commit 0b7d6977c0bbafe157c7558ac791171fffd4f177
> Author: Gilles Caulier <caulier.gilles at gmail.com>
> Date:   Wed Sep 19 23:18:40 2012 +0200
>
>     Add support to RawSpeed codec for Libraw 0.15.0-alpha5.
>     This option still experimental and is disabled by default.
>     Use Cmake switch -DENABLE_RAWSPEED=on to compile Libraw with RawSpeed
> support.
>
> CC'ing Gilles (currently having the flu dont expect an answer to soon)
>
> Marcel
>
>
> > Hi,
> >
> > as you have probably noticed, libkdcraw started requiring libjpeg ≥ 8 for
> > some of its functionality as of 4.10. Unfortunately, this is a problem
> for
> > Fedora and will remain a problem for Fedora for the foreseeable future.
> >
> > To explain why, let's discuss some history:
> >
> > * IJG libjpeg, as released by IJG, is not optimized, making it very slow
> for
> > some real-time applications, such as VNC. Therefore, the authors of
> > TurboVNC developed a speed-optimized fork of libjpeg, called
> libjpeg-turbo:
> > http://sourceforge.net/projects/libjpeg-turbo/
> > Initially, this was shipped as a bundled library, but because 1. we
> strongly
> > dislike bundled libraries in Fedora and 2. we want all applications to
> > benefit from the speed optimizations, since 2010 (Fedora 14), Fedora
> ships
> > this libjpeg-turbo fork instead of IJG libjpeg:
> > https://fedoraproject.org/wiki/Features/libjpeg-turbo
> >
> > * libjpeg-turbo is API/ABI-compatible with IJG libjpeg 6.2 (which, by the
> > way, is also the version in the LSB and the one binary-only software
> > (still) tends to expect).
> >
> > * IJG libjpeg, on the other hand, started making API and ABI changes to
> > their code to support some new features. While libjpeg-turbo has some
> > support for the IJG lijpeg 8 ABI, libjpeg-turbo's upstream considers the
> > additions and changes unnecessary and useless (mainly because JPEG files
> > using the new features cannot be read with older libjpeg
> implementations!),
> > will not guarantee that any added functionality actually works (only ABI
> > compatibility) and strongly recommends against enabling the new ABI:
> > http://sourceforge.net/mailarchive/message.php?msg_id=30352465
> >
> > * In Fedora, we had initially planned to enable the IJG libjpeg 8 ABI for
> > the upcoming Fedora 19:
> > https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI
> > but with the release of IJG libjpeg 9, the topic came up again, and
> > (following the above-cited discussion with upstream) it was decided to
> drop
> > that proposed feature.
> >
> > In other words: FEDORA WILL ONLY SHIP A libjpeg-6.2-COMPATIBLE ABI FOR
> THE
> > FORESEEABLE FUTURE.
> >
> > That said, adding new functions is not ABI-incompatible and can and will
> be
> > done where it makes sense (to libjpeg-turbo upstream). For example, the
> new
> > jpeg_mem_src() function will be present in next libjpeg-turbo release.
> > (Please send any requests for new functions directly to the upstream
> > libjpeg-turbo project.)
> >
> >
> > So the questions are:
> > * Why does libkdcraw require version ≥ 8 of libjpeg?
> > * What functionality from the new version does it actually require?
> > * Can it be made to work with libjpeg-turbo? If yes, how much work would
> > that be? (I'm willing to do the work if it isn't too much.)
> > * If you need (a) specific new function(s) (now or in the future), would
> it
> > be possible to test for that/those function(s) specifically instead of
> the
> > libjpeg ABI version?
> >
> > Kind regards,
> >         Kevin Kofler
> > _______________________________________________
> > Kde-graphics-devel mailing list
> > Kde-graphics-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-graphics-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20130119/285fe69f/attachment.html>


More information about the Kde-graphics-devel mailing list