Legacy ImageMagick Discussions Archive

Hello, Greetings,
My name is Ryan. I'm a new ImageMagick user and very impressive about how ImageMagick work.

In ImageMagick, there are many image scaling filters that are already implemented. But I hope ImageMagick developers will add some filter called pixel-art scalling algorithm, such as SuperEagle, Super2xSaI, Hqx, xBR, etc that was already used in many video game emulators. The purpose of these filters are not too different from another scaling filters, but these filters are specially designed for magnifying pixel art image without visually loss of qualities.
For example is below Mario images:

1=>; 2=>; 3=>;
4=>; 5=>; 6=>
Notes:
Original (Unique Color: 4, Size: 380 bytes)
1. Nearest Neighbour (Unique Color: 4, Size: 950 bytes)
2. Lanczos (Unique Color: 15278, Size: 38.69 kilobytes)
3. Genuine Fractals (Unique Color: 17150, Size: 41.67 kilobytes)
4. Portrace (Inkscape) (Unique Color: 1274, Size: 12.76 kilobytes)
5. Hqx (Unique Color: 63, Size: 4.02 kilobytes)
6. xBR (NoBlend) (Unique Color: 4, Size: 2.16 kilobytes)

As you can see, when using pixel art scaling algorithm such as Hqx and xBR the image can be magnified eight times while maintaining it's quality. If you want to exam more deeply, there is almost no additional color in this image when using this pixel scaling algorithm while in Lanczos or even the patented Genuine Fractals there are too many additional colors even though the quality is still inferior. I don't want to say that Lanczos or another filter is worse than Pixel Art filter, but it just doesn't suitable for pixel art.

The limitation of these pixel art algorithm are they only capable for magnifying picture in predefined size, such as 2x, 3x, or 4x and cannot be used to shrink images. The solution when users want to resize their picture with custom size is to magnify the picture with the pixel art scaling algorithms first, then shrink it with lanczos or another filter to the desired size. For example, a pixel art image with dimension 2x2 pixel want to be scaled until 7x7 pixel (almost 4 times of its original size). So the solution is by using - let's say - Hq4x filter to magnify it until 8x8 pixel, then shrink it with lanczos filter to 7x7 pixel. The image will looks perfectly with this method.

The implementation of these pixel art scaling algorithms can be found in following websites:
1. Super Eagle and Super2xSaI : Main site;
2. Hqnx : Main site , Source Code or Source Code with support transparency ;
3. xBR : Main Site, and it's source code;
4. Almost all pixel art scaling algorithm : Main site, Source code collections. The author of this site (Hawkynt) is very gracious as he always reply my private message regarding his software.

My suggestion is, please visit the main site first then see their sample library at the number four (http://code.google.com/p/2dimagefilter/), because it was the only project that I know which tried to unifying and even improving these algorithm outside emulator project (unfortunately it was GPL and implemented in C Sharp). This site also provide stand alone application, so we can see how the algorithm works.

As the conclusion, I want to said that I and maybe another users will be more than happy if ImageMagick developers want to implement these pixel art scaling algorithms in ImageMagick as these algorithms have many potential to be used outside emulator program to be applicated in real image manipulation implementations.

If there are some questions from developer regarding this algorithm, feel free to ask and I will try my best to provide the informations.

Best regards,

Ryan Bram.

see also http://scale2x.sourceforge.net/index.html

IM is open source and all it needs is someone willing to spend time doing the work.
I'd love to have this myself

I'd also like to see some better 'limited color pallete', dithers implemented. Which is similar but related.

I have just no time.


PS: duplicate topic in Developers was deleted, and replace with a link to this topic.

For now, we implement the Scale2X algorithm available in ImageMagick 6.8.4-10 Beta by sometime tomorrow with the -magnify option.

magick wrote:For now, we implement the Scale2X algorithm available in ImageMagick 6.8.4-10 Beta by sometime tomorrow with the -magnify option.

FYI, for future consideration, there are scale3x and scale4x versions at the same link http://scale2x.sourceforge.net/index.html

Scale4x is is the same as '-magnify -magnify'. Scale3x can be achieved with '-magnify -magnify -resize 75%'. We might support additional pixel art scaling algorithms in the future with a new option, perhaps -pixel-art-scale type. In the mean-time we need to finish up our work on IMv7 -channel-fx and read / write masks.

magick wrote:... We might support additional pixel art scaling algorithms in the future with a new option, perhaps -pixel-art-scale type. In the mean-time we need to finish up our work on IMv7 -channel-fx and read / write masks.

Thanks for hearing my request. I am more than happy to hear this news. Just for information, instead of visiting website for every specific pixel art scaling algorithm, it is better to visiting 2DImageFilter website at http://code.google.com/p/2dimagefilter/ as reference, because it was the only project that I know which collecting and sometimes improving almost all open source pixel art scaling algorithm that was available. It is in C# and GPL licensed, but still worth to become reference just don't forget to credits Hawkynt the author of this project.

About new -pixel-art-scale type option that you mentioned, I think it is better to use -magnify [magnification] [filter] option as bassically every pixel art works in same way by magnifying image 2 times, 3 times, or 4 times. So the option can be something like this example magick -magnify 2x hq image_in.png image_out.png for 2 times magnification by using Hq filter, or magick -magnify 4x xbr image_in.png image_out.png for 4 times magnification by using xBR filter.

Noted: Not every pixel art scaling algorithms have 3x and 4x magnification feature. Most of them only support 2x magnification. In most case, performing 2x magnification two times is different from performing 4x magnification one times. See http://code.google.com/p/2dimagefilter/ ... ageScaling for more information.

Best regards,

Ryan Bram.

RyanBram wrote:About new -pixel-art-scale type option that you mentioned, I think it is better to use -magnify [magnification] [filter] option as bassically every pixel art works in same way by magnifying image 2 times, 3 times, or 4 times. So the option can be something like this example magick -magnify 2x hq image_in.png image_out.png for 2 times magnification by using Hq filter, or magick -magnify 4x xbr image_in.png image_out.png for 4 times magnification by using xBR filter.

We try not to modify the syntax of existing options like -magnify

If we were going to add a general option for pixel-art scaling algorithms as you suggested it would likely be a new option for backward compatibility reasons. perhaps -pixel-scale

But as with anything someone needs to write the core library function or API's and CLI to hook into.

The documentation on the options page for -magnify seems inconsistent. It shows an argument (factor) but ignores it and always does 2x no matter what factor one gives.

From the options page:

"-magnify factor

double the size of the image with pixel art scaling"

That would be a mistake. I am surprised no one has picked up on it before.

Strangely it does not object the factor, but seems to ignore it. It is as if -magnify was originally built to apply a factor, but then just does 2x.

How long has -magnify been around? Was it just created for pixel-art scaling recently or has it been around for a long time?

magnify from from the very first IM versions (long time before even version 5, which was when I started the original examples)
It has mostly been just a wrapper around a -resize 200%

Internally there is also a -minimize (shrink by 50%) but that has never been available on the CLI.

Really until this pixel art addition it was a rather useless thing. I would have prefered to make it a separate operation and depreciate -magnify completely. At least then you could include a 'method' to also for some of the other pixel-art algorithms to be added in the future. x3 and x4 could have been added as special aliases calling on the x2 function.

PS: x3 I don't think could use -resize as that would add colors. it is probably a -scale 75% rather than a resize.

Just curious, but if it has been around for while, then how is it different from -scale and how does one know that it really replicates the pixel-art scale2x algorithm, which I know is built with many special cases of the neighbors. Perhaps Magick rewrote -magnify?

Based on Magick statement in previous post, I think he rewrote -magnify option:

magick wrote:For now, we implement the Scale2X algorithm available in ImageMagick 6.8.4-10 Beta by sometime tomorrow with the -magnify option.

And because originally -magnify is from the very first IM versions, but just a wrapper around a -resize 200% and a rather useless thing, modifying its sintax seems has no impact for most user case and depreciate it is not the solution for backward compatibility reasons (because if it is depreciated, that means there is no option for it at all).

Instead of depreciate it, I think making -magnify option for something more useful than before is better than depreciate it. -pixel-scale option seems too long and more complicated than more simple -magnify option. -pixel-scale is too specific for pixel art algorithm method, while -magnify is more open for another method as long as they are scaling by factor.

After all it is up to the developer what option they will prefer, because for me as a user the more important is have this pixel algorithm be implemented in ImageMagick.

Best regards,

RyanBram

Okay, but it will need some 'method' option added, to allow for other scaling types.

Perhaps even a +magnify {method} {arg} type addition for the methods that perhaps does need some argument (I don't know of any, but I don't know all the methods either).


But if we are going to add 'method' NOW is the time to do it, even if there is currently only one option, (and two psuedo-options)