Jump to content
Sign in to follow this  
Followers 3

Is there an optimal image size?

Recommended Posts

I've noticed that many images look poorly when using the whereyougo app. Before I load up my own cartridge with images, is there anything I can do to improve the appearance of the images I use? For instance, make them at the proper target size.

Related to this, the Edit Cartridge Listing - when using the Wherigo\\kit - has a place for two images. One seems to be the same as all other dialog boxes for zones and questions etc, but the other is labelled 'cartridge icon'. What is the purpose of the cartridge icon... where does it show up?

Sort of related to this, if I upload an image to the \\kit but later opt not to use it, will it be excluded at compile time or will it bloat the cartridge?



PS. So far I have had no problem with the \\kit. I'm still learning where things in the GUI, let's call it, translate into realtime play, but overall I'm finding it an easy experience... and the waypoints are being triggered perfectly which in turn make program flow unproblematic.


Share this post

Link to post

I usually reference the media specs pinned topic in this forum for image sizes.  If we as a community come up with new standard sizes, I'd heavily suggest putting the new sizes there.

As for your other question, cartridges, zones, characters, items, and so on can have two pictures associated with them: the regular photo that shows up on the object's detail screen (e.g. when you click to view a zone and detailed navigation to it) and an icon for when the object is shown among a list of other objects (e.g. on the screen that lists all zones).  For Kit, you can give Kit an icon for your cartridge (I think I have it where it scales it down for you) for when the cartridge is shown within a list of cartridges and the regular image for when someone clicks to read information about the cartridge before starting the game.  Kit will allow the cartridge icon, but it'll automatically make icons for your zones based off whatever image you give it for the zone details page.  At the moment, Kit v2 follows this same process, but it includes little green question marks to tell you what everything is and how it will be used.  (I have most of the builder done to show a cartridge, but I have to add the ability to edit a cartridge before I can release it for community comments and suggestions.  I also want to add the ability to play sounds.  Anyway, most of the major changes are in the back end, plus it'll be faster in the front end.)

Finally, about the images in Kit.  If you upload a picture and don't use it, Kit should detect that and delete the image.  It does so because I was being cheap and didn't want to pay to host pictures people didn't end up using in their cartridges.  If everyone had 250KB in extra pictures, I'd be paying to store 1.25GB for no reason.  That's also why I've hesitated about letting people upload mp3 files to play in cartridges--that and I'm concerned about cartridge sizes getting too large.  But I think I'll try it out later in Kit v2 and see how it goes.

  • Upvote 1

Share this post

Link to post

I recently came up with a cartridge that had max width of 300 and max height of 230 and 200 height for messages. On the iPhone app 300 fill up the screen a little better (at least for my SE). Otherwise the images tend to appear too small and not centered.

Edited by Forest-Ghost
  • Upvote 1

Share this post

Link to post

Thank you both.

So... "[Width is always 230 pixels]" - that gives me something to work with. I can experiment with height and see what happens.


Yes, Kit scales the icon down (I tried it late last night), as it does with other images.

And for whatever it might be worth, Kit v1 is going to be perfect for what I currently have in mind - a simple tour with two questions. However, a friend and I are looking into something more sophisticated so it's good news to hear v2 isn't far off.

Thanks again.

Share this post

Link to post

By the way, there's a risk people run when sizing images.  As images appear above text in messages and inputs, people playing the cartridge might not always catch on that there's text underneath the image if the image ends just before whatever button is displayed below the message or input dialog.  (I think it might be better to rework the UI for those and put the button within the scrolling area instead of aligned at the bottom of the screen, with the scrolling area tiled above it.)

I plan on open sourcing Kit v2 so anyone can help me with the project, add new kits, and tell me there was a better way to create an API for adding kits to the builder.  Well, anyway, I'm not sure I like how I moved most of the content to the sidebar on the left, but I wanted to get it out of little balloon on the map.

  • Upvote 1

Share this post

Link to post

> images appear above text in messages and inputs

Yes, I've noticed that, the easy way as well as the hard way. Time, of course, or a lack of it, is one of my concerns at the moment. However, I did plan to try shorter images (i.e., banner style or something) to see how they'll display. But I agree, to have buttons and inputs scroll would be ideal.

> open sourcing Kit v2

Now THAT should be interesting.

> I moved most of the content to the sidebar on the left... I wanted to get it out of little balloon on the map.

In my experience, usability and gui's are a mixed bag of things. You can't please everybody and what one person finds intuitive others will find confusing. It's hard to strike that perfect balance.

I had no trouble with the current setup. It took me a couple shots to figure out where and when text would show up when playing the cartridge but that was no big deal, nothing to complain about. And I'm sure the set up was designed to minimize the amount of help/instruction required - something I find is lacking in most other areas of Wherigo. Or, to say it another way, the learning curve getting into Wherigo is steep but the Kit's interface keeps things manageable. So, if you've continued in this direction I'm sure it'll be helpful no matter where it's located.



Share this post

Link to post

Next related question. I just read that Wherigo uses the JPG image format. I uploaded PNG but the Kit was happy to convert them to JPG. So far so good. Unfortunately, somewhere along the line, a high level of compression is introduced. Due to the nature of the images I used, this was not a problem in most cases... however, in a few the results are pretty bad.

Note. I used images 230x170 so the distortion and artefacting should not be the result of resizing. Compression is the villain here.

So, my question is: when or where does the compression take place - during the conversion, in Kit, or in the whereyougo app? Secondly, would there be an advantage to uploading JPG over PNG. I used PNG because I reasoned it was fairly lossless. Are JPG images subjected to the same processing during upload and/or play? And in either case, is there any control over the amount of compression used?

Thank you.

Edited by 10011010
added specs

Share this post

Link to post

Good question.  I think you might be able to get around to checking faster than I can--you have an example to work with and are probably not pressed for time.  You can check to see if it's Kit that's doing the compression by downloading the GWZ/zip file from Kit.  That's what Kit creates.  If the artefacting is not there, it's likely the player app unless you're feeding the cartridge through another builder, at which point there's another potential link in the chain to check.  I doubt Groundspeak's Wherigo site performs any image resizing, but I can check for that by downloading a cartridge and extracting the images from the GWC.

As for PNG versus JPG, here's some information.  To my knowledge, the Garmin Wherigo Players only support JPG.  I think most or all the cell phone player apps support PNG.  Because Kit is trying to create cartridges compatible with the widest range of player apps, it must use JPG.  The PNG to JPG does happen through Kit.  Also, using JPG saves some money on hosting Kit.

I don't remember how aggressive Kit is in its compression, so I'll be sure to check Kit v1 when I'm working on Kit v2 tonight.  (I wasn't available over the weekend because I was working on Kit v2.  It'll be open source, so people will be able to check what it's doing and contribute to Kit.)  I'll also consider making an override in Kit v2 so people can use PNG images if they understand the consequences.  Considering I'm using a nullable GUID with an assumed JPG file extension in Kit, I'll have to refactor several things so I can use different file extensions.

Share this post

Link to post

I'd already replaced the worst offenders with images less prone to artefacting so I'm in generally good shape. However, for the sake of thoroughness, I had a look at the gwz file. Unfortunately, I have sad news to report. Looks like Kit is introducing at least 'some' of the problem (I do not over-look the fact that stretching a 230 pixel image to span 800+ pixels is bound to have some issues too).

I have not been using another builder. But it's good to know Groundspeak is unlikely to add to the problem.

I 'have' been reading the Earwigo Wiki to extend my understanding of what is going on with builders in general. However, at present my plan is to complete what I'm working on with Kit. It's highly unlikely I'll ever use urwigo because of its reliance on the dot net framework. And while I may have considered trying out earwigo I will probably hold off for v2 (since I know it's being actively developed).

Regarding PNG versus JPG, my vote goes to leave well enough alone. As I mentioned, I used PNG because of its properties. Had I known of garmin proprietary formats I probably would have went with JPG to begin with, if for no other reason than eliminating the need for conversion - you know, fewer moving parts. I see no percentage in overriding conversion to JPG if it means a failure to work in some devices.

For whatever it might be worth, I have found compression of just eight per-cent (numbers vary among paint programs) reduces file size a significant amount but keeps image quality more than reasonable.

And an off-topic observation. It's my understanding that the creation of Zone 1 also marks the starting point for the Wherigo. But it seems if I later move or alter zone one the starting point is not updated with it. I say this because the Wherigo 'logo' marking the beginning of my cartridge in the player is now outside the zone boundary. It would be nice to have a bull's-eye.

Lastly, I have half a mind to offer to beta test v2 but I trust you have volunteers aplenty and I don't have anything particular in mind ready to go (yet). I might add, tho, that if v2 will have more features than v1 then you might consider keeping both online at the same time. But at this stage you'd know better than I would.

Thanks for checking in. Mucho appreciato.


Share this post

Link to post

I'll see what I can do to get Kit v1 to be nicer to graphics when it converts them.  When I developed the Wherigo Foundation site after Kit, I came across a very nice library for image manipulation.  I'll see about adding it to both Kit v1 and v2.

I'll also fix the issue about the cartridge's location always being the first zone.  I think, for Kit v2, I might add the option to define a starting location.  If one is chosen, Kit uses that.  If not, it'll use the first zone.

For Kit v2, I've shuffled around things and added a ton of help items to tell people what everything does.  I'm not too certain I like moving everything to the sidebar on the left, but doing so gives me a little more room and flexibility to do certain things.  I haven't solicited feedback from people just yet.  I have the full back end complete.  It's all rewritten except for the part that converts the Kit cartridge to the lua script.  I remember how difficult that was the first time I wrote it, so I'm leaving it alone.  (It's a special type of torture because I present Kit as if the Wherigo Engine waits for the next action when it doesn't, so I had to write the conversion.)

I do want to create what I guess I'd call a freeform kit for Kit, which amounts to making whatever cartridge you want.  I've also been asked about making one for the reverse Wherigo, which is odd since you just need to go out into the field, run the cartridge, and get the three numbers it provides.  I should also offer kits for Whack-A-Lackey, Battleship, and my other arcade cartridges.

Anyway, I posted a link to what I have of Kit v2 last night, along with some disclaimers.  When I'm further along, I'll formally solicit feedback, but you can see a lot right now.  I'm hoping someone will tell me sooner or later if I'm not going in the right direction.  There's a lot more work left.  I think I'll be occupied for most of the year, though I should really take a break soon and catch up on logging caches.

  • Upvote 1

Share this post

Link to post

I updated Wherigo\\kit a few minutes ago.  I did a few things around images: 1) the maximum image size is now doubled to 500x700 (the player apps should be able to cope or I'm in trouble), 2) Kit is now using the same image resizer as the Wherigo Foundation site, 3) all image resizing is now done at 100 quality, and 4) PNGs are converted through the same image resizer library.

Please upload your pictures again and check the quality when you download a zip file of your cartridge.

  • Upvote 1

Share this post

Link to post

Okay, I'll spend some time with it tonight. I'll stick with my original PNGs for the time being just to check the changes. I'll report back in a bit.

Share this post

Link to post

My procedure.

1. "Use none" in all image spots. Save and close the browser.

2. Upload everything again using the original PNGs including those we had problems with (not their replacements). Save and browse to the list page where I could download the gwz.

3. Unzip the gwz and have a look.

First impressions are very good. The artefacting I saw before is not present now.

The sun is setting as I type so I won't be able to test in the field today. And unfortunately due to non-geo commitments (yeah, I know - shame on me) I won't be able to check until day after tomorrow. But I'll leave everything as it is and will report back when I do.


Re: 500x700

All my images have been 230 pixels wide. My reasoning has been that if garmin devices call for it, then no sense denying garmin owners the full experience. And working to the 230 width should mean no harm from resizing that doesn't get done.

Now. I'm using the whereyougo app on an 10" LG tablet. I can confirm that whereyougo up-sizes the image to fit the screen. So far so good.

But once upon a time... I attempted a test cartridge using the Groundspeak builder. This was just three zones around the house - back yard, front yard, drive-way sort of thing. For that one, not knowing any better, I created 800x1280 images to fit my set up (whereyougo on LG tablet). The only gwc file I have left from that effort has only one zone but the large image displays more or less correctly. But if memory serves, and it probably doesn't, I recall some of the images not fitting the screen. They were too large, not scaled down.

Whether or not the Groundspeak builder processed the images I couldn't really say, but judging from the size of the gwc file (almost 3mbs) I'd hazard it didn't do anything.

If my one remaining gwc from the first round of testing is any indication, and the frailty of human memory, I'm guessing whereyougo upsizes to fit but it doesn't downsize/constrain.

All of which is to say I wouldn't object to keeping maximum images sizes at the 230 pixel standard known to work on all devices.

It would be interesting to poll visitors to find out the most popular devices used for Wherigo. And at this point in time we don't know what, if anything, Wherigo.com does with images when it delivers files to downloaders.


Share this post

Link to post

See attachments for samples. All samples are whereyougo screenshots of 230 pixel images stretched to fit the screen. All samples have the bad side to the left, the good side to the right.

Sample 1 - Question Mark - This is a zoomed-in perspective for sake of showing the effect of artefacting via high compression. The left side, from the old uploader, was shaky enough I wouldn't use it. The right side is the same image but uploaded after you made changes. The visible pixelation on the right stems mostly from the high magnification; that is, the 1:1 display in the app on the tablet is clear enough to use.

The point here is that JPG compression can be pretty brutal on a plain surfaces. When it's in a diagram or cartoon it can ruin the image. For example...

Sample 2 - baft-out bushwalker - The pre-change upload on the left is clear enough you can tell what it is but at the same time it certainly isn't pretty. The one on the right gives evidence of magnifying pixelation but is superior many fold compared to the old one.

The point here is that the busier the original image the more it can withstand compression processing... within reason. For example...

Sample 3 - two photographs - The photo of military equipment on the left came from a Wherigo I did yesterday. Very clearly it was a poor image to begin with - and the builder used (probably not \\kit) did nothing to help the image. By the way, the comic-strip images in that cartridge were nothing short of terrible. Anyway, the water image on the right is intended for the project I'm currently working on. The foreground ripples in the water can survive several more steps of magnification.

It is my humble view that Wherigo images should be no worse than those on the right side of my samples here. They should be better whenever possible. (And note, the water image is still only 230 pixels in width. If garmin does NOT resize to fit, this demonstrates the small image is acceptable. There is no need to go larger and risk taking away from those who use garmin).

Anyway, if you are concerned about the amount of space uncompressed images use on your server, you can probably get away with a few per-cent without significant loss. How the module works/is configured will determine how far you can go. In my experience, two per-cent compression, for example, will yield more than two per-cent file size reduction... so that even minor compression can reduce file sizes quite a bit.


Sample 1.jpg

Sample 2.jpg

Sample 3.jpg

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 3