[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Re: scale



Not using colorkey at all. Just changed ".scale" to ".smoothscale". I'll attach a couple small images later.

Charlie Nolan wrote:
No, you want to avoid a colorkey when scaling.  Without seeing the
artifacts, it's hard to say, but I suspect that your problem is that
you're currently using a colorkey, but need to switch to alpha for scaling.

-FM

Chris wrote:
Can't believe I missed that with how much I have been reading the pygame
documentation.

Thank you.

When I tried it, smoothscale created several single pixel artifacts
around the edges of my image.  Is that a result of transparency scaling?

Should I give it a solid background, transform then colorkey the
background to transparent afterwards?

I'll try that tomorrow.

René Dudfield wrote:
hi,

have you tried transform.smoothscale?

cheers,

On Tue, Jun 17, 2008 at 12:19 PM, Chris <c4@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
The gimp uses an image resize function that is perfect.  I use it in PHP
with my online shop images. Going from larger to smaller, of course. I had
hoped that transform would operate the same way but the image
degradation
is... noticeable to severe.

Excuse me if I missed the discussion target.

René Dudfield wrote:
Hello,

a few notes below.


On Tue, Jun 17, 2008 at 10:49 AM, Nirav Patel <olpc@xxxxxxxxxxxxxx>
wrote:
As part of my project to add computer vision stuff to pygame, I'd like
to write a function or functions that do the following.

For vision purposes, it would be very useful to have thresholding with
both upper and lower boundaries, returning both the number of pixels
within the threshold and the centroid of those pixels.  This is a
trivial addition to the existing transform.threshold() function, but
is it acceptable to modify the input options and the output of an
existing function?  Would it break compatibility with existing pygame
games?  Would it make sense to have a second function so similar to an
existing one?

You could modify the existing function if the old functionality stays
the same.  Probably by adding another default argument.  We try not to
break existing functionality.

I think the current one can use just one distance from the color.  So
it's both a lower, and upper threshold.  I'm just wondering if it
could be used already to do what you want?

The other function, which is also similar (and could even just be an
option in thresholding), is thresholding with connected component
detection.  This would involve supplying an upper and lower threshold,
a Surface, and optionally a mask.  The function would find the largest
blob of pixels in the Surface within the threshold, make a mask of
those pixels if desired, and return the centroid and number of pixels
in the blob.

Currently this can sort of be done by making a mask from the
thresholded image.  Mask has a get_bounding_rect() function.  Doing
the get_bounding_rect on a mask turns out to be fast because you
process way less data -- as mask is 1 bit per pixel.  Then you can
sort the bounding rects on size to find the largest one.

I'm not sure if that will be suitable for your task though, but I
think maybe you could do things this way.


It could also be useful to have multiple connected component
detection, for "multi-touch" without having to use different colored
objects (or if you are using IR LEDs like the Wii does), but I'm not
sure how to handle that in a single pass of the array.  Actually, I'm
not really sure how I'm going to handle both detection and creating a
mask in a single pass either.  It may be necessary to store the
starting pixel, ending pixel, and size of each connected component on
the first pass, keeping track of which was the largest yet, and then
have a shorter second pass to create the mask that only starts at the
starting pixel and ends at the ending pixel.

Multiple areas can be found like above with Mask.get_bounding_rect().

Doing everything in one pass is hard... but if you reduce the data
down -- by using a mask -- then the second pass can act on 32x less
data.

eg, a 1024x1024 image:
(1024 * 1024 * 4) / 32.
131072.0

So that is 4MB on the first pass down to 131KB of data to process on
the second pass.



Any comments, reality checks, questions, or suggestions would be
greatly appreciated.

Nirav