Error interpreting JPEG file
Tduell
I have just migrated from Fedora 14 to fedora 15, and having set up my
rpmbuild and all the libs, built the latest default branch hugin.
It all appears to work OK, however the Fedora image viewer (eye-of-
gnome) gives an error when I attempt to display a jpeg pano stitched
by my fc15 version of hugin.
It gives the following error message "error interpreting JPEG file
(Suspension not allowed here)".
Gimp can display the file, and if I save it out of gimp as new jpeg,
eye-of-gnome displays it OK.
Eye-of-gnome doesn't have any problems displaying panos stitched by my
previous versions of hugin.
An internet search didn't turn up any info related to the error
message.
I am wondering if I have built hugin with the wrong jpeg libs. The
only libjpeg that appeared in the Fedora repo was libjpeg-turbo, which
I used, but it doesn't sound familiar.
Does anyone have any ideas as to what might be wrong?
Cheers,
Terry
Bruno Postle
> I have just migrated from Fedora 14 to fedora 15, and having set
> up my rpmbuild and all the libs, built the latest default branch
> hugin. It all appears to work OK, however the Fedora image viewer
> It gives the following error message "error interpreting JPEG file
> (Suspension not allowed here)".
> Gimp can display the file, and if I save it out of gimp as new
> jpeg, eye-of-gnome displays it OK.
> Eye-of-gnome doesn't have any problems displaying panos stitched
> by my previous versions of hugin.
I see the same problem on fedora f15 with JPEG files written by both
nona and enblend.
The new files are different, they don't open with eog on my
(ancient) centos4 machine with this error:
loading failed: Error interpreting JPEG image file (Sorry, there are legal restrictions on arithmetic coding).
> The only libjpeg that appeared in the Fedora repo was
> libjpeg-turbo, which I used, but it doesn't sound familiar.
Fedora has switched from libjpeg to the forked libjpeg-turbo which
now has support for arithmetic coding (which was always in the JPEG
spec, just nobody ever used it).
So something in hugin/vigra/libjpeg-turbo is now creating arithmetic
coded JPEG files even though this should never be the default.
In src/foreign/vigra/vigra_impex/jpeg.cxx we have this:
#ifdef C_ARITH_CODING_SUPPORTED
info.arith_code = TRUE;
#endif
This looks to me like a vigra bug, it seems that vigra will always
produce arithmetic coded files if the JPEG library supports it.
Can someone confirm my interpretation?
This will need to be fixed in enblend-enfuse, the same code exists
in Hugin too but in normal circumstances you will never see a JPEG
file created by nona/Hugin.
--
Bruno
Terry Duell
On Wed, 08 Jun 2011 08:57:21 +1000, Bruno Postle <br...@postle.net> wrote:
[snip]
> Fedora has switched from libjpeg to the forked libjpeg-turbo which now
> has support for arithmetic coding (which was always in the JPEG spec,
> just nobody ever used it).
>
> So something in hugin/vigra/libjpeg-turbo is now creating arithmetic
> coded JPEG files even though this should never be the default.
>
> In src/foreign/vigra/vigra_impex/jpeg.cxx we have this:
>
> #ifdef C_ARITH_CODING_SUPPORTED
> info.arith_code = TRUE;
> #endif
> This looks to me like a vigra bug, it seems that vigra will always
> produce arithmetic coded files if the JPEG library supports it.
I'm no expert, but this does look like the culprit.
> Can someone confirm my interpretation.
> This will need to be fixed in enblend-enfuse, the same code exists in
> Hugin too but in normal circumstances you will never see a JPEG file
> created by nona/Hugin.
As 'no answer' was the stern reply, maybe it would be worth testing this.
I'll have a look at building a local version of enblend-enfuse with this
code commented out and see what happens.
Cheers,
--
Regards,
Terry Duell
Terry Duell
On Thu, 09 Jun 2011 12:04:36 +1000, Terry Duell <tdu...@iinet.net.au>
wrote:
> Hullo Bruno,
>
> On Wed, 08 Jun 2011 08:57:21 +1000, Bruno Postle <br...@postle.net>
> wrote:
[snip]
>> In src/foreign/vigra/vigra_impex/jpeg.cxx we have this:
>>
>> #ifdef C_ARITH_CODING_SUPPORTED
>> info.arith_code = TRUE;
>> #endif
>> This looks to me like a vigra bug, it seems that vigra will always
[snip]
> As 'no answer' was the stern reply, maybe it would be worth testing this.
> I'll have a look at building a local version of enblend-enfuse with this
> code commented out and see what happens.
I rebuilt enblend-enfuse with the above code commented out. There may be
better ways of doing this.
The pano now stitched can be opened in eye-of-gnome (Fedora 15 x86_64), so
that was the problem. Not sure if changing the code this way has other
side effects. We need someone who knows more about this to look at a
'proper' change to the enblend-enfuse code.
Whilst testing (hugin hg6bc92bf521eb) I had some other problems. After
alignment the FPW fails to open and the cpu continues to run at 100%. I
had to kill hugin.
I had a similar experience when first testing this version on fc15, but it
isn't 100% repeatable. Possibly some issue related to fc15 or something in
the source. The previous version (hg4ac7e44431c7) seemed stable on fc14
Bruno Postle
>>>In src/foreign/vigra/vigra_impex/jpeg.cxx we have this:
>>>
>>> #ifdef C_ARITH_CODING_SUPPORTED
>>> info.arith_code = TRUE;
>>> #endif
> I rebuilt enblend-enfuse with the above code commented out. There
> may be better ways of doing this.
> The pano now stitched can be opened in eye-of-gnome (Fedora 15
> x86_64), so that was the problem. Not sure if changing the code
> this way has other side effects. We need someone who knows more
> about this to look at a 'proper' change to the enblend-enfuse
> code.
It's a bug in vigra_impex, I'll report it in vigra upstream and see
how they want to fix it.
--
Bruno
Terry Duell
On Fri, 10 Jun 2011 06:23:40 +1000, Bruno Postle <br...@postle.net> wrote:
[snip]
> It's a bug in vigra_impex, I'll report it in vigra upstream and see how
> they want to fix it.
From what I read, it seems that the arithmetic coding algorithm patent has
now expired, which would explain Fedora adopting the libjpeg-turbo library.
That leads me to wonder if the vigra_impex code is OK and that it is
eye-of-gnome that is out of kilter by not being able to decode the
arithmetic coded jpeg...or have I got hold of the wrong end of the stick?
Bruno Postle
>
>From what I read, it seems that the arithmetic coding algorithm
>patent has now expired, which would explain Fedora adopting the
>libjpeg-turbo library.
libjpeg-turbo is supposedly faster due to some assembly
optimisation.
>That leads me to wonder if the vigra_impex code is OK and that it is
>eye-of-gnome that is out of kilter by not being able to decode the
>arithmetic coded jpeg...or have I got hold of the wrong end of the
>stick?
Yes, either EOG has a bug or there is something not-quite-right
about the arithmetic coded files hugin/enblend/libjpeg-turbo are
producing - The files only fail to open in EOG when you set JPEG
quality to 100 in Hugin, otherwise they are ok
Regardless, we don't want Hugin creatings arithmetic coded files,
they are not very portable.
--
Bruno
Terry Duell
On Sat, 11 Jun 2011 06:55:30 +1000, Bruno Postle <br...@postle.net> wrote:
> Yes, either EOG has a bug or there is something not-quite-right about
> the arithmetic coded files hugin/enblend/libjpeg-turbo are producing -
> The files only fail to open in EOG when you set JPEG quality to 100 in
> Hugin, otherwise they are ok
Fails here with quality set to 90.
>
> Regardless, we don't want Hugin creatings arithmetic coded files, they
> are not very portable.
OK.