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,image.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.cropX) , \
float(image.cropY) , \
(float(image.cropX)+float(image.cropW)), \
(float(image.cropY)+float(image.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_compressione = Image.BILINEAR

try:
pil =
pil.resize((image.realW,image.realH),filtro_compressione)
except:
traceback.print_exc()


if not pil.mode == 'RGB':
try:

pil = pil.convert('RGB')

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]

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>