Rick's b.log - entry 2020/03/15

Soon Sakura?

Game of Thrones

What is she, twelve?

Image from GoT 1.01, © 2012 HBO

I rather suspect spaced-girl is also going to turn out to be important, and that there's something going on between her and her brother. But already I've pegged him as a bit of a slimeball.

Image from GoT 1.01, © 2012 HBO

No spoilers, please.

Vide greniers

Scaling an image

The hard part, however, is doing it well.

For my Manga software, there are currently three scaling options:

• Don't, display full size and scroll (this is my preferred).
• Use ChangeFSI.
• Use internal scaling.

The internal scaling, on the other hand, is near-instant, but it's rubbish. It steps through copying out every n pixels and just discarding the rest. Here is an example, scaled to 75%:

My first test was to look at the current pixel and the ones to the left and right as well as above and below. This helped to average out errors due to skipped pixels, but has introduced some blurring. Here's an example:

Today's work was to enhance the process. It now counts for eleven pixels, arranged as follows:

What I'll need to do is try to work out how sharpening works, to then be able to enhance the edges of the black and the white, which should hopefully mask the blurring. I did look for some help online, but the resources I find quickly descended into impenetrable maths. :-(

At this time it is just test code. I'm playing around with ideas. That's because the results are still far from ChangeFSI (though perhaps better than the OS rendering, even blurred, dialogue text is more readable than with bits missing). However, the process is extremely memory hungry. 282484 bytes was allocated for the original JPEG. This was then rendered at 1:1 size into a 32bpp TBGR sprite (3,633,080 bytes) and then processed into the destination sprite (also 32bpp TBGR) which was another 2,325,560 bytes.
Or 6,241,124 bytes in total, plus some frankly negligible extra for variables and the pixel array. That's 5.95MiB to scale that image to 75%. Scaling up to 200%? You're looking at 18,444,644 bytes (17.6MiB), though to our benefit the processing completed in 6.34 seconds.
Just for a laugh, I ran the older simpler BASIC algorithm for 200% scaling. It took a mere 137 seconds. Yes, just shy of two and a half minutes. This should probably stand testament to how BASIC is not really suited to tasks where there's a lot of farting around within chunks of memory. It could be sped up by crunching variables, but it'll never compete with C. And, no, one cannot cheat and use the ABC compiler. By default it chokes with array allocations of that size, and if you try to set HEAP=20000000 to give it space, it'll hang in a way that takes the machine down with it.
So, yeah. Either hand crafted assembler or C is the way to go. I know which I'd rather read. ☺
All that aside, it doesn't help with making a better scaling routine. I suppose it would help if I had a clue what meant...

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

David Pilling, 15th March 2020, 21:56

DPScan with the Lanczos filter (selected, heaven knows why, from its general choices). Be an interesting comparison.

Gavin Wraith, 19th March 2020, 11:39

I have a book Selected Papers on Computer Science by Donald E Knuth. Most of it is rather mathematical but chapter 9, Theory and Practice IV, is his keynote address for the 11-th World Computer Congress in 1989, is full of nice pictures, and deals with just the problem of scaling images and pixelization.   By the way, the equation you display means: the array y is the cumulative shift of array x using the array h to weight the shifts.

Gavin Wraith, 19th March 2020, 11:52

My eldest daughter and son in law gave me the box set of G-of-T Christmas before last. I eventually got round to it while I was stricken down with shingles. It is a bit too violent for my taste, but it was interesting to see where the author had got his ideas from. A touch of Michael Moorcock here (dragons), Edmund Gibbon there (Dothraki ~ Scythians). Actually Gibbon's Decline and Fall of the Roman Empire contains a more dizzying tapestry of exotic melodrama than any work of fiction. I would be interested to know how you get on with G of T if you have the patience :-)

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 33514 backwards.
		Your comment