Rick's b.log - 2020/03/15
You are 3.142.198.51, pleased to meet you!
|
Rick's b.log - 2020/03/15 |
| It is the 21st of November 2024 You are 3.142.198.51, pleased to meet you! |
|
mailto: blog -at- heyrick -dot- eu
What is she, twelve?
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.
No spoilers, please.
The hard part, however, is doing it well.
For my Manga software, there are currently three scaling options:
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.
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... ☺
Image from GoT 1.01, © 2012 HBO
Image from GoT 1.01, © 2012 HBOVide 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.
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).
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.
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.
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.
:-(
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...
David Pilling, 15th March 2020, 21:56 Gavin Wraith, 19th March 2020, 11:39
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
| © 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. |