Indeed, everything loads from WWW but not BLF. Now I will use Supermium browser for BLF specially and only.
I get the annoyance with the compatibility problems. However, if you are running Windows 7, that’s a 16 yr old operating system that was EOL January of 2020. In all likelihood there will be more websites going forward that are not compatible with your system.
It’s also worth pointing out that casually browsing the web on browser that is extremely out of date is risky. Malicious content (including ads embedded in otherwise-trustworthy sites) can exploit vulnerabilities in old browsers to install malware on your computer, add malicious extensions to the browser, or cause the browser to perform some other harmful action on the attacker’s behalf.
To avoid getting off topic here, I’ve created a modern web browsers for your old computer thread.
Something I just noticed…
I edited the last post of a thread, but it didn’t bump the thread (like BLF’s software did so in the past.)
I might be in the minority, but I prefer threads to be bumped when the last post is edited. ![]()
That’s the typical asshattery I see a LOT of so-called “developers” taking.
I do not remember threads ever being bumped due to edit, new posts yes, updates no, actually I can not remember it happening on any forums, not just blf.
I belong to dozens of forums, and only BLF had this feature.
I don’t know if it was a Discourse feature, or if it was some sort of hack implemented by sb, but I liked it when we had it. ![]()
You’re right, it was a Discourse feature, but for some reason they decided to remove it.
That’s okay.
I’ll live. ![]()
Don’t know if this is related at all to the update, but I’m suddenly having issues with image hosting.
A few days ago I was able to load multi-MB images with no issue. Now I am getting this warning:
and even after reducing the file size to <700kB, I continue to receive it.
Speaking of uploading large images…
Perhaps I should resize all images to 690 pixels wide (or 500 pixels tall) before uploading them to the BLF server.
The reason is that when images are displayed in BLF threads, anything over 690x500 pixels will be resized to a maximum of 690x500 pixels (though it is possible to see the original image with some extra mouse clicking.) ![]()
EDIT:
I mean, no offense to BLF’s software, but I prefer my method of resizing an image over BLF’s method. ![]()
Most people probably don’t care about this issue, but I’m a bit of a control freak with OCD! ![]()
What method do you use?
I’ve mostly been doing this sort of thing…
> mkdir sized
> for f in *.png ; do resize-hq 690x500 "$f" sized/"$f" ; done
> optipng sized/*.png
> cat $(which resize-hq)
#!/bin/sh
SIZE="$1"
INFILE="$2"
OUTFILE="$3"
convert "$INFILE" -filter Lanczos -distort Resize "$SIZE" "$OUTFILE"
… and maybe a
> for f in *.png ; do convert "$f" -quality 80 "$f.jpg" ; done
or similar, depending on the format and compression I need at the time.
Basically, I’ve tested a bunch of scaling algorithms and Lanczos has given me the best results so far. Has been a while though, and new types have been added, so I should probably try them again to check if there’s something even better. convert -list filter now shows 30 different scaling algorithms.
Edit: The “Lagrange” filter makes visibly sharper images when converting something with text in it. It looks like the best filter may depend on the content of the image though, so I might just add another script to convert with every filter and then pick one.
Edit: Fixed typo, wrote “.jpg” when I meant “.png”.
I use IrfanView (and I typically output to a webp image) with settings that I like. ![]()
I need to find a better program (with a nice GUI) to resize images. ![]()
EDIT:
Apparently, if one resizes a lossless webp, the file size will most likely increase even if the dimensions shrink.
I tried IrfanView, XnConvert, and Squoosh Desktop with similar results. ![]()
These are the settings I use in IrfanView…
webp lossless:
…
webp lossy is like this, though I sometimes change the quality setting:
…
resize settings:
…
The images in this post did not get reencoded by Discourse, perhaps because the file sizes are so small (~10 KiB each). ![]()
I haven’t tried this yet, but I could resize a lossless webp in IrfanView, then display the image at 100%, and then hit Print Screen and create a fresh lossless webp.
That is quite tedious, but I think it would work. ![]()
Fascinating. And very different than my process.
I’m still using .png and .jpg for lossless and lossy images, most of the time. I generally do the resizing in lossless form, then convert to a lossy image depending on what I need at the time.
Speaking of which…
One of the pics where the scaling algorithm mattered was when Tom E wanted a cleaner avatar picture, and he was getting moire effects on the cooling fins of his torch. So I tried a variety of scaling algorithms too see which worked best. Here are maybe half of the algorithms, with the native 85 pixel version (BLF’s avatar size at the time) and a scaled-up (but still pixelated) version to show the pixels better:
Blackman:
![]()
![]()
Box:
![]()
![]()
Catrom:
![]()
![]()
Cosine:
![]()
![]()
Cubic:
![]()
![]()
Gaussian:
![]()
![]()
Hamming:
![]()
![]()
Hermite:
![]()
![]()
Jinc:
![]()
![]()
Kaiser:
![]()
![]()
Lagrange:
![]()
![]()
Lanczos:
![]()
![]()
LanczosRadius:
![]()
![]()
Point:
![]()
![]()
Quadratic:
![]()
![]()
Spline:
![]()
![]()
Triangle:
![]()
![]()
Welch:
![]()
![]()
Original, in case anyone feels like doing their own tests with the same image:

Yep, same here.
When I’m editing an image, I use a lossless format, and then at the end, I convert to lossy (if it saves file space.)
I know that IrfanView isn’t the best at everything, especially compared to CLI programs, but that program is convenient (in my opinion.)
I also use Photoshop (or GIMP) for some things, though those programs are bloated in comparison. ![]()
I just learned that this is partially incorrect.
I now think that the true maximum resolution for an image posted on the BLF forum is 1380x1000 pixels.
If an image is that size or smaller, I don’t think it’ll be reencoded, though it will be displayed at a maximum of 690x500 pixels if it’s bigger than 690x500. ![]()




