PIL problem with biprocessor hardware

[mardif]

Hi guys,

I've a problem, but very big!
So, i have a python/PIL application that manipulate images ( rotate,
crop, save, etc etc ).
If this application work on a PC mono-processor, I don't have any
problems.
If this application work instead on a PC bi-processor, the process
elaborates an image "corrupted" :

I mean "corrupted" because:

If I open this image with any image-viewer, it will show the image
with background color on top blue, and on bottom green. Sometimes it
can happen that somethings inside was wrong designed.

If i open this image instead with GIMP, this message will shown:

Corrupt JPEG data: 36 ( this value is not ever equal ) extraneous bytes
before marker 0xd9
EXIF data will be ignored.

This error don't has a procedure that will produce it. It's random.

I've executed this application in a PC mono-processor, and it seems all
ok ( 100% ), instead on a PC bi-processor sometimes don't work ( 90% ?
).

Thx very much

[danmcleran]

> If this application work on a PC mono-processor, I don't have any

problems.
If this application work instead on a PC bi-processor, the process
elaborates an image "corrupted" :

Sounds like you've got some thread synch issue. On a mono-processor
system, your threads are running serially, but on an SMP system (i.e.
bi-processor) your threads are truly running in parellel thru the CPU.
I'd take a good look at any data you're locking currently, or should be
locking. It's hard to make more concrete recommendations without
knowing exactly what the code looks like.

[mardif]

OK, this is the code:

"""
image is the object instance of Image class which contains all
informations
"""
pil = Image.open( os.path.join( image.path,imag e.name ) )

if image.rotation_ angle != 2:
try:
pil = pil.rotate( rotation_levels[image.rotation_ angle]
)
except:
traceback.print _exc()
result = False
if ( image.cropped ):

box = [ float(image.cro pX) , \
float(image.cro pY) , \
(float(image.cr opX)+float(imag e.cropW)), \
(float(image.cr opY)+float(imag e.cropH))
]

try:
pil = pil.crop( box )
except:
traceback.print _exc()

if pil.size[0] < pil.size[1]:
try:
pil = pil.rotate( 90 )
except:
traceback.print _exc()

filtro_compress ione = Image.BILINEAR

try:
pil =
pil.resize((ima ge.realW,image. realH),filtro_c ompressione)
except:
traceback.print _exc()
if not pil.mode == 'RGB':
try:

pil = pil.convert('RG B')

except:

traceback.print _exc()

try:

pil.save( path, format="JPEG", quality=80 )
except Exception,e:
traceback.print _exc()

I think this is very normal.
It's NOT normal that don't work well on PC SMP processor...

not?

[danmcleran]

I wonder if there are other threads accessing image? Maybe image isn't
fully initialized by some other thread before this code accesses it?

It's hard to say what's going wrong. I don't believe that an SMP system
would have any bearing on an application unless it uses multiple
threads of execution. I wonder if

[danmcleran]

oops. lost my train of thought. I was gonna say, I wonder if some of
these image manipulation routines are using multiple threads?

[Fredrik Lundh]

da********@yaho o.com wrote:

oops. lost my train of thought. I was gonna say, I wonder if some of
these image manipulation routines are using multiple threads?

PIL doesn't use threading by itself, and I know of quite a few PIL-based
systems running on multi-processor hardware (not to mention multi-core
and hyper-threading systems).

if the posted snippet is all there is, I'd blame it on the hardware ;-)

</F>