User talk:Valaggar/PlanetBox

To continue some of the discussion here rather than clutter up Svdb's page - If I can interject some thoughts on this, it might look better with the "type" box beneath the planetary data - also i don't think it's necessary to say what the satellite types are just how many of them there are. This field could be merged into the planetary data section. Also as to the map size, I'd recommend 242x75, the size of the eartmask.png, or 232x67, the size of the orview.19.png. I couldn't find any other set example of a map in the UQM content files though. That said, do you mind if I or others tweak this page a bit to experiment with the appearance? --Fyzixfighter 10:44, 1 May 2007 (CEST)

You can tweak it how you want.

As to satellite types - well, it makes a BIG difference to look at the sky and see a Water World moon, for example. And it doesn't clutter the PlanetBox at all. Just a few extra characters.

Planet type box moved below detailed data.

Speaking of merging the satellite data with data on the planet - well, you can see it better in the planet type box, as it's related to the "planet at a glance" information rather than detailed data.

I don't know what's up with eartmask.png, but if you zoom in to the topomaps here you can see that there are no macropixels (former pixels divided into multiple pixels). I guess this is because of the scaler, but it looks better at the current resolution. Valaggar 11:10, 1 May 2007 (CEST)

Hey Val, what were the graphic settings you were using when you took the topomap images? I'm trying to compare how these look at different settings. Just FYI, using the lowest resolution (equivalent to the original SC2) the images are 242x75 like the eartmask.png. --Fyzixfighter 06:44, 2 May 2007 (CEST)

1024x768. Windowed, if this matters. Valaggar 14:10, 2 May 2007 (CEST)

Thanks - Which scaler was it using? --Fyzixfighter 16:08, 2 May 2007 (CEST)

HQ. As a side note (17:05 CEST), I can re-take the screenshots, there's no need to do it yourself. Valaggar 16:53, 2 May 2007 (CEST)

While the advanced scalers tend to look less pixelated, there is a problem with trimming the grey border. With any of the scalers, the border and topomap bleed together for a few rows/columns of pixels. I'd be more in favor of using the unscaled topomaps, like we did for the alien artifacts (granted it was easier for those since the raw images existed and were easily accessible). And since its the rawest data, anyone can then go and easily apply the various algorithms to create a smoothed out image; unconvoluting a scaled image on the other hand is a pain - though I don't know how or if the same argument holds up for the 3d planet image. But since that's generated from the topomap (and the 3d image generation has changed significantly for UQM), I think a good compromise would be to use the HQ, high-res 3d image, and the none-scaled, low-res topomap. Oh and don't worry, I'm only tinkering around with a single topomap, checking out the various resolutions and scalers. And with that, I'm off to work. --Fyzixfighter 17:34, 2 May 2007 (CEST)

You've got the point here. Don't worry, I'll do the grunt work. My plan is to take the shots with no scaler and apply a 100% Low Pass with a radius of 2 pixels, and it looks much better than with any scaler, plus with no cut columns or rows. Valaggar 17:46, 2 May 2007 (CEST)

EDIT: BTW, the HQ scaler does not cut any columns or rows, it's just an illusion. Anyway, I feel that the low pass works better. I don't know if you agree, though. Uploaded Gamma Serpentis I with Low Pass from No Scaler for comparison:
and here is the HQ Gamma Serpentis I:
Hmm... maybe the HQ version is the best, now that I glance upon the image again. Valaggar 17:58, 2 May 2007 (CEST)

It's not that the HQ removes rows/columns - it's that the HQ blends the grey border with the topomap. Zoom into the interface region (preferably an area with some variety like a continent) and you'll see what I mean. Really, any of the in-game scalers will produce this since it's using the neighboring pixels to interpolate the extra pixels. I imagine you could take the cropped raw image without the grey border and then interpolate, but since which interpolative algorithm to use is so subjective I'd still rather just keep to the raw data, even though it does look more pixelated. --Fyzixfighter 19:22, 2 May 2007 (CEST)

I've already looked at various land forms, all 4 borders, and, frankly, there's NO pixel screwed by HQ that wasn't already screwed by the transition effect present in the non-scaler mode too. If you'd supplement your view with a screenshot on which to show the exact screwed areas, I might reconsider my PoV. Valaggar 20:06, 2 May 2007 (CEST)

Strange, since I see it just fine. Yes I know these aren't from the same planet, but they demonstrate the point (and sorry for the whitespace). Highest resolution with no scaling, zoomed in on the interface:

And zoomed in on the interface for highest resolution and HQ scaling Notice how in the none-scaled region, the interface is very clean, while in the HQ version the light grey strip blends blends with the top row of the topomap. This is what I was talking about and why I would still advocate using the raw, lowest-res, none scaled image. --Fyzixfighter 23:32, 2 May 2007 (CEST)

OK, now I see. But it's not that much. Not that much to motivate giving up the image's quality. Let's see what others say. Valaggar 14:47, 3 May 2007 (CEST)

Making the whole "1 satellite" text a link doesn't look like a good idea to me. It looks bad, plus what would you do if you have 2 satellites?

Anyway, it's good that you found the 242px value. It looks better now.

Finally - looking at the double topomap, it's easy to see that there is no visible difference. It would not be a bad idea to keep the not-scaled images too, I think each of them should have a link from the scaled images (i.e. in EtavulpeculaeiiMap.jpg's description there is a "Low resolution image" link). Valaggar 08:09, 5 May 2007 (CEST)

Recent tweaks

Well you did say we could tweak it. Just a bit of explanation on the last little tweaks. I collapsed the borders since the right edges weren't lining up too well, and this was the only way I could fix it (I'm sure there's another way, but...meh...this works). I also hid the moon type into the satellite term. My main concern was it looked kind of messy to me with all that information and this way makes it easier to apply to planets with multiple moons - the line could become something like 3 satellites (a,b,c) where a,b,c each link to the appropriate world types. Also, I changed the topomap size to the 242px size since it was the original size and 300px still seemed a bit large and arbitrary. The 242px size also seems to fit the planet data table better. And for comparison, I uploaded and included the original, unscaled image of the topomap - in some places it looks a little blockier/more pixelated, but there are some details that actually are not as visible in the scaled image as in the unscaled image (like some of the craters), but this may be an artifact of the wiki resizing algorithms.

Yeah, maybe it would be best to use the pixellated image in PlanetBoxes and the scaled image linked to from the non-scaled image.

The edits are very good, and now I understand what you want with the satellites and I approve it, but I think that planets with a single satellite should be "1 satellite (a (<link>))", for symmetry.

Ah, and yes, you can tweak it. I just presented my opinion about how the PlanetBox looks. Valaggar 11:20, 5 May 2007 (CEST)

Yes, I think that's a fair compromise on the satellite issue. One other thing that I would suggest is not using the JPEG format. JPEGs use a lossy compression method, whereas the PNG don't. The file will be a bit bigger, but only by about a factor of 2 and the files are already very small. If you don't have the capability to save as a PNG let me know and I can do it. --Fyzixfighter 19:49, 5 May 2007 (CEST)

I can do it, but this would require to retake all the shots. It's not a problem for the lowres ones, since I didn't take them yet, but the 3D images would mean some work. I don't think I'll do it very soon, so... Valaggar 20:29, 5 May 2007 (CEST)