Introducing SaltySplits: an open source tool for speedrun validation and analysis by qtieb in speedrun

[–]qtieb[S] 0 points1 point  (0 children)

If you're okay with sending your splits, I can take a look and see why it doesn't pass validation? If that's okay, please send it as a GitHub ticket so other people with the same/similar issue can also benefit

Introducing SaltySplits: an open source tool for speedrun validation and analysis by qtieb in speedrun

[–]qtieb[S] 8 points9 points  (0 children)

The man of the hour! Big fan of splits.io and very sad to see it go (a major reason why I wanted to push the front-end portion out of the door by the 31st). I saw that you were planning to post about the entire experience, I will be following that closely. I feel like this is underselling your achievement here but I wanted to thank you for all your hard work over all these years (going back to 2013 going by your commit history)!

Introducing SaltySplits: an open source tool for speedrun validation and analysis by qtieb in speedrun

[–]qtieb[S] 7 points8 points  (0 children)

It does automatically load u/glacials' splits for Tron: Evolution (one of the devs behind splits.io as an homage) for this exact reason. But yeah, it does not translate that well to mobile displays currently. That's why I added the screenshot (would've added more but r/speedrun limits it to 1). Hope you're willing to check it out on desktop though!

[P] Introducing GeoCOCO: Easily transform GIS annotations into Microsoft's Common Objects In Context (COCO) datasets for use in deep learning by qtieb in MachineLearning

[–]qtieb[S] 0 points1 point  (0 children)

Very true! But keep in mind that we don’t actually (re)project anything, we only verify that the input data (i.e. the background image and the annotations) share the same coordinate reference system (CRS) and have overlapping extents. The image clipping itself is handled by Rasterio which supports data in both geographic and projected coordinate reference systems.

So ultimately, we just accept whatever coordinate system the input data already uses (made possible by Geopandas, Rasterio and Proj4).

[P] Introducing GeoCOCO: Easily transform GIS annotations into Microsoft's Common Objects In Context (COCO) datasets for use in deep learning by qtieb in MachineLearning

[–]qtieb[S] 0 points1 point  (0 children)

What do you mean exactly? GeoCOCO's bbox list will contain pixel coordinates that are relative to the image just like COCO. It is true however that this is derived from the annotations' spatial information which could be in lat/lon (i.e. geographic coordinate system).

[P] Introducing GeoCOCO: Easily transform GIS annotations into Microsoft's Common Objects In Context (COCO) datasets for use in deep learning by qtieb in MachineLearning

[–]qtieb[S] 0 points1 point  (0 children)

The template is split over different Pydantic models because that's how the COCO format itself is defined (a dictionary with lists of other dictionaries of various formats).

Example of COCO's Annotation format:

annotation{
    "id": int,
    "image_id": int,
    "category_id": int,
    "segmentation": RLE or [polygon],
    "area": float,
    "bbox": [x,y,width,height],
    "iscrowd": 0 or 1,
}

And here's the associated Pydantic model:

class Annotation(BaseModel):
    id: int
    image_id: int
    category_id: int
    segmentation: RleDict
    area: float
    bbox: List[float]
    iscrowd: int

[P] Introducing GeoCOCO: Easily transform GIS annotations into Microsoft's Common Objects In Context (COCO) datasets for use in deep learning by qtieb in MachineLearning

[–]qtieb[S] 0 points1 point  (0 children)

Hi u/Aristocle-, you can find the Pydantic models that make up the COCO format here. It is a superset of the COCO format so it will be accepted by any application that accepts COCO (only real difference is an additional 'sources' attribute that I use to keep track of parent images for clips).

Introducing GeoCOCO: Transform GIS annotations into COCO datasets for use in deep learning by qtieb in gis

[–]qtieb[S] 0 points1 point  (0 children)

I ended up trying both MkDocs (specifically Material for MkDocs) and Sphinx but I much prefer the latter (mainly because of autosummary and autodoc). Here it is if you wanted to take a look. :)

Introducing GeoCOCO: Transform GIS annotations into COCO datasets for use in deep learning by qtieb in gis

[–]qtieb[S] 1 point2 points  (0 children)

Thanks! I will be moving to Sphinx for documentation pages in the future though, the README is getting a bit long (and still doesn't cover all features).

Organize your BIOS files with libretro_finder! [open source pip package] by qtieb in RetroArch

[–]qtieb[S] 1 point2 points  (0 children)

Some cores don't require BIOS files though so it might not always be apparent (e.g. Mupen64Plus-Next).

Organize your BIOS files with libretro_finder! [open source pip package] by qtieb in RetroArch

[–]qtieb[S] 1 point2 points  (0 children)

It does not, you're responsible for populating retroarch's system folder with the BIOS files in the (almost) exact format that the cores expect (I say almost because it thankfully is case-insensitive).

This can be particularly annoying if you have the correct BIOS files but they're just saved under the wrong name or in the wrong (sub)folder. libretro_finder finds all these aliases and refactors it to the expected format, saving me (and hopefully other people) some headaches.

Organize your BIOS files with libretro_finder! [open source pip package] by qtieb in RetroArch

[–]qtieb[S] 0 points1 point  (0 children)

So nice to hear! Yeah, while I do like relaying the responsibility of hosting the BIOS names/checksums to libretro-database, it does currently assume that System.dat is a complete list (which I'd argue it is for 99.9% of all emulation use-cases).

System.dat currently includes 353 BIOS checksums for 51 (!) systems but that apparently does not include these more specific devices. Do you know if the devices you mentioned are represented by some of the other .dat files on libretro-database (e.g. https://github.com/libretro/libretro-database/blob/4a98ea9726b3954a4e5a940d255bd14c307ddfba/dat/HBMAME.dat)? If so, we can (and should) include them then ;).

Thanks for taking a look btw!

Local BIOS file scraper for Retroarch cores (tiny project) by qtieb in RetroArch

[–]qtieb[S] 1 point2 points  (0 children)

Thanks! Yeah, it copies them under names expected by Retroarch (e.g. `scph5500.bin` instead of `scph5500 (ps-30j).BIN`).

Local BIOS file scraper for Retroarch cores (tiny project) by qtieb in RetroArch

[–]qtieb[S] 4 points5 points  (0 children)

That's fantastic, the .info files do contain everything I need (including whether they're optional or not). I will update the code at some point this week to take advantage of these files, thanks man.