JPEGReadWriter2Plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

JPEGReadWriter2Plugin

Bert Freudenberg

Hi,

have there been changes lately to the jpeg plugin?

On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.

Here's my little test:

(JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex

On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: JPEGReadWriter2Plugin

David T. Lewis
 
I think that John made some changes that would have entered the VMMaker updates
as of VMMaker-JMM.166 (March 2010). In addition, three methods are different
between the Cog branch and the main branch:

        #primJPEGReadHeader:fromByteArray:errorMgr:
        #primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr:
        #primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:

Looking at the method time stamps I'm guessing that there was some fix
made by Andreas in 2006 that is present in the Cog code base but not
the main VMMaker. My guess would be that we should be using the Cog
versions, and merging John's March 2010 updates into this.

I just happen to be part way through converting the plugins to use
pragmas to match Cog. The updates for primitives should be done in
a couple of days, after which it will be easier to spot differences
like this.

Dave


On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:

>
> Hi,
>
> have there been changes lately to the jpeg plugin?
>
> On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
>
> Here's my little test:
>
> (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
>
> On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.
>
> - Bert -
>
Reply | Threaded
Open this post in threaded view
|

JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)

Bert Freudenberg
 
So I tracked it down to Mac version 4.2.3 that is broken, whereas 4.2.2 was still fine.

The Windows 4.1.1 also has the broken plugin, 3.11 was still fine.

Same for Linux 4.0.3, it's broken.

According to John's release notes he switched to VMMaker 160 in 4.2.3, and also noted

        **** This VM includes some features not in VMMaker yet *****
        (f) JPEGReaderPlugin, work to make 64bit clean

So maybe this is where the problem comes from.

The latest 4.x VM (4.2.5) still has the bug. I'm attaching a jpeg exhibiting the problem. It "wraps around" when imported, you can see the former right edge on the left. The code pasted below also shows the problem.

Would be great if we could still fix this, currently Etoys ships with the broken VM ...

- Bert -

On 27.09.2010, at 11:45, David T. Lewis wrote:

>
> I think that John made some changes that would have entered the VMMaker updates
> as of VMMaker-JMM.166 (March 2010). In addition, three methods are different
> between the Cog branch and the main branch:
>
> #primJPEGReadHeader:fromByteArray:errorMgr:
> #primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr:
> #primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:
>
> Looking at the method time stamps I'm guessing that there was some fix
> made by Andreas in 2006 that is present in the Cog code base but not
> the main VMMaker. My guess would be that we should be using the Cog
> versions, and merging John's March 2010 updates into this.
>
> I just happen to be part way through converting the plugins to use
> pragmas to match Cog. The updates for primitives should be done in
> a couple of days, after which it will be easier to spot differences
> like this.
>
> Dave
>
>
> On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:
>>
>> Hi,
>>
>> have there been changes lately to the jpeg plugin?
>>
>> On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
>>
>> Here's my little test:
>>
>> (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
>>
>> On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.
>>
>> - Bert -
>>


gradient.jpg (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JPEGReadWriter2Plugin

David T. Lewis
In reply to this post by Bert Freudenberg
 
On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:

>
> Hi,
>
> have there been changes lately to the jpeg plugin?
>
> On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
>
> Here's my little test:
>
> (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
>
> On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.

Bert,

I adopted the Cog version of the plugin as of VMMaker-dtl.191, so the
the two branches are identical now and problem will be gone from future
versions of the VM.

John, can you please check these two methods:
  JPEGReaderWriter2Plugin>>primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr:
  JPEGReaderWriter2Plugin>>primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:

By adopting the Cog version, I lost some changes that you made to these
two methods earlier this year. However, I suspect that the parameter
type declarations that had been added in the oscog version (but missing from
vmmaker trunk) may have addressed the same issues so possibly no additional
updates are required.

Thanks,
Dave

Reply | Threaded
Open this post in threaded view
|

Re: JPEGReadWriter2Plugin

johnmci
 
Ok, puzzled trying to figure this out, chatted with Bert.

4.2.2 is good,
4.2.4b1 bad
4.2.5b1 bad
5.7b1 bad
5.8b10 is good


Now the code in the past read.

        formBits :=self cCoerce: (interpreterProxy fetchPointer: 0 ofObject: form)  to: 'unsigned *'.
        formBitsAsInt := interpreterProxy fetchPointer: 0 ofObject: form.


This failed on a 64bit system because formbits was not a 64 bit address, rather it was the 32bit oops offset.
So I changed it to say fetchPointer: 0 was the oops, and then we had to do the firstIndexableField: to get the bits...

        formBitsOops := interpreterProxy fetchPointer: 0 ofObject: form.

        formBits := interpreterProxy firstIndexableField: formBitsOops.

mmm the 5.8b10 is using the Cog code which doesn't have the change.
So what's the fix for the 64bit crash then?
If someone else can do a build and test with, that would be helpful.  

Bert supplied a small jpeg (attached) which is helpful for testing.

On 2010-10-08, at 1:12 PM, David T. Lewis wrote:

> On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:
>>
>> Hi,
>>
>> have there been changes lately to the jpeg plugin?
>>
>> On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
>>
>> Here's my little test:
>>
>> (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
>>
>> On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.
>
> Bert,
>
> I adopted the Cog version of the plugin as of VMMaker-dtl.191, so the
> the two branches are identical now and problem will be gone from future
> versions of the VM.
>
> John, can you please check these two methods:
>  JPEGReaderWriter2Plugin>>primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr:
>  JPEGReaderWriter2Plugin>>primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:
>
> By adopting the Cog version, I lost some changes that you made to these
> two methods earlier this year. However, I suspect that the parameter
> type declarations that had been added in the oscog version (but missing from
> vmmaker trunk) may have addressed the same issues so possibly no additional
> updates are required.
>
> Thanks,
> Dave
>
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================






gradient.jpg (5K) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)

johnmci
In reply to this post by Bert Freudenberg
 
Ah, ok I see

for(i = 0, j = 1;

I think the jpeg embedded C code is then offsetting by j = 1  to ensure it skips the first header word when we did the
formBits :=self cCoerce: (interpreterProxy fetchPointer: 0 ofObject: form)  to: 'unsigned *'.

however the  
formBits := interpreterProxy firstIndexableField: formBitsOops.
skips over the header word for the oops and the embedded C code then does
formPix = formBits [ ((pcinfo->next_scanline) * formWidth) + j ];

thus offsetting from (1)  versus the required (0).


So can someone take the 64bit changes and alter the

for(i = 0, j = 1;

in primJPEGReadImage: &  primJPEGWriteImage:

and see what happens?


On 2010-10-08, at 12:12 PM, Bert Freudenberg wrote:

> So I tracked it down to Mac version 4.2.3 that is broken, whereas 4.2.2 was still fine.
>
> The Windows 4.1.1 also has the broken plugin, 3.11 was still fine.
>
> Same for Linux 4.0.3, it's broken.
>
> According to John's release notes he switched to VMMaker 160 in 4.2.3, and also noted
>
> **** This VM includes some features not in VMMaker yet *****
> (f) JPEGReaderPlugin, work to make 64bit clean
>
> So maybe this is where the problem comes from.
>
> The latest 4.x VM (4.2.5) still has the bug. I'm attaching a jpeg exhibiting the problem. It "wraps around" when imported, you can see the former right edge on the left. The code pasted below also shows the problem.
>
> Would be great if we could still fix this, currently Etoys ships with the broken VM ...
>
> - Bert -
>
> On 27.09.2010, at 11:45, David T. Lewis wrote:
>
>>
>> I think that John made some changes that would have entered the VMMaker updates
>> as of VMMaker-JMM.166 (March 2010). In addition, three methods are different
>> between the Cog branch and the main branch:
>>
>> #primJPEGReadHeader:fromByteArray:errorMgr:
>> #primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr:
>> #primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:
>>
>> Looking at the method time stamps I'm guessing that there was some fix
>> made by Andreas in 2006 that is present in the Cog code base but not
>> the main VMMaker. My guess would be that we should be using the Cog
>> versions, and merging John's March 2010 updates into this.
>>
>> I just happen to be part way through converting the plugins to use
>> pragmas to match Cog. The updates for primitives should be done in
>> a couple of days, after which it will be easier to spot differences
>> like this.
>>
>> Dave
>>
>>
>> On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:
>>>
>>> Hi,
>>>
>>> have there been changes lately to the jpeg plugin?
>>>
>>> On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
>>>
>>> Here's my little test:
>>>
>>> (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
>>>
>>> On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.
>>>
>>> - Bert -
>>>
>
> <gradient.jpg>
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)

David T. Lewis
 
John,
Bravo, that was it exactly. I have re-merged your 64-bit updates and added
the j = 0 fix to the read and write primitives. All seems well now when
compiled in either 32-bit or 64-bit mode.

Eliot,
Changes attached for inclusion in oscog. Two methods are affected.

Bert,
This should make things healthy again for EToys after the next VM build.

Dave

On Fri, Oct 08, 2010 at 02:42:12PM -0700, John M McIntosh wrote:

>  
> Ah, ok I see
>
> for(i = 0, j = 1;
>
> I think the jpeg embedded C code is then offsetting by j = 1  to ensure it skips the first header word when we did the
> formBits :=self cCoerce: (interpreterProxy fetchPointer: 0 ofObject: form)  to: 'unsigned *'.
>
> however the  
> formBits := interpreterProxy firstIndexableField: formBitsOops.
> skips over the header word for the oops and the embedded C code then does
> formPix = formBits [ ((pcinfo->next_scanline) * formWidth) + j ];
>
> thus offsetting from (1)  versus the required (0).
>
>
> So can someone take the 64bit changes and alter the
>
> for(i = 0, j = 1;
>
> in primJPEGReadImage: &  primJPEGWriteImage:
>
> and see what happens?
>
>
> On 2010-10-08, at 12:12 PM, Bert Freudenberg wrote:
>
> > So I tracked it down to Mac version 4.2.3 that is broken, whereas 4.2.2 was still fine.
> >
> > The Windows 4.1.1 also has the broken plugin, 3.11 was still fine.
> >
> > Same for Linux 4.0.3, it's broken.
> >
> > According to John's release notes he switched to VMMaker 160 in 4.2.3, and also noted
> >
> > **** This VM includes some features not in VMMaker yet *****
> > (f) JPEGReaderPlugin, work to make 64bit clean
> >
> > So maybe this is where the problem comes from.
> >
> > The latest 4.x VM (4.2.5) still has the bug. I'm attaching a jpeg exhibiting the problem. It "wraps around" when imported, you can see the former right edge on the left. The code pasted below also shows the problem.
> >
> > Would be great if we could still fix this, currently Etoys ships with the broken VM ...
> >
> > - Bert -
> >
> > On 27.09.2010, at 11:45, David T. Lewis wrote:
> >
> >>
> >> I think that John made some changes that would have entered the VMMaker updates
> >> as of VMMaker-JMM.166 (March 2010). In addition, three methods are different
> >> between the Cog branch and the main branch:
> >>
> >> #primJPEGReadHeader:fromByteArray:errorMgr:
> >> #primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr:
> >> #primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:
> >>
> >> Looking at the method time stamps I'm guessing that there was some fix
> >> made by Andreas in 2006 that is present in the Cog code base but not
> >> the main VMMaker. My guess would be that we should be using the Cog
> >> versions, and merging John's March 2010 updates into this.
> >>
> >> I just happen to be part way through converting the plugins to use
> >> pragmas to match Cog. The updates for primitives should be done in
> >> a couple of days, after which it will be easier to spot differences
> >> like this.
> >>
> >> Dave
> >>
> >>
> >> On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:
> >>>
> >>> Hi,
> >>>
> >>> have there been changes lately to the jpeg plugin?
> >>>
> >>> On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
> >>>
> >>> Here's my little test:
> >>>
> >>> (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
> >>>
> >>> On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.
> >>>
> >>> - Bert -
> >>>


JPEGReaderWriter2PatchWithTests-dtl.1.cs.gz (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)

Bert Freudenberg

Excellent, thank you! :)

- Bert -

On 09.10.2010, at 11:37, David T. Lewis wrote:

> John,
> Bravo, that was it exactly. I have re-merged your 64-bit updates and added
> the j = 0 fix to the read and write primitives. All seems well now when
> compiled in either 32-bit or 64-bit mode.
>
> Eliot,
> Changes attached for inclusion in oscog. Two methods are affected.
>
> Bert,
> This should make things healthy again for EToys after the next VM build.
>
> Dave
>
> On Fri, Oct 08, 2010 at 02:42:12PM -0700, John M McIntosh wrote:
>>
>> Ah, ok I see
>>
>> for(i = 0, j = 1;
>>
>> I think the jpeg embedded C code is then offsetting by j = 1  to ensure it skips the first header word when we did the
>> formBits :=self cCoerce: (interpreterProxy fetchPointer: 0 ofObject: form)  to: 'unsigned *'.
>>
>> however the  
>> formBits := interpreterProxy firstIndexableField: formBitsOops.
>> skips over the header word for the oops and the embedded C code then does
>> formPix = formBits [ ((pcinfo->next_scanline) * formWidth) + j ];
>>
>> thus offsetting from (1)  versus the required (0).
>>
>>
>> So can someone take the 64bit changes and alter the
>>
>> for(i = 0, j = 1;
>>
>> in primJPEGReadImage: &  primJPEGWriteImage:
>>
>> and see what happens?
>>
>>
>> On 2010-10-08, at 12:12 PM, Bert Freudenberg wrote:
>>
>>> So I tracked it down to Mac version 4.2.3 that is broken, whereas 4.2.2 was still fine.
>>>
>>> The Windows 4.1.1 also has the broken plugin, 3.11 was still fine.
>>>
>>> Same for Linux 4.0.3, it's broken.
>>>
>>> According to John's release notes he switched to VMMaker 160 in 4.2.3, and also noted
>>>
>>> **** This VM includes some features not in VMMaker yet *****
>>> (f) JPEGReaderPlugin, work to make 64bit clean
>>>
>>> So maybe this is where the problem comes from.
>>>
>>> The latest 4.x VM (4.2.5) still has the bug. I'm attaching a jpeg exhibiting the problem. It "wraps around" when imported, you can see the former right edge on the left. The code pasted below also shows the problem.
>>>
>>> Would be great if we could still fix this, currently Etoys ships with the broken VM ...
>>>
>>> - Bert -
>>>
>>> On 27.09.2010, at 11:45, David T. Lewis wrote:
>>>
>>>>
>>>> I think that John made some changes that would have entered the VMMaker updates
>>>> as of VMMaker-JMM.166 (March 2010). In addition, three methods are different
>>>> between the Cog branch and the main branch:
>>>>
>>>> #primJPEGReadHeader:fromByteArray:errorMgr:
>>>> #primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr:
>>>> #primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:
>>>>
>>>> Looking at the method time stamps I'm guessing that there was some fix
>>>> made by Andreas in 2006 that is present in the Cog code base but not
>>>> the main VMMaker. My guess would be that we should be using the Cog
>>>> versions, and merging John's March 2010 updates into this.
>>>>
>>>> I just happen to be part way through converting the plugins to use
>>>> pragmas to match Cog. The updates for primitives should be done in
>>>> a couple of days, after which it will be easier to spot differences
>>>> like this.
>>>>
>>>> Dave
>>>>
>>>>
>>>> On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> have there been changes lately to the jpeg plugin?
>>>>>
>>>>> On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
>>>>>
>>>>> Here's my little test:
>>>>>
>>>>> (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
>>>>>
>>>>> On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.
>>>>>
>>>>> - Bert -
>>>>>
>
> <JPEGReaderWriter2PatchWithTests-dtl.1.cs.gz>