mailto: blog -at- heyrick -dot- eu

Soon Sakura?

Looking outside, I noticed that the late blooming Sakura looks as if it might beat pretty much everything else this year. Last year, the flowers were impressive a month from now, on the 15th of April.

 

Game of Thrones

A few weeks ago, somebody expressed surprise that I've never seen Game of Thrones and they said I really should. It's not on Prime Video or Netflix, but luckily I was able to get it from the library.
So it seems a bit sword and sorcery, which is okay, with a cast of dozens. I think it'll take a bit of time to get into things. There are five discs for the first season, with two episodes per disc. So ten episodes. And eight seasons. And if we consider each episode is a little under an hour, that'll be bout 74 hours. To help put this into context, I work 35 hours a week... ☺

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

I went to the vide grenier in Châteaubriant before The Dreaded Virus took hold. Looks like it might be the last one for a while...

 

Scaling an image

It isn't hard to scale an image. For instance, one can reduce an image to half it's original size by simply copying out every other pixel on each axis.

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.
ChangeFSI looks good, but it takes several seconds per image and it requires ChangeFSI to be visible to the system (this is normal but not guaranteed).

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%:

If you look at the framework of the balcony she is standing on, specifically the bar under her arms and the stairway handrail to the left, you can see the scaling has actually left missing bits. I'm not you can imagine how bad that looks with dialogue.

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:

The above code, being written in BASIC, processed the image (to 75%) in 21.34 seconds (on an ARMv7 Pi2). It was proof of concept, not something that can reasonably be used.

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

The number is the weighting, so the central pixel (the current pixel) carries a weight of '4'. The left/right/top/bottom are weighted two, and the fill ins are weighted one. This has the advantange of helping to diffuse the missing parts by blending in what would be missing pixels with the pixels that are being copied. Unfortunately the words "diffuse" and "blend" have another synonym - "blur". Here is an example and you can see that the railings do look better. Written in C, the process completes in 1.1 seconds.

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 01026 backwards.
Your comment
French flagSpanish flagJapanese flag
Calendar
«   March 2020   »
MonTueWedThuFriSatSun
      
23568
9101114
171921
27
31     

(Felicity? Marte? Find out!)

Last 5 entries

List all b.log entries

Return to the site index

Geekery

Search

Search Rick's b.log!

PS: Don't try to be clever.
It's a simple substring match.

Etc...

Last read at 03:37 on 2024/04/19.

QR code


Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0

 

© 2020 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.

 

Have you noticed the watermarks on pictures?
Next entry - 2020/03/16
Return to top of page