JPEGReadWriter2Plugin
Locked
JPEGReadWriter2Plugin
 
|
Re: JPEGReadWriter2Plugin
|
|
JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)
|
|
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)
Re: JPEGReadWriter2Plugin
|
|
Re: JPEGReadWriter2Plugin
|
|
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 =========================================================================== |
Re: JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)
|
|
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 =========================================================================== |
Re: JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)
|
|
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 - > >>> |
Re: JPEG broken in all 4.x VMs (was Re: [Vm-dev] JPEGReadWriter2Plugin)
|
|
| Free forum by Nabble | Edit this page |