There are tools out there that can help you, such as Shoebox. But tools-recommendation questions aren't appropriate here, so instead I'll describe a basic process you could use to do this yourself.
Since the sprites in the sheet are regular (that is, they're all the same size) you can pretty easily write a program that produce a set of rectangle data in JSON based on the size of the image. You only need to give this program the image file name, the desired tile size, and the output file name. It would then:
- Load the image file, get the width and height.
- Generate a set of tiled rectangles, starting with
(0, 0, tileWidth, tileHeight), by dividing the width and height accordingly.
- Generate a placeholder name for each tile, such as
tile00 through tile24 or whatever.
- Write all that information to the output JSON file.
You can then open the file up and alter the placeholder names to match what you actually see on the sprite sheet for that section. No matter you're going to be naming the tiles yourself. You could aid yourself in this process by adding the following features to your program:
- Perform a simple check on the contents of the sprite sheet in every rectangle to see if the rectangle is empty. If so, that space can be considered empty and you can avoid generating the name or bounds information in the output.
- Write out a separate copy of the image where you've rendered a grid (in some easily visible color, like hot pink) over each tile and annotated each tile with the number used in the placeholder name. This will help you more easily match up the placeholder name with the image and help you produce better names quicker.
- In the case where you want to consider some sprites to be larger than the otherwise-mostly-regular ones (for example, the two larger trees in your example), you can manually adjust the output file to combine the bounds of the individual tiles into a larger tile, deleting the extra entries.
You can write this tool in any language, although one with built-in support for all the appropriate operations (opening PNGs, annotating them, simple math primitives like rectangles) would be ideal. C#, for example, would make a good choice and you could probably write such a thing very easily if you didn't want to just use an existing tool, if you needed to build thing into a customized asset pipeline, or if you wanted to provide extra options or UI for interaction (for example, your tool could present the sheet with the grid overlayed and allow you to drag-select rectangular regions of the base tile size that constitute "larger" sprites, like the aforementioned trees, saving you the manual fix-up step).
It's impossible to get away from having to do at least some manual work on the data (in the most general case), but simple tools like the above can help you alleviate the majority of the repetitive grunt work inherent to the process.
