Ah... end of the week. Final-fucking-ly. The week has been long, for a variety of reasons that I will not go into, because it is (1) boring for most people; and (2) involves too any ``other people'' that it really isn't about me any more.
Instead, let's talk about some accumulated things that I had done.
Not too long ago, I learnt about some new
HTTP headers needed for security, along with
an online tool to test them. The idea behind these ``security headers'' is to provide server-centric instructions to the client browser to ``know'' what kinds of content (static or executable) are to be considered legitimate from the perspective of the server that the client is connecting to. This is the missing information link that is needed to prevent the class of exploits that starts with a man-in-the-middle (MITM) attack, which includes drive-by malware downloads, page hijacking to siphon off user input (and therefore information). It is an explicit white-list to the client on what the server knows as resources/actions that it needs that the client should pay attention to, ignoring/stopping any that do not follow that whitelist.
Intrigued, I tried setting it up on my
personal domain. The HTTP headers were created in a no-brainer way, but the behaviours that they created... broke lots of things.
For starters, there is now a
strict segregation of the presentation layer (i.e. the HTML and CSS stuff) from the controller layer (i.e. any executable code, often in the form of JavaScript). One can no longer use the
on* family of attributes within the HTML tags to create callbacks for specific actions (notably in my case, the
onClick,
onChange, and
onLoad actions).
That broke enough stuff that I had to rewrite my website to do that, and boy did that take a while.
Also, even in the presentation layer, there was a strict enforcement of splitting out the semi-structured layer from the styling layer (i.e. HTML files cannot have embedded CSS styles, no matter how small, nor when they were inserted (like in original HTML file, or as part of some DOM-tree shenanigans)). It wasn't difficult; it was more annoying than anything else.
But after all that effort, my website works well now, and you can
verify the Security Headers with the link.
The eagle-eyed will notice that the new pages no longer have referrals to the CSS/HTML validation links. That's because one of the security headers basically blocks the passing of the forwarding page's URL to the forwarded to URL, which made such validation links impossible to operate in the client browser.
My chief constraint is that I have very little control over how to configure the website server program, so I had to do what I had to do just to keep the 'net gatekeepers happy. Like how I ended up creating a damn
sitemap, and having to do up an entire toolchain that minifies and GZips individual pages, all because the damn gatekeeprs of the 'net these days state that all websites are
clearly meant for machine-to-machine communication, so the sources of the pages themselves should be mangled for efficient machine-to-machine communication, as opposed to something that is human readable (and therefore learnable from).
Man, the ways of the 'net have changed drastically over the past 25 years.
------
I have the
ESV Study Bible in hard copy for a few years now, and have wanted to grind through it slowly but surely as part of my own education on my faith. It's not my first time through the Bible (
according to my own loose tracking, I've covered the Bible end-to-end two full times by now). But one of the biggest problems was that the book was an inch thick, and has terrible portability, despite it being the ``personal edition'' and having the general dimensions (not counting the thickness) of an A5 sheet of paper.
An e-book version would work wonders on the portability front.
Crossway has it. Unfortunately, it is
terrible to use.
You see, unlike the deadtree version where the ESV text sits in the upper half of the page, and the extensive study notes sit as end notes in the bottom half, the official e-book version treats it like a hypertext document with oversized text, where the footnotes are replaced with links that jump to a completely different part of the binary file, and after a few such jumps, being lost becomes the regular state of things, made worse by being on an e-reader like the Kindle [Colorsoft].
In short, the official e-book sucks.
I had been patiently looking to see if there was a version of the
ESV Study Bible that was just a straightforward digitisation of the printed version, with all the information where they are, without having to jump all over the place like a punch drunk monkey.
Let's just say my patience paid off and I got ahold of such a version. There was a problem with the images that made up each scanned page---there was a very strong unsaturated red tinge that made the text contrast terrible.
Ignoring lots of [necessary] intermediate steps, I managed to fix the contrast problem at the image level with the following ImageMagick miniscript/command:
find -type f -iname '*.jpg' \
-exec magick {} -separate -contrast-stretch 0.5%x66% \
-combine {}_out.jpg \;So what this does is that it uses the
find command to locate all the image files, and then apply the ``auto-leveller'' on each channel separately, allowing up to 0.5% of the pixels to go ``black'', and up to 66% of the pixels to go ``white''. The
66% is empirically determined through checking the output---the idea is that we want the ``background'' colour of the page to have its unsaturated red plus bleedthrough from the other side's text to ``go away'' (the actual paper is thin enough that there is some bleedthrough in real-life, which of course meant that the scan would yield the same problem, decreasing legibility).
I had tried ImageMagick's
-auto-level option before, but it did nothing to the contrast. Using the alternative of
magick {} -colorspace Lab -channel 0 \
-auto-level +channel -colorspace sRGB {}_out.jpg brightened the contrast, but did not remove the unsaturated red tinge much. It was only after applying the final incantation I specified in the beginning that I saw results.
And the results were
dramatic (I'm not showing them here for obvious reasons), and after running the images through an older version of
KCC (I used 7.2.0 instead of whatever is there now because the 7.3.x series broke many things), I had something that worked wonderfully on Eirian-VI, my Kindle Colorsoft. In this case, I
needed the colour ability of Eirian-VI since colour is used quite extensively as highlights, and for specific diagrams/illustrations within the ESV Study Bible to explain core concepts.
I said that I left out some necessary intermediate steps. They weren't the focus of this discovery, but were needed because
magick could not work on the source file directly to generate the type of output needed. I used an updated version of
pypdf that needed
pillow, which demanded that one does
not update one's Cygwin Python3 installation to 3.12, because it messes the hell out of the dependency availability from the mish-mash of libraries under the default 3.9 and newer 3.12.
------
The
stupid thing I bought finally showed up yesterday. It was, as they say in Chinese, 又贵又重. Shipping was a bitch, and product delivery took a while.
But it finally arrived.
First impressions: yep, it is as it says on the box---a fucking heavy cup. To ensure that it could have the 10 kg mass, the cup's diameter was large enough to quality as a mug, but its depth was shallow enough that the total volume was still cup-sized. In essence, it was like a bowl with a really extended and heavy-af
bassbase. I currently cannot lift it one-handed, and am not expected to do this any time soon. I can also see a litany of overuse injuries in the near future as my deltoids and parts of my pectorals get continually hurt from moving this even as they are healing from their own weakness.
It was as stupid as it gets, and I love it.
I also got the 0.5 lb stainless steel shotglasses (are they still considered shot
glasses despite being made of not-glass?), originally three (one for me, two for CP/Elain), but they upped it to four when my order was delayed enough that they graciously upgraded it to their 4-for-3 promotion.
That shotglass(?) felt nice to hold and drink from. There was no ``metallic'' flavour that one might think something like this would have, but then again, after having eaten out of stainless steel plates and cutlery, there was never a real ``metallic'' flavour to begin with.
For both, I would suggest scrubbing the interior a little more thoroughly before using them as a matter of course.
------
I watch lots of VTubers, so many to the point that 8 regular hours a day cannot be enough. So I watch them at 2.5× speed, which is a speed that the observant will realise to be impossible from both the network bandwidth, and web-client viewer perspective.
The answer is
yt-dlp. That's all I'll say about this part.
The
other parts start with the statement that for the sake of my network, I don't usually need to watch things at 1080+p, for the reason that the video often runs on the vertically aligned screen.
This means that the maximum width of the video that I will be watching, tends to be limited by 1080 px
horizontally.
Mathing it with the usual 16:9 ratio of today, this works out to something like 608 px vertically.
YouTube doesn't have anything at 608p, but they do have 480p, which is the resolution that I often watch my videos in. Automatically upscaling it in VLC media player has some blurriness, but throwing in small amount of sharpen filter, it works well enough.
That is, until the game that the VTuber is playing has lots of words (not a secret: am referring to
Blue Prince). The encoding at 480p from YouTube tends not to do well with text, and it was getting a little... more frustrating to follow.
The magic is to recode it to 480p using better settings than whatever was used when YouTube was transcoding the source to the different bitrates.
The incantation used looks like:
ffmpeg -i inputfile \
-vf "scale=-1:480" -c:v h264_nvenc -crf 23 \
-c:a copy \
outputfile_480p.mp4
The only reason why I thought this was viable was that the encoder could make use of the NVIDIA graphics card that Eileen-III had (RTX 4090). I didn't try to encode without the
h264_nvenc option, seeing that using it meant that it still took time to re-encode the video part.
``Why not just use the source resolution/bit rate and downsample?''
Well... it's slow and doesn't do as good a job as re-encoding. There's also the side issue of avoiding the integrated graphics card [doing the decoding when I'm watching it] from grinding through too many pixels only to discard more than two thirds of them to fit into 1080×608, and end up with a blurry mess due to the lack of access to the kinds of advanced filters that re-encoding can provide.
------
The last thing to
bitchtalk about is the trend of ``oh if you see em-dashes in a text, it is 100% AI generated''. Related to that is ``if the AI detector detects that a paragraph of text is AI generated, it is 100% correct''.
On item 1, that's just a lazy way of looking at things. I mean, come on---if you look at this blog, almost all my posts have em-dashes rendered in. I use them extensively, though to be fair, I don't actually
type the emdash as is---I type it out LaTeX style as
---, and rely on my pretty-printer to render it as an em-dash.
Which segues into item 2. It seems that ``AI detectors'' these days seem better at estimating the quality of a piece of writing with respect to grammar and diction than to truly ``detect'' the use of [generative] AI.
What I am trying to get at is, just because ``you'' suck at writing doesn't mean that any piece of writing that doesn't suck is ``generative AI'' just because ``you'' cannot write well enough. And if life in the modern world is anything to live by, is that anyone who points fingers and claims that someone else is displaying the qualities consistent with some
thing of
meta-variable-X, it is more likely than not a
projection of the accuser who actually
is the thing of
meta-variable-X.
And that's about it for this update. Till the next one.
