ache7

myjino-ru is just a virtual hosting provider.

j19544519 - seems to be the username on this hosting.

Damn, github should show some big visible warning about this.

Here is a commit with malicious code from a Microsoft employee:

https://github.com/promonlogicalis/asn1/commit/7bdca06d0edf8...

These trolls really exist on Russian social networks, trying to refute any news from the opposition media. And some people (Russian enthusiasts) count and list these bots. But your article does not prove it to me, because some Russians are afraid of vaccinations and there are crazy paranoids in Russian social networks that convince not to get vaccinated, including vaccines that are done by Russian medicine - what do you think this proves? That Russian bots are trying to weaken their own nation? For me, these are not bots, but religious fanatics, religions often reject medicine. You may have noticed that many religions have denied the existence of COVID this year.

It is very sad that the authors of the article either believed in all these accusations against the Russians or are afraid to say that this is nonsense so that they are not accused of supporting the Russians.

I want to note that the Russian government also accuses its political opponents of being foreign agents, using the same rhetoric.

Any number is remarkable if you're smart enough to find why it's remarkable.

If it's an outdated pesticides, as suggested in another comment, then it's very related. Because it's a leakage from an old Soviet storage tanks.

Using compiler hints, data can be placed directly in the code section.

Works on x86/x86_64 Linux:

char main[] __attribute__ ((section(".text"))) = "\xe8\x0d\0\0\0Hello world!\n"

#ifdef __x86_64__

"\x31\xc0\x8d\x50\x0d\xff\xc0\x89\xc7\x5e\x0f\x05\x31\xff\x8d\x47\x3c\x0f\x05";

#else

"\x31\xdb\x8d\x53\x0d\x59\x8d\x43\x04\x43\xcd\x80\x31\xdb\x8d\x43\x01\xcd\x80";

#endif

He is also one of the developers of Bad North, where islands are procedurally generated, much similar with this demo.

About that "write-ppm" example. Using PPM type 3 will increase the size of pixel data by 2-4 times. Use type 6.

I don't have the general problems with reading, but I do have the problem you mentioned. And I'm also kind of a speed reader, I think the problem is here.

It reminds the index of the first element in an array in different programming languages. Some use one-based indexing, others use zero. Which causes problems (bugs) when porting the program to a language with different indexing.

Modern computers have some sources of entropy that can be used to create a random numbers. For example, the timings of the memory access, race condition of threads. User interaction (mouse movement, delays between keystrokes) can also be used as an input signal to feed a random number generator (which is some hashing algorithm).

It goes fine with mozjpeg. I tested a little, didn't find any problems.

I've seen these projects on github. I don't remember the names, only that waifu2x upscaler has an NN filter for JPEG artifacts.

Use "-w 0.0" switch to jpeg2png, gives slightly sharper results.

Also try with: https://github.com/ilyakurdyukov/jpeg-quantsmooth with "-q6" (default setting without luma-aware chroma upsampling)

My guess is that quantsmooth won't handle squares in the background well, but will be better at the edges (without excessive blurring).

Update: I tested it, it's about 10% quality, jpeg-quantsmooth doesn't handle this quality. At 25% quality - result is fine, starting at 20% and less - not good.

Perhaps the synthesis of all three projects combined into one (taking best of each) could give a great result.

So then...

jpeg2png: overblurs and slow

knusperli: does only deblocking, not removes artifacts

jpegqs: fails to deblock low frequencies (less 25% quality)

"All JPEG decoders have chroma upsampling."

Well, I meant better upsampling than bilinear interpolation, which blurs chroma.

"Oh, you can also jointly optimize the YUV-RGB conversion because if the pixel ends up out of range in RGB space it is probably a compression artifact."

Probably not, I suspect that the mozjpeg encoder may use this, so images with black on white text look better (artifact noise go beyond of range).

Both of these projects have chroma upsampling.

By the way, you can decode JPEG with less artifacts using these projects:

https://github.com/ilyakurdyukov/jpeg-quantsmooth (good for most mid-quality and high-quality images)

https://github.com/victorvde/jpeg2png (use for very low-quality images, slower)

jpeg-quantsmooth gives a sharper output (use "-q6" option).

jpeg2png output is a little blurry, but it does a better job of unblocking very low-quality images.

Actually - JPEG is not lossless even at 100% quality, there is a little noise at +/-1 of pixel value, some rare pixels at 2. Grayscale is not needed, you may skip RGB->YUV conversion and encode in RGB colors, libjpeg can do that.

And I also have questions about decompression speed and memory requirements.

JPEG quality can probably be better (but slower) when using sophisticated decoder libraries. This way, a JPEG image with a WebP size may look with the same quality. But I didn't test.

https://news.ycombinator.com/item?id=22245788

Also, Google has a "brunsli" library, that can recompress JPEG to JPEG XL format without loss.

https://google.github.io/brunsli/

Here you can find the link: https://www.ddosecrets.com/data/north_america