Hacker News new | past | comments | ask | show | jobs | submit | more pierotofy's comments login

> On the consumer side, open source is inherently for enthusiasts

Consumers care about whether software works for their needs, they don't care whether it's proprietary or open source. And often there's also the factor of price.

The problem with FOSS is that too few developers have the willingness to ask for money directly, like selling binaries instead of sponsorships/donations which have terrible conversion rates. https://piero.dev/2023/02/foss-funding-chapter-2-binaries/

Other monetization methods proposed in the article just don't scale, aside from the running a SaaS business which is 100% a great way to fund work.


> The problem with FOSS is that too few developers have the willingness to ask for money directly, like selling binaries instead of sponsorships/donations

While I agree with you, this leads to confusion: the naive users from your first sentence then say, that they thought it is open source, why the author asks for money?

This can be seen for example with android apps, that have GPL-licensed sources on Github, free binaries in F-droid and paid binaries in Google Apps Store. So basically the author is charging only a convenience fee, but this confusion still arises.


.. because asking for money generally fails.. Huge "shareware" projects garnered a total of five figures kind of money, ever. Plenty of projects fail to get a thousand dollars, ever. The market is filled with success stories, to you dont see the misery of the failed ones.. especially when the stakes get large, such as phone monthly revenues, or ad streams on major consumer brands. The management that grabs the reigns there are hired specifically to push others out and maximize gains.


People who buy things expect quality, service, and interoperability. In my experience, FOSS projects often have the quality, but they lack service (they may ignore suggestions or unusual bugs). Interoperability is usually left as an exercise for the user.

If a user buys a binary, the seller should expect demands for work or a refund. But people don't expect refunds for donations. And it takes a lot of money to attach strings to a donation.


all valid, until the ubiquity of modern net use. Many people dont make individual purchases, instead they subscribe to bundled services which in turn gate-keep at a company store. The amounts of money moving in walled-gardens now are vastly larger than any individual products ever saw.


As I understand the proposal is that the source code is indeed open source and available freely but you have to pay to download the binary?

It can be done. Some companies do things along these lines. But, especially at the consumer level, that introduces a lot of adoption friction. I imagine most users will close the page and move on once they saw they needed to build a binary themselves to try something out for free.


OpenMapTiles is open source just as much as OpenAI is open source.


While it might be nice if there we pre-rendered tiles available for download, and openmaptiles.org constantly steers users to "buy now" pages, instead of offering a simple button to the self-service docs, they do in fact offer a significant amount of documentation on how to generate and serve your own tiles[1], including a page with fairly step-by-step instructions on how to create a tileset "from scratch" without sending them a cent[2].

1. https://openmaptiles.org/docs/ 2. https://openmaptiles.org/docs/generate/generate-openmaptiles...


Perhaps this will signal that it's time to start training these generative AI algorithms on freely licensed data instead of grabbing whatever is available.


Why?


Direct knowledge of the lens distortion model and complete control of the image generation, with perfect knowledge and use of the associated metadata tags, can certainly give an engine a leg up in some cases. One example I can think of is the Parrot Sequoia which is a camera that works OK-ish in ODM, but works flawlessly with Pix4D (which is owned by Parrot).


But none of that is private data, right? It feels like "tuning". Surely one could characterise Sequoia to improve the camera model, and I doubt they encrypt the exif data, do they? Also Sequoia is a bit of a special example here, that most likely has been carefully tuned by Pix4D. But DJI most probably does nothing for Pix4D that ODM couldn't access.

Not criticising ODM (I love OpenSfM and ODM), on the contrary: I feel like those are not fundamental limitations of ODM, and one could put the work of improving support for specific cameras without the need for proprietary information available only to Parrot employees.

Or am I missing something?


EXIF data is not encrypted, but often times is not documented (or documented well). DJI has many differences between models (even between firmware versions). They also sell DJI Terra, which is their own photogrammetry solution.

The point being that you are correct, these are not limitations of ODM, but in some cases it does give vendors a head start (a leg up) in implementing good support for certain cameras, especially multispectral cameras like the Sequoia.


Pretty much any camera (even multiple cameras), from any orientation (no gimbal required). Also works with your cellphone camera or DSLR camera. Just try not to change the focus between shots too much. DJI models are well supported.


Are DJI models the only ones supported?


Nop, you can use pretty much any drone camera.


Glad you like it! :) Is this the odm_orthophoto_render.tif file? If so, that's normal. That file is not a higher resolution image, it's just an intermediate file that doesn't have georeferencing and compression. The final georeferenced image, odm_orthophoto.tif, by default is cropped to the bounds of the model and you can disable that by passing "--crop 0". The two images will look identical without crop.


Very interesting, thank you! i mostly drone as a hobby to get some interesting shots, so this is my first foray into using it to do anything like this. Indeed I am talking about odm_orthophoto_render.tif, I assumed it was the higher resolution one because of the size (about 3x the size of the other two), and qGIS was not treating odm_orthophoto.tif well, but after closer inspection looks like qGIS just didn't like odm_orthophoto.tif because it was having trouble loading it full resolution, but it did end up loading it correctly if I gave it a few more moments to load, and works really well!

Thanks so much for the ad hoc tech help, will definitely be playing with this more!


Welcome!

You can also use --build-overviews for speeding up load times in QGIS or --cog for generating Cloud Optimized GeoTIFFs that both open fast in QGIS and can be streamed fast over HTTP.



Lovely! Try bumping --mesh-octree-depth by 1 or 2 for sharper models. Also if you're capturing photos in motion, definitely enable --rolling-shutter which will help compensate for the rolling shutter distortion of the DJI Mini 2's camera (it will take a bit longer to process though).


How does it compensate for rolling shutter? Out of curiosity :)


It implements the method outlined in "A two-step approach for the correction of rolling shutter distortion in UAV photogrammetry" by Y. Zhou and others: https://www.sciencedirect.com/science/article/abs/pii/S09242...

The Python code is probably easier to understand: https://github.com/OpenDroneMap/OpenSfM/blob/287/opensfm/act...



Time to read up on this and AWS Batch!


Here's also a few example maps compared side by side with other software: https://opendronemap.github.io/UAVArena/


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: