Bruninho wrote on 2020-02-18, 02:26:

Does the logo still need that hat?

the hat's my favorite part of the new site

Note sure if this should go here or in the bugs thread.

I just attached a jpg image that was 1.24MB and the forum automatically reduced the quality which made it 451KB.

I did a search but didn't find anything mentioning this.

Is this on purpose. If so, why? I really like having high quality pics and not sure what the reasoning behind reducing image quality / size if it is under 2MB.

cyclone3d wrote on 2020-02-22, 06:19:

Is this on purpose. If so, why? I really like having high quality pics and not sure what the reasoning behind reducing image quality / size if it is under 2MB.

It is intended. The primary resource constraint for the site is disk space utilisation, and there’s no reason to store a 1.2MiB file when it could be (in this case, 62%) smaller. The encoder won’t touch images which are already reasonably compressed and it shouldn’t cause any perceptible quality change to images at normal viewing size. Since most people are just uploading photos taken straight from their phones with no processing, this automation is important regardless of the uploaded file size.

In the case of the last photo you uploaded, while I don’t have access to the original image for comparison, it appears to me from inspecting what’s there that your photo was already crushed by a different JPEG encoder as it contains artefacts that shouldn’t normally appear at the high quality level that the site encoder uses. When you re-save an already compressed image at Q=100, you’re not making the image more high quality, you’re just bloating the file size by retaining the high frequency quantisation error from the first run through the JPEG encoder. That data is not actual image data, it’s just garbage from the DCT, and discarding some of that data again isn’t hurting the image quality.

I hope this makes sense. Let me know if I can clarify anything else.

I *really* miss being able to see the page numbers (e.g. [1], [2], [3], ... [14]) on the topics.

The reason?

Without them, it is impossible to tell at a glance what kind of thread this is. Is it a brand new thread you might want to jump in on? Is it a very active, large thread? Is it a build thread with lots of pages? Etc.

Plus it is nice to be able to immediately switch to the last page and also know which page that is. (am I switching to only the 1st page? Or is it the 10th? Or perhaps the 500th page?)

keenmaster486 wrote on 2020-02-25, 20:49:

I *really* miss being able to see the page numbers (e.g. [1], [2], [3], ... [14]) on the topics. […]
Show full quote

I *really* miss being able to see the page numbers (e.g. [1], [2], [3], ... [14]) on the topics.

The reason?

Without them, it is impossible to tell at a glance what kind of thread this is. Is it a brand new thread you might want to jump in on? Is it a very active, large thread? Is it a build thread with lots of pages? Etc.

Plus it is nice to be able to immediately switch to the last page and also know which page that is. (am I switching to only the 1st page? Or is it the 10th? Or perhaps the 500th page?)

Yeah, that would be nice to have back. As it is now, it just jumps you to the first post if you click on the thread title or to the first unread by you post if you click on the link to the left of the title.

Snover wrote on 2020-02-22, 16:51:

It is intended. The primary resource constraint for the site is disk space utilisation, and there’s no reason to store a 1.2MiB […]
Show full quote

cyclone3d wrote on 2020-02-22, 06:19:

Is this on purpose. If so, why? I really like having high quality pics and not sure what the reasoning behind reducing image quality / size if it is under 2MB.

It is intended. The primary resource constraint for the site is disk space utilisation, and there’s no reason to store a 1.2MiB file when it could be (in this case, 62%) smaller. The encoder won’t touch images which are already reasonably compressed and it shouldn’t cause any perceptible quality change to images at normal viewing size. Since most people are just uploading photos taken straight from their phones with no processing, this automation is important regardless of the uploaded file size.

In the case of the last photo you uploaded, while I don’t have access to the original image for comparison, it appears to me from inspecting what’s there that your photo was already crushed by a different JPEG encoder as it contains artefacts that shouldn’t normally appear at the high quality level that the site encoder uses. When you re-save an already compressed image at Q=100, you’re not making the image more high quality, you’re just bloating the file size by retaining the high frequency quantisation error from the first run through the JPEG encoder. That data is not actual image data, it’s just garbage from the DCT, and discarding some of that data again isn’t hurting the image quality.

I hope this makes sense. Let me know if I can clarify anything else.

Ok. It was taken with my phone. I then opened it up with Serif Affinity Photo to adjust and crop it and then exported it to a smaller resolution as well. I did leave it at 100% since it was under the 2MB upload limit.
The red wire coloring is very degraded as well as the rest of the image not being as clear compared to the image I uploaded due to the site auto compressing it.

It is a lot easier/quicker to take pics with my phone than it is to do so with my DSLR and shoot RAW and then process the image.

What compression setting do I need to use in order for the site to not auto compress it?

keenmaster486 wrote on 2020-02-25, 20:49:

Without them, it is impossible to tell at a glance what kind of thread this is. Is it a brand new thread you might want to jump in on? Is it a very active, large thread? Is it a build thread with lots of pages? Etc.

Not so. The “replies” column gives you this information.

cyclone3d wrote on 2020-02-25, 21:00:

Ok. It was taken with my phone. I then opened it up with Serif Affinity Photo to adjust and crop it and then exported it to a smaller resolution as well. I did leave it at 100% since it was under the 2MB upload limit.
The red wire coloring is very degraded as well as the rest of the image not being as clear compared to the image I uploaded due to the site auto compressing it.

Would you please upload the originally saved cropped compressed version to a file transfer service so I may examine it directly?

cyclone3d wrote on 2020-02-25, 21:00:

What compression setting do I need to use in order for the site to not auto compress it?

Progressive scan at libjpeg-turbo equivalent of Q=92 or lower and all metadata stripped. MozJPEG is a good choice.

Snover wrote on 2020-02-25, 21:14:

Not so. The “replies” column gives you this information. […]
Show full quote

keenmaster486 wrote on 2020-02-25, 20:49:

Without them, it is impossible to tell at a glance what kind of thread this is. Is it a brand new thread you might want to jump in on? Is it a very active, large thread? Is it a build thread with lots of pages? Etc.

Not so. The “replies” column gives you this information.

---

cyclone3d wrote on 2020-02-25, 21:00:

Ok. It was taken with my phone. I then opened it up with Serif Affinity Photo to adjust and crop it and then exported it to a smaller resolution as well. I did leave it at 100% since it was under the 2MB upload limit.
The red wire coloring is very degraded as well as the rest of the image not being as clear compared to the image I uploaded due to the site auto compressing it.

Would you please upload the originally saved cropped compressed version to a file transfer service so I may examine it directly?

cyclone3d wrote on 2020-02-25, 21:00:

What compression setting do I need to use in order for the site to not auto compress it?

Progressive scan at libjpeg-turbo equivalent of Q=92 or lower and all metadata stripped. MozJPEG is a good choice.

Ok, I put it on my Google drive.
https://drive.google.com/open?id=197dJGV2W7fZ … IYIIt5QRIYC9lHq

Thanks for the info.

cyclone3d wrote on 2020-02-25, 22:38:

Ok, I put it on my Google drive.
https://drive.google.com/open?id=197dJGV2W7fZ … IYIIt5QRIYC9lHq

Thanks, you can remove that file now if you’d like. There’s a barely perceptible difference in the noise pattern between the two which is only noticeable by A/B testing (but not so noticeable that I can guess correctly in an ABX test). This is to be expected since it’s a lossy compression and noise is a high frequency component. There is no obvious visual quality degradation and the tone of the red wires is unchanged. The original file shows clear signs of macroblocking, especially in the chroma channels, so was not a high quality source to begin with. The SSIM of the compressed image compared to the original is 0.966 which is very good. All this is to say: the site compressor is operating well, so you need not worry about doing extra work to try to keep it from doing its job.

In any case, consider how much you are worrying about the quality of a photo of a 3-pin fan connector. This isn’t a fine art site. You could probably crank that down to Q=20 and it’d still serve its purpose.

Haha. Thanks for checking.

That fan connector was cropped quite a bit so I am not surprised that it was not that great to begin with. I just noticed the difference immediately after uploading it so I thought maybe there was something going on.

I'll just make sure to export at 92% from now on. I used to do 95-98% to bring the file size down below 2MB when needed.

@Snover:

I have a suggestion. I have been trying older browsers and noticed that the only thing stopping me to submit the log in form with them, is that it cannot understand the button submit tag.

The new forum log in form has a button element to submit the form. Apparently older browsers do not understand the button tag. Can't we replace it with an input type=submit? I understand that it would require some additional tricks for CSS (you can use an label with 'for="..."' attribute as a trick to style the same button, if you need the same styles).

Probably this way older browsers that were updated for newer ciphers and TLS can log in again.

keenmaster486 wrote on 2020-02-25, 20:49:

I *really* miss being able to see the page numbers (e.g. [1], [2], [3], ... [14]) on the topics. […]
Show full quote

I *really* miss being able to see the page numbers (e.g. [1], [2], [3], ... [14]) on the topics.

The reason?

Without them, it is impossible to tell at a glance what kind of thread this is. Is it a brand new thread you might want to jump in on? Is it a very active, large thread? Is it a build thread with lots of pages? Etc.

Plus it is nice to be able to immediately switch to the last page and also know which page that is. (am I switching to only the 1st page? Or is it the 10th? Or perhaps the 500th page?)

Another forum I use had the same problem, and they had to resort to some extreme hacking of the forum software and theme to get back the functionality.

This is actually something that really annoys me about modern forum packages: the removal of features that make a website easily usable. It's right up there with "vague icons that only mean something to the front end developer and no tool tips" as one of my pet peeves. Both lead to bad website accessibility.

yawetaG wrote on 2020-02-29, 08:49:

... It's right up there with "vague icons that only mean something to the front end developer and no tool tips" as one of my pet peeves. Both lead to bad website accessibility.

I agree completely. A good example is the "new post" button on this website. It's just a big plus sign, which is not immediately obvious at least to me.

keenmaster486 wrote on 2020-02-29, 17:37:

I agree completely. A good example is the "new post" button on this website. It's just a big plus sign, which is not immediately obvious at least to me.

I thought that's just there if I want to call an ambulance. 😀

Hi,

I haven't used this forum very much in years, but every now and then come in to check on it. I'm very impressed with the new look. I've been using forums a lot more lately, maybe I'll start using this one more often too.

Back in 2010, I created a thread for attaching DOSBox-compatible ports of *NIX games:

Attach your DOSBox-compatible *NIX ports in this thread

I noticed that now there is a requirement for giving the license of attachments, with the default being "Fair use/fair dealing exception." Of those attachments on the thread, some are GPLv2 or later, one is GPLv3 or later, three are Simplified BSD, one is MIT, and two others have no license given in the code.

I was wondering if you were planning on adding additional FLOSS licenses if requested, and if so, could you please add the licenses mentioned above? If not I'll leave everything not GPLv2 "Fair use/fair dealing exception" and post a message to the thread (last post was in 2012) listing the licenses for each attachment so far. (Nobody else posted any attachments to the thread.)

Thank you!

Merged to the official feedback thread so that Snover would see...

I have a suggestion for when an user comes here with JS disabled.

If I disable JS and access the forum, the popups for login menu, notifications and user menu are rendered open instead of closed. I'd suggest to keep them closed and add a link to the login page, notifications page as well as the user profile page for when an user comes with JS disabled. Makes for better browsing on older operating systems or when an user has a preference to load sites without JS.

One CSS trick I use to load menus, modals without JS is to render them next to a hidden input checkbox, triggered by a label rendered like a button. Then I use a ":checked ~ element" selector to target the menu/modal.

But here its better to use the first solution.

Hi, all

I think I've found a bit of an issue with Vogons' forum engine.

Quite often I'm browsing through Archive.org or Usenet groups to learn about a piece of software, a driver or a ROM file only to see that the download link for that file is dead. I track a specific filename that I then try to google, with no success. And then I learn that this file was actually published on Vogons in a form of a file attachment. But the post with that file would not appear in Google.

Example:

mauimt32.zip — available here

Yet if I try to google for "site:vogons.org mauimt32.zip" I get nothing. (searching for mauimt32.zip without specifying the site will show lots of Usenet posts, but again no link to Vogons).

At the same time, if I try to google "site:vogons.org setwf143.zip" I'll find this post, but not this post.

Both posts in the latter example are roughly from the same time, the only difference I can see is that the "setwf143.zip" has a file description in the first post, but not the second one. If I try to use the forum's search function, I'll find no mentions of mauimt32.zip, but searching for setwf143.zip will again give me only one result.

So could this be that filenames themselves are not being indexed on Vogons? Is there a better way to find file attachments here or is it something that could be fixed in the forum's settings by the administration?

I imagine that Vogons' users have posted lots of unique files here over the years — it would be a pity if they were lost.

Good suggestion. Merged into feedback thread 😀

I don't know. This site is being crawled by Google bots constantly.
If files can be searched, maybe there will be automated requests to put down content because of certain file names (written warnings).
Just look what insanity happened just recently :
https://torrentfreak.com/adobe-goes-after-27- … -ms-dos-210315/

Edit : A few words about Archive.org.. Some users are actually worried that the archive runs games in emulation since a while, for example:
It uses Win 3.x as a runtime to allow accessing Windows Shareware stuff from the 90s and so on.
Or lets you play all sorts of home computer/console games from the past.
Currently, the archive is protected by US law, because it has library/archive status, so it gets away with it.
Nevertheless, people have mixed feelings about such actions.
Somewhen, the archive may go too far and must pay back.
This in the end would affect the wayback machine, too, which is much more important (like a world heritage).
That's what worries certain people, I think.