On the ONNX choice: it's fairly lightweight to install and runs decently fast on a CPU. Other existing libraries forced me to install torch or tensorflow.
Does the library inherently handle threading and concurrency to make use of beefier CPUs, or does that need to be coded in to the users Python script? I'm asking as I'll most likely have a go at extending a current project with a custom model or two and am tossing up where to put money in PC hardware. I suspect I'll need to invest both in GPU and CPU, the former for training, and the latter because not everything runs on GPU.
The inference process via ONNX (where most of the CPU time is spent) is multi-threaded. I briefly explored adding multiprocess capabilities for the tiling/downsampling/result merging parts of the codebase, but the improvements were marginal with a trivial implementation, so I didn't explore further (although I'm sure it could be improved).
Hey, I wrote GeoDeep, what a cool writeup! Glad someone tried to run these on satellite imagery. I did most of my testing on drone derived orthophotos, so was curious to see how it would perform with lower resolution images. Some models like the car model seem like they did poorly. I suspect it's probably because the ground sampling distance (GSD) was in the 35-56 cm/px range, whereas the car model was trained for 10 cm/px. GeoDeep can downscale the input to match the model's input resolution, but can't (currently) upscale it.
Very cool project! It works about as well as I would expect if you naively take a drone derived model and apply it to satellite images, but I am sure a bit of fine-tuning would improve performance.
Good job on the ease of use front: it does look really easy to use.
Thankfully this is also right in the window of much of what's being captured from aircraft in many places, too. It's not uncommon to find 7.5 - 15cm / px imagery from public agencies around the globe. Even some more philanthropic acquisitions are acquiring within this envelope.
Here's what I'd want from accounting software; a credible exit strategy that if you go bankrupt or decide that you need to tweak your pricing too much, I can take my data and run it on my own infrastructure. Have you thought about an open source business model? Even just offer the basic platform as open source (e.g. keep the AI stuff proprietary). Also, your pricing is too high; Xero offers a more generous starter plan for $20 / month.
> Here's what I'd want from accounting software; a credible exit strategy that if you go bankrupt or decide that you need to tweak your pricing too much, I can take my data and run it on my own infrastructure.
This is so, so critical, that I hope the founders consider it their number one priority. When you look at tools like Figma or Linear, they are often brought into a company by an individual designer or product manager for use by one small team - sometimes as an official pilot, sometimes not. It then has the option to grow organically within the company before the company switches over to it whole hog.
Accounting software obviously doesn't have that luxury. Companies absolutely need to know it will be around for years, as once the decision is made it's incredibly difficult to back out of. OP talks about this being their third pivot - my guess is that some of their original early adopters of their previous products were left a bit high and dry when they pivoted. Not at all blaming the founders for this - that's the nature of business, but also highlights why many small companies are reticent to go with an untested accounting product
I actually think the number one feature the founders should build is export to QuickBooks. For better or worse, that is the standard for small business accounting, and knowing there is a data export to QuickBooks would go a long way to assuaging a lot of potential customers' fears. It's a tactic Microsoft took in the 80s when they introduced Excel. At the time Lotus 123 was the spreadsheet standard, and they made sure Excel files could be exported to Lotus 123 so customers were less concerned about creating spreadsheets that other employees couldn't read.
Both these comments raise a great point on longevity of the product/support for migrating to other products. Everything can be exported to csv (and in an easily readable format that can be ingested by other accounting software -> QBO, Xero, etc...).
We still support customers from past pivots (albeit on maintenance mode).
It's not about the ability to migrate to other products. If I switch to your product, I need guarantees that you will not screw me over pricing 5 years down the road when you need to increase your revenue figures and that if you go out of business I can still run your software, which I've spent time learning and migrating, on my own.
I can't help but recommend an accounting software called Manager (https://www.manager.io/). You install it on your computer and its free. It's probably the most beautifully designed accounting software i have come across. They also have a cloud version.
I first came across Manager about 5 years ago and wanted my accountants to use it. However they chose Xero because they were 'used to Xero'.
I still have Manager installed and play around with it whenever i need inspiration.
The downloadable version is single user. All data is stored in an SQLITE file which you can just copy-paste if you have to move computers. You can decide where you want to store the SQLITE file. I ended up choosing a shared dropbox folder. Guess what, now i have a multi-user version. Although, i'm not sure if the Manager team would recommend this approach.
It’s a closed-source software managed by a single person who appears to be residing in Australia. I’m not surprised your accountants didn’t want to use it.
I know, I don't get the fuzz either, I've coded real-time gaussian splat renderers >7 years ago with LOD and they were able to show any kind of point cloud.
They worked with a basic 970 GTX on a big 3d screen and also on oculus dk2.
Photogrammetry struggles with certain types of materials (e.g. reflective surfaces). It's also very difficult to capture fine details (thin structures, hair). 3DGS is very good at that. And people are working on improving current shortcomings, including methods to extract meshes that we could use in traditional graphics pipelines.
3DGS is absolutely not good with non Lambertian materials..
After testing it, if fails in very basic cases. And it is normal that it fails, non Lambertian materials are not reconstructed correctly with SfM methods.
You use SfM to find the first point cloud. However SfM is based on the hypothesis that the same point 'moves' linearly in between any two views. This hypothesis is important because it allows you to match a point in two pictures, and given the distance between the two images, you can triangulate the point in space. Therefore find it's depth.
However, non-Lambertian points move non linearly in viewing space (eg a specular point depends on the viewer pose).
So, automatically, their positions in space will be false, and you'll have floating points.
Gaussian 'splats' may have the potential to render non-Lambertian stuff using for example the spherical harmonics (even if I don't think the viewer use them if I'm not mistaken). But, capturing non-Lambertian points is very difficult and an open research problem.
* Do not allow questions on GitHub issues, it's a poor place for conversations. I find Discourse or some other forum (or mailing list) a better place to do that, which allows community participation (and you can automate moderation using something like https://github.com/pierotofy/issuewhiz)
* People owe you nothing, just as you owe them nothing; you don't have to fix an issue or merge a pull request because somebody opened one.
* Try review and merge contributions, but on your own timeframe. If people have urgency, kindly invite them to get a paid support agreement.
* Don't engage in quarrels; you always have the option to ignore or ban the offenders.
While it's certainly challenging, it's not terrible, but it requires some thought and a sustainable business model, something many FOSS developers don't want to do. https://piero.dev/category/foss-funding/
