Hi all!
I've got a little issue here: I often make screenshots from games running in NLMSX. Now, the problem is the dimensions of those images are 544*424. That's not a problem, on {emulated}screen 5 it will use pixel doubling. Now, for displaying those shots on a website, I made myself a PHP script. It's about 50 to 60 lines in size, and you'll see the results below (pictures are copyrighted by Umax ):


This is the original version.


This is the image after passing my script.

So far, so good: the script accepts any image format (except BMP, since PHP hasn't a real support for it) and creates the antialiased version on-the-fly. Now, we're finally at the point where I can state my problem:

if I use this script on a "really big" picture (say, 544*424), the execution time of the script is about one minute per picture on my Intel Pentium III! I think that could be done faster: even a Turbo R with NBASIC and vpeek/vpoke actions can do this faster .

For getting the pixel colors:
for each pixel, I use twelve times imagecolorat() on the original image to get an estimated (smoothing) new color for the new image.

For setting the new pixel:
for each pixel to set, I use imagesetpixel(), with the specified color obtained by imagecolorallocate().

Is there anyone around who can give me the solution to this speed issue (except of buying a new wintel brick, for which I don't have money left (hey, I gotta buy an OPL4 someday ))?

Ta in advance

For law and order : in my previous post, I used two static images (instead of generating the anti-aliased on-the-fly), for:

• I don't have GD support at the University (where I stored the images, my own web server isn't 24/7 online)
  
• I try to prevent the loading times of MRC increasing (although MRC is one of the fastest sites around )
  

imho, the anti-aliased picture is less clear than the original

I don't know jack about PHP, but can't you retrieve multiple pixels at once?

I can recommend taking a look at www.imagemagick.org which is a very powerfull set of tools for working with images. It also has PHP support, but I don't have experience in using it in combination with PHP.

Why don't you use BlueMSX with its fancy filters to get nice smooth pics?

Quote:

Why don't you use BlueMSX with its fancy filters to get nice smooth pics?

Hurm.... I just like to use the anti aliasing more broadly. It's not just meant for smoothening screenies, but it can be anything (font smoothening, etc.). Furthermore, blueMSX doesn't run nicely when I've the filters enabled

Quote:

I don't know jack about PHP, but can't you retrieve multiple pixels at once?

Well, that's what I was trying to say: are there better ways (functions) to read pixels, or maybe indeed that imagemagick?

I'll give it a shot.

Quote:

I can recommend taking a look at www.imagemagick.org which is a very powerfull set of tools for working with images. It also has PHP support, but I don't have experience in using it in combination with PHP.

Now I've seen it: I must admit it's quite the powerful toolset... And as well it should be! The package is about 28MB!!
The page claims it has native PHP support but I can't find it anywhere in the API...

[edit]Moreover, it seems like HELL to install it on a windows machine. Well, I'll give it a try, though I don't know how exactly. I've read some FAQs, and somebody said something about Imagemagick version 5.5.7 and PHP Imagick version 0.98. Have a decent read HERE . But I wonder why one would need both packages...[/edit]

maybe you can read a few lines at once and store the pixeldata in arrays?
pixels are probably more often too, so you can reuse them instead of getting them from the image all the time

but as Vincent says, you might be able to use imagemagick, and there are probably other tools which can do what you want.

On the site the php module claims to have some examples in an examples directory.
If you have the basic toolset installed you can also run:

convert -antialias image-in.gif image-out.gif

If you don't get it to work with the libraries you can always do a system to the convert utility and built something around that.

Another result of the script (also copyrighted by Umax ):


The original image.


The anti aliased image. Thus far, this is my most precious one, since it cost PHP/GD about one-and-a-half minute to generate it ...

Quote:

maybe you can read a few lines at once and store the pixeldata in arrays? pixels are probably more often too, so you can reuse them instead of getting them from the image all the time

What do you mean by reusing them, Arjan? By the way, I use .PNG pictures as input, so there isn't any pallette involved. Hence, any pixel can have any color, and the blending color has to be defined with imagecolorallocate(). And you would really like to have arrays with a length of about 512*3 bytes for one line?! (.PNG is truecolor, 24bpp...)

True, the currently used script uses about 1MB of memory for a 640*480*24bpp picture. But I don't think using arrays is a suggestion. AFAIK, GD doesn't have a proper built in anti alias function (which could make use of e.g. DirectX or openGL, depending on the system's configuration).

[still downloading imagemagick... ]

[edit]It seems the IM PHP extension for windows has to be configured manually. Shouldn't be a problem, but I don't know where to start. The *nux script is yet available though... I'll see what options I have.[/edit]

Okay. So far so good. I know now what I use the files for. The ImageMagick 28.1MB package is for the IM system itself, it contains all functions, etc. The php_imagick.dll is a PHP4/PHP5 wrapper for this system, thus enabling PHP to use it.
Well, that *nux script which I spoke of before, was on the generic PHP site. That site provided as well a link to the compiled win32 binaries, so I suppose I don't have to worry. But now:

• What's the difference between "PHP4 binaries for Win32" and "PECL binaries for Win32 (PHP4)"?
  
• Which should I use? You can find both of them (and more!) HERE .
  

Logically, I'd say I'd go for the first one, since I have PHP 4.3.7, but the PECL heading also mentions PHP4...

IMO those images look too blurry after resizing w/ antialiasing... whatever
1. How do you scale your image? Which algo did you use?
2. How is the code for scaling built up? Would you mind posting the main part here? Perhaps there are some optimizations left. Because scaling a whole image taking > 1 min sounds a bit odd...

Quote:

What's the difference between "PHP4 binaries for Win32" and "PECL binaries for Win32 (PHP4)"?

PECL stands for PHP Extension Community Library, those are (precompiled) extensions for the PHP-engine.

Quote:

maybe you can read a few lines at once and store the pixeldata in arrays? pixels are probably more often too, so you can reuse them instead of getting them from the image all the time What do you mean by reusing them, Arjan? By the way, I use .PNG pictures as input, so there isn't any pallette involved. Hence, any pixel can have any color, and the blending color has to be defined with imagecolorallocate().

About PNG: If I'm not mistaken PNG can be used for color indexed images as well, and can store a colorpallet, but you seem to use it in the TrueColor mode

In SDL you can get the colormasks and colorshifts for each color, so that you can extract each color separately. Isn't this possible in PHP and for blending this can also be used
by adding all color masked pixels and then dividing(or shifting) them back in place and mask them again.
Ok that sentence is unclear but here is an example that will hopefully make it clear:

if a pixel value was something like a screen 8 pixel (your 24 bit number)
then each bit would code for a part of a color for instance red colorcompeonent was stored in bits 7-5,Green in bits 4-2 and blue and the final two bits. The byte value is thus coded as
RRRGGGBB
the BlueColorMask (=BCM) woud be 00000011 ,
the RedColorMask (=RCM) would be 11100000 and
the GreenColorMask (=GCM) would be 00011100

if you want to make pixel 1 (=P1) average the value of its four neighbours (P2,P3,P4 and P5) then the new value would be something like
P1=( ( (P2 & BCM) +(P3 & BCM) +(P4 & BCM) +(P5 & BCM) ) /4) &BCM +
( ( (P2 & RCM) +(P3 & RCM) +(P4 & RCM) +(P5 & RCM) ) /4) &RCM +
( ( (P2 & GCM) +(P3 & GCM) +(P4 & GCM) +(P5 & GCM) ) /4) &GCM

Quote:

And you would really like to have arrays with a length of about 512*3 bytes for one line?! (.PNG is truecolor, 24bpp...)

I would assume that looking up each pixel in such array would be way faster then calling the other pixel functions... I would store each line in one array of 512 elements of 24(or 32) bits numbers. And I would store 3 lines at a time ass well to speed things up :-)

It is a trade of, do you want speed or a small memory footprint?

rgds,

David

Edit: This forum has troubles with nested quote tags!