FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-02-2010, 06:30 PM
Kevin Fenzi
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

On Sat, 2 Oct 2010 22:53:53 +0530
Mukund Sivaraman <muks@banu.com> wrote:

> Arithmetic coding in Fedora libjpeg (bug #639531)

...snip long thing...

My thoughts:

- We should not be making this change in stable releases even if
otherwise like the idea. It could well cause issues and problems with
a fragile library used by a lot of things.

- In f14+ we are not using libjpeg. We are using libjpeg-turbo. See:
http://fedoraproject.org/wiki/Features/libjpeg-turbo
So, any request to enable this support should be filed there and looked
at from it's perspective. Do they have support? Does it cause any
issues? Does upstream enable it?

- For the legal side, make your (new libjpeg-turbo) bug block FE_LEGAL
so it can be looked at.

kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-02-2010, 07:38 PM
Bjrn Persson
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

Peter Lemenkov wrote:
> Just for the record, AFAIK there are only two countries which allows
> software patents - USA and South Korea.

That's not the whole story. The situation is quite weird in countries that
have signed the European Patent Convention. The convention and the national
laws all state clearly that computer programs are not patentable, and yet
software patents are granted on a daily basis, justified with some irrational
reasoning that makes sense only to mentally deranged patent lawyers and some
gullible politicians. Tens of thousands of these illegal patents have been
granted.

Several years ago the patent lobby attempted to push through an EU directive
to legalize software patents. The directive was eventally dropped after years
of massive campaigning for and against, but that only means that the granting
of illegal patents continues as before.

Such a patent might not hold up in court if it were contested by a good lawyer
and the judge had some basic understanding of how computers work, but that
doesn't make the patents harmless. Due to the high cost and the uncertain
outcome of a patent lawsuit, small companies often have no choice but to pay
the license fees.

Bjrn Persson
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-02-2010, 08:03 PM
Tom Lane
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

Kevin Fenzi <kevin@scrye.com> writes:
> On Sat, 2 Oct 2010 22:53:53 +0530
> Mukund Sivaraman <muks@banu.com> wrote:
>> Arithmetic coding in Fedora libjpeg (bug #639531)

> My thoughts:

> - We should not be making this change in stable releases even if
> otherwise like the idea. It could well cause issues and problems with
> a fragile library used by a lot of things.

Don't worry, there's exactly 0 chance of that.

> - In f14+ we are not using libjpeg. We are using libjpeg-turbo. See:
> http://fedoraproject.org/wiki/Features/libjpeg-turbo

Yes. So actually the OP is pestering the wrong person; he should be
trying to convice the libjpeg-turbo maintainers to expend work on this.

I believe that they'd be best advised to say "no", because at this point
one of JPEG's principal attractions is near-universal compatibility.
Throwing A/C into the mix will throw that away, for what really is a
very marginal gain in compression efficiency. If you want a new
not-compatible-with-anything image format, you may as well adopt JPEG
2000, or some other format that's less than 20 years old. The A/C
option to original JPEG is something that missed its chance because of
patents. Resurrecting it from the dead now is just an exercise in
misplaced priorities.

But having said that, it's not my decision to make; it's the
libjpeg-turbo authors' decision whether to expend effort in that
direction.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-02-2010, 09:14 PM
Björn Persson
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

Tom Lane wrote:
> I believe that they'd be best advised to say "no", because at this point
> one of JPEG's principal attractions is near-universal compatibility.
> Throwing A/C into the mix will throw that away, for what really is a
> very marginal gain in compression efficiency.

It's well known around the Internet that to achieve compatibility you should
be conservative in what you send and liberal in what you accept. Applied to
JPEG: Use only Huffman coding when encoding – except maybe if you know that all
recipients can handle arithmetic coding – but support both encodings when
decoding.

Björn Persson
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2010, 01:20 AM
Gregory Maxwell
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

On Sat, Oct 2, 2010 at 1:34 PM, Paul F. Johnson
<paul@all-the-johnsons.co.uk> wrote:
> Hi,
>
>> "You shall not create images with arithmetic coding" is like saying "You
>> shall not create images of the flying sphagetti monster." It's not up to
>> Fedora to make this choice for me.
>
> It is though - you have chosen to use Fedora therefore have to live with
> the decisions the Fedora legal people (I'm assuming they said no to
> arithmetic coding) have said goes.

The relevant patent expired last year. I believe the SUN OMS team had
researched this extensively as they were using the JPEG arithmetic
coder in their aggressively researched royalty free video codec
design.

If someone doing legal research on this needs more information, you
can contact me offlist and I can connect you with people who have
researched this topic and may be willing to provide some useful
pointers.

2010/10/2 Björn Persson <bjorn@xn--rombobjrn-67a.se>:
> It's well known around the Internet that to achieve compatibility you should
> be conservative in what you send and liberal in what you accept. Applied to
> JPEG: Use only Huffman coding when encoding – except maybe if you know that all
> recipients can handle arithmetic coding – but support both encodings when
> decoding.

Absolutely. This is an excellent argument and I think is sufficient to
justify the inclusion alone.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2010, 02:48 AM
Kevin Kofler
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

Björn Persson wrote:
> It's well known around the Internet that to achieve compatibility you
> should be conservative in what you send and liberal in what you accept.
> Applied to JPEG: Use only Huffman coding when encoding – except maybe if
> you know that all recipients can handle arithmetic coding – but support
> both encodings when decoding.

+1

I can see not adding the support to the ENCODING portion, also because that
appears to imply an ABI change (extra flag), but the DECODING portion of the
patch should be merged.

The patch against the original libjpeg libjpeg-turbo is derived from should
probably work, it might not be "turbo"-optimized, but given how rare those
files are, that shouldn't be a problem. It's still better to be able to
decode the files slowly than not at all.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2010, 08:22 AM
Mukund Sivaraman
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

Hi all

In reply to Gregory Maxwell:
>> It's well known around the Internet that to achieve compatibility you
>> should be conservative in what you send and liberal in what you
>> accept. Applied to JPEG: Use only Huffman coding when encoding ?
>> except maybe if you know that all recipients can handle arithmetic
>> coding ? but support both encodings when decoding.

>Absolutely. This is an excellent argument and I think is sufficient to
>justify the inclusion alone.

Thank you everyone for the replies. I did not know earlier that Fedora
was switching to libjpeg-turbo. I have created a new bug now:

https://bugzilla.redhat.com/show_bug.cgi?id=639672
Add support for decoding arithmetic coded files in libjpeg-turbo

It contains a patch against upstream libjpeg-turbo HEAD, and the patch
has been submitted upstream too:

https://sourceforge.net/tracker/?func=detail&aid=3080268&group_id=303195&atid=1278 160

This patch has been tested against some arithmetic coded images.

I wish libjpeg-turbo also accepts to include creating arithmetic coded
images too, as the project is not really going to affect creation of
such images if an application wants to do so. But this can be saved
for another argument, and doesn't stand in the way of decode support.

Mukund
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-03-2010, 04:45 PM
Roberto Ragusa
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

Björn Persson wrote:
> Tom Lane wrote:
>> I believe that they'd be best advised to say "no", because at this point
>> one of JPEG's principal attractions is near-universal compatibility.
>> Throwing A/C into the mix will throw that away, for what really is a
>> very marginal gain in compression efficiency.
>
> It's well known around the Internet that to achieve compatibility you should
> be conservative in what you send and liberal in what you accept. Applied to
> JPEG: Use only Huffman coding when encoding – except maybe if you know that all
> recipients can handle arithmetic coding – but support both encodings when
> decoding.
>

Well said.
Adding decoding support can do no harm.

--
Roberto Ragusa mail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-04-2010, 09:13 AM
Adam Tkac
 
Default Arithmetic coding in Fedora libjpeg (bug #639531)

On Sun, Oct 03, 2010 at 01:52:28PM +0530, Mukund Sivaraman wrote:
> Hi all
>
> In reply to Gregory Maxwell:
> >> It's well known around the Internet that to achieve compatibility you
> >> should be conservative in what you send and liberal in what you
> >> accept. Applied to JPEG: Use only Huffman coding when encoding ?
> >> except maybe if you know that all recipients can handle arithmetic
> >> coding ? but support both encodings when decoding.
>
> >Absolutely. This is an excellent argument and I think is sufficient to
> >justify the inclusion alone.
>
> Thank you everyone for the replies. I did not know earlier that Fedora
> was switching to libjpeg-turbo. I have created a new bug now:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=639672
> Add support for decoding arithmetic coded files in libjpeg-turbo
>
> It contains a patch against upstream libjpeg-turbo HEAD, and the patch
> has been submitted upstream too:
>
> https://sourceforge.net/tracker/?func=detail&aid=3080268&group_id=303195&atid=1278 160
>
> This patch has been tested against some arithmetic coded images.
>
> I wish libjpeg-turbo also accepts to include creating arithmetic coded
> images too, as the project is not really going to affect creation of
> such images if an application wants to do so. But this can be saved
> for another argument, and doesn't stand in the way of decode support.

We decided to accept arithmetic method into libjpeg-turbo upstream as
soon as Fedora legal says it's fine.

Regards, Adam

--
Adam Tkac, Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org