Reproducing the same jpeg

To be able to get an accurate overlay / train a jpeg-denoising AI, we needed to be able to reproduce the same jpeg settings as seen in the original screenshot. The Photoshop settings shown above do the job, but it would be impractical to use Photoshop every time for it, especially with a live recreation overlay. That's why we needed to figure out how to reproduce it algorithmically.

The way each jpeg image is encoded/compressed depends basically only on the "quantization tables". These can be easily extracted from the image.

You can grab these from here: http://fotoforensics.com/analysis.php?id=cf7716e80530f991ccf01f89c546f74fe1ae1b59.101733&show=estq

With the jpeg algorithm implemented, reproducing the jpeg is easy. You basically just paste these in.

Minecraft Version

Based on the date of the screenshot and the appearance of the world within it, it was determined that the screenshot was taken no later than in version Alpha 1.1.2_01, which was the latest version at that time (released on September 23th 2010), so it's the version we'll be working with. https://minecraft.gamepedia.com/Java_Edition_Alpha_v1.1.2_01

There are a few things to keep in mind regarding this version:

• It's the last version before biomes were introduced into the game. This means that all of the grass and leaves (also the sky) have the same color everywhere.

• It also uses an older terrain generator than the one used in later Alpha/Beta versions.

• The leaf decay is broken, so leaves can randomly decay even if they are still part of a tree. This means that we can't really depend on leaf placements, or at least not on the ones we don't see, only on the ones we still do.

• This version doesn't have flying, custom seed selection, F1 (hide GUI), F2 (take screenshot) or even GUI scale setting (the GUI can still scale automatically depending on the resolution though).

• Animal spawning is random, it doesn't depend on the seed.

Original Resolution

Since you couldn't hide the GUI in this version with F1 and Minecraft couldn't take screenshots with F2 yet, the screenshot has been taken manually with all of the GUI elements still present. The hotbar at the bottom and the version name at the top have been cropped out and the crosshair has been edited out (it still left some visible artifacts behind though). The image couldn't have been just print-screened though, since that doesn't work in fullscreen mode (F11), so it had to be taken while Minecraft was in windowed mode. The resolution of the cropped screenshot we have is 1602x971. We tried to figure out the original resolution ourselves at first, but we wrongly concluded that his monitor was 2048x1152. He later said his monitor resolution was actually 1920x1200 and he also said that he used Windows 7 at that time, which got us a window size of 1920x1148 after subtracting all the Windows panels (his bottom taskbar was set to a smaller size than default btw).

Cropping

We were able to figure out the full resolution and cropping rectangle by matching the shape of the player's hand in the picture with our own pictures, since the size of the hand depends only on the vertical resolution, and it's always drawn the same way when standing still (except for shading of course). It was a bit hard to match the hand with so much jpeg artifacting present, but we confirmed it with multiple jpeg denoisers and also by replicating the same jpeg settings for our own screenshot, and we independently got the exact same cropping rectangle every time, so we're pretty confident about it. Here's how it looks like overlayed over the full game window at 1920x1148 resolution:

Crosshair

As mentioned before, the crosshair had to be edited out of the image, because there was no way to hide the GUI (no F1 functionality). This wasn't done very precisely though, so you can still find some leftover artifacts in the image. These are the corners of the crosshair.

Vignette

Before Kristoffer told us his original monitor resolution, we tried to figure it out ourselves, as well as the original center of the screen. For this we used the vignette overlay that's present on fancy graphics and visible in the screenshot. The vignette is a transparent screen overlay that gets darker towards the edges.

Clouds --> Position

As always, the cloud patterns are the most useful thing for figuring out the Z coordinate, so that's what I did here too. Here is the location of the visible cloud patterns in the picture below.

Based on this, we know that the player is standing roughly around Z=-30 facing north (towards -Z). The orientation of the moon also helped to get the correct facing direction initially.

Additionally, Kristoffer said that he thinks it was a random world he intentionally created just to get a nice screenshot of the moon. He doesn't think he would've walked too far, he mostly just waited for the night, so it's safe to assume the position is near 0,0. He also thinks that he did it in a single game session (basically without closing the game or opening other worlds), so we can probably rewind the clouds based on the time of day and get the X coordinate that way.

Time Of Day

The time is early night, since the moon is rising in that direction. We can get the exact time (when we have the correct perspective set up) using the exact angle of the moon (or using stars too, if the moon isn't precise enough). The current estimate using just the block light level (=6) is between 13353 to 13509 ticks.

Important things to help SeedCracking

Dirt heights

The other thing that's gonna help us find the coordinates is the dirt heights. There are a lot of dirt-to-stone borders visible, so getting enough samples should be easy (after we have the overlay). The dirt thickness at each location is partially based on the seed, but partially also just based on it's world coordinates, so using a statistical analysis, we can determine the most likely X/Z coordinate, roughly speaking.

Trees

The trees might be of interest, but we're gonna focus on the flowers and dirt first. Also we can't really depend on the leaves, because all the leaves randomly decayed in this version.

Render distance chunk borders

You can spot the edge of the rendered chunks on the far right side, which we can use to get the correct chunk alignment after we get a good perspective+overlay.