there is a confirmed bug when writing jpeg file format with the current
linux build (beta39). when specifying +fj output format the following
error occurs:

JPEG parameter struct mismatch: library thinks size is 372, caller
expects 376
JPEG parameter struct mismatch: library thinks size is 372, caller
expects 376
Render failed

this has been confirmed on ubuntu 10.4 and openSuSe 11.2 (assuming 32
bit version) as openSuSe 11.2 64-bit reports no problem

there has been a proposed fix to ~smp/source/base/image/jpeg.cpp that
appears to work, however it requires some additional work to make it a
platform specific fix.

before going too much further i was wondering if anyone has done a
source build against the 8b version of libjpeg ... maybe we might get
lucky and this problem will become a non issue by simply upgrading to a
newer version. i imagine there's probably going to be other fallout from
going to v8b, so before i tear into my setup to investigate, i thought
i'd ask first and see if anyone else has experienced any pain from doing so!

jim

Post a reply to this message

Le 07/08/2010 17:27, Jim Holsenback nous fit lire :
> this has been confirmed on ubuntu 10.4 and openSuSe 11.2 (assuming 32
> bit version) as openSuSe 11.2 64-bit reports no problem
> 

> before going too much further i was wondering if anyone has done a
> source build against the 8b version of libjpeg ... 


Source built of beta38 is against libjpeg62 on my ubuntu 10.4 (amd64);
Any suggesttion where to find 8b ? (a launchpad experiment ? or only on
x86 ? somewhere else ?)

Please notice that the beta source only provide beta35, a post provide
beta38. No official 39 so far for source.

Post a reply to this message

On 08/07/2010 05:09 PM, Le_Forgeron wrote:
> Le 07/08/2010 17:27, Jim Holsenback nous fit lire :
>> this has been confirmed on ubuntu 10.4 and openSuSe 11.2 (assuming 32
>> bit version) as openSuSe 11.2 64-bit reports no problem
>>
> 
>> before going too much further i was wondering if anyone has done a
>> source build against the 8b version of libjpeg ... 
> 
> 
> Source built of beta38 is against libjpeg62 on my ubuntu 10.4 (amd64);

are you seeing the problem ... just use +ua +fj
clipka didn't see it on his opensuse 11.2 (64), but chris cason did on
ubuntu 10.4 (32), and so did i on opensuse 11.2 (32)

> Any suggesttion where to find 8b ? (a launchpad experiment ? or only on
> x86 ? somewhere else ?)

http://www.ijg.org/

> 
> Please notice that the beta source only provide beta35, a post provide
> beta38. No official 39 so far for source.
> 

yikes ... you are correct ... sorry about that (it's certainly a luxury
to have access to the code repository) i don't think this was introduced
with the b39 release (but i could be wrong) discovered it while doing a
doc entry ... testing if a non supported format (picked jpeg) would
throw a warning if +ua was specified. if you're willing to give it a go
that might be helpful in seeing if there is any other fall out from
using v8b libjpeg. i was going to give it a day or too and see if anyone
had even attempted ANY beta build using v8b. it seems to me that subject
was briefly mentioned in another thread before ... but darned if i can
find it.

Post a reply to this message

Le 08/08/2010 00:37, Jim Holsenback nous fit lire :

>> Source built of beta38 is against libjpeg62 on my ubuntu 10.4 (amd64);
> 
> are you seeing the problem ... just use +ua +fj

No problem with libjpeg62 , but the resulting image has no alpha.
(ubuntu 10.4 amd64)

> clipka didn't see it on his opensuse 11.2 (64), but chris cason did on
> ubuntu 10.4 (32), and so did i on opensuse 11.2 (32)
> 
>> Any suggesttion where to find 8b ? (a launchpad experiment ? or only on
>> x86 ? somewhere else ?)
> 
> http://www.ijg.org/
> 
> i was going to give it a day or too and see if anyone
> had even attempted ANY beta build using v8b. it seems to me that subject
> was briefly mentioned in another thread before ... but darned if i can
> find it.

I'm going to try to install manually 8b and then re-configure&compile
povray to see. More on that later.

Post a reply to this message

Le 08/08/2010 07:47, Le_Forgeron nous fit lire :

>> i was going to give it a day or too and see if anyone
>> had even attempted ANY beta build using v8b. it seems to me that subject
>> was briefly mentioned in another thread before ... but darned if i can
>> find it.
> 
> I'm going to try to install manually 8b and then re-configure&compile
> povray to see. More on that later.

Done, configure with --with-libjpeg=/usr/local/lib (by default,
configure would fine 8b but the linker option for povray would omit
-L/usr/local/lib, which result in aborted render when used with +fj due
to a mismatch: expecting libjpeg 80, 62 found... so adding the option to
configure really helps)

Render with new version (8b) is ok for +fj +ua (but image remains as
previously: no checkered alpha displayed in my visualisation programs
(imagemagick display & eye of gnome) on ubuntu 10.4 amd64 from source.
(beta38 level). +fn is ok on that aspect of alpha.

It might very well be a 32 bit specific issue for 8b.

P.S.: the data information on image 8b & 62 are identicals, should I had
expected any difference ?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> No problem with libjpeg62 , but the resulting image has no alpha.

  That might be because the JPEG image format does not support an alpha
channel.

-- 
                                                          - Warp

Post a reply to this message

On 08/08/2010 03:16 AM, Le_Forgeron wrote:
> Le 08/08/2010 07:47, Le_Forgeron nous fit lire :
> 
>>> i was going to give it a day or too and see if anyone
>>> had even attempted ANY beta build using v8b. it seems to me that subject
>>> was briefly mentioned in another thread before ... but darned if i can
>>> find it.
>>
>> I'm going to try to install manually 8b and then re-configure&compile
>> povray to see. More on that later.
> 
> Done, configure with --with-libjpeg=/usr/local/lib (by default,
> configure would fine 8b but the linker option for povray would omit
> -L/usr/local/lib, which result in aborted render when used with +fj due
> to a mismatch: expecting libjpeg 80, 62 found... so adding the option to
> configure really helps)

thanks ... good info

> 
> Render with new version (8b) is ok for +fj +ua (but image remains as
> previously: no checkered alpha displayed in my visualisation programs
> (imagemagick display & eye of gnome) on ubuntu 10.4 amd64 from source.
> (beta38 level). +fn is ok on that aspect of alpha.

maybe you missed (or perhaps i didn't communicate clearly) +fj +ua
(since beta38) will generate a warning as jpeg DOESN'T support alpha channel

> 
> It might very well be a 32 bit specific issue for 8b.

I'll try on my system today if I don't get sidetracked.

> 
> P.S.: the data information on image 8b & 62 are identicals, should I had
> expected any difference ?

Nope

Post a reply to this message

Am 08.08.2010 07:47, schrieb Le_Forgeron:

>> are you seeing the problem ... just use +ua +fj
>
> No problem with libjpeg62 , but the resulting image has no alpha.
> (ubuntu 10.4 amd64)

That's the intended result (except that you should also get a warning): 
JPEG does not support alpha channel.

>> clipka didn't see it on his opensuse 11.2 (64), but chris cason did on
>> ubuntu 10.4 (32), and so did i on opensuse 11.2 (32)

Due to the nature of the underlying problem (data alignment, 4 byte vs. 
8 byte), it is pretty likely a 32-bit specific issue.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.08.2010 07:47, schrieb Le_Forgeron:

> >> are you seeing the problem ... just use +ua +fj
> >
> > No problem with libjpeg62 , but the resulting image has no alpha.
> > (ubuntu 10.4 amd64)

> That's the intended result

<nitpicking>

  I suppose you mean that's the *expected* result (the reason being, of
course, that the JPEG image format has no support for an alpha channel).

  "Intended" would imply that POV-Ray deliberately skips writing the alpha
channel to the jpeg file even though it could.

</nitpicking>

-- 
                                                          - Warp

Post a reply to this message