“OPF is a fully open and free specification, which means that it is now possible to store, exchange, and collaborate on photogrammetric data between different parties and software products - even if the software is developed by different companies”
I think it would be nice to have a free, open format to interchange projects between different software products (in the future). Curious about your thoughts.
I have the same read. I’m not clear on the overall play – but a single proprietary entity releasing and controlling an open standard is rarely for benevolent reasons in the long term, even when it is well intentioned at the beginning as it is entirely subject to whatever leadership of that entity decides.
I am an R&D manager at Pix4D and I currently lead the work on this topic.
I fully understand your concerns, and it’s natural to feel this way, given that the Open Photogrammetry Format (OPF) is proposed by a single proprietary entity. However, I want to reassure you that our motivations behind this initiative are for the common good of the photogrammetry field.
We see the need for an open, free, and standard format to foster greater collaboration and data exchange across diverse software products, and help the academic and R&D communities use photogrammetry output easily. OPF and its tooling are published under a permissive license, and the specification is accessible to everyone, and this is only starting point (we have to start somewhere!), and we know it can be improved!
Your comparison to the ESRI and sqlite3 situation is valid, but it’s not our intention. In fact, during all the development we have paid special attention so that as much as we could think of is clearly, unambiguously specified, in order to precisely avoid to create a mess of incompatible implementations. I am aware that like all first versions of anything it’s unlikely to be perfect just yet (and there is definitely more features to add to the format!), If you find that things are unclear or underspecified in some places, we’d love to hear you and find a way to fix the situation.
We’re also well aware of the need for broader participation in this process. We’re inviting feedback from everyone, including our counterparts at Agisoft, Epic, Meta, and other stakeholders, we’d of course love to hear from Open Drone Maps too! In the future we will consider how to involve interested parties more directly in the process, and if another structure may be more beneficial for this project.
At the end of the day, this initiative’s success depends on collective contribution and we do hope to foster a community-led standard, not a Pix4D-owned one. I hope we can embark on this journey together and make the field of photogrammetry more accessible and collaborative.
Please feel free to ask further questions or provide your feedback, we value your participation!
What is the format supposed to contain?
Thanks for your interest,
An OPF project is made of multiple files:
A project file: it’s basically a “container”, in the sense that it give the link to all the other files
Cameras
Camera list: a list of all images of that are used in the OPF project, and an association with an image ID (image file path ↔ UID)
Input Cameras: prior knowledge about the camera, (may be derived from the EXIF geotag for example), or from some database of priors on distortion coefficients and sensor properties
Projected Cameras: input cameras data with pose expressed in the processing CRS
Calibrated Cameras: optimised camera pose and parameters, as a result of photogrammetric calibration for example
Control points: can represent “manual tie points” between images, GCPs, check points, scale and orientation constraints. This is meant as an additional input to calibration if available.
Geo-referencing information: information about the scene reference frame, coordinate system, etc.
Calibration
Calibrated Cameras (already mentionned)
Calibrated control points (the control points, after calibration, for example the triangulated position of a GCP).
GPS bias (the bias between the result of calibration and the geolocation information, as a rigid transform.
Point cloud and tracks
OPF proposed a very nice unified format for storing point clouds as well as tracks (automatic tie points, keypoints, or whatever you call them)
Based on GLTF (so super easy to read with a compatible GlTF reader
With (specified) extensions to represent:
A link between a 3D point on the source image
For tracks the position, scale of the feature on the 2D image
An octree-like spatial partitionning, which allows both effective processing and fast rendering
Because it’s based on GlTF it’s also extensible to add additional information that other may need, eg point cloud classes, etc. etc.
A feature I like about OPF is it’s extensibility, based on similar concept to what is in GlTF or Cesium 3D tiles, so custom needs can be accommodated easily.
We have some support for camera rigs, multispectral data, etc.
In addition we are cooking some extensions to OPF, that will include things like, processing areas, depth maps (computed or from depth sensors), planes, and mores.
In the future we would like to add more photogrammetric output as addition OPF items, eg DSM/Ortho/Mesh based on open standards such as COG tiff etc.
Thanks for weighing in. I appreciate the note and transparency.
It is very useful to have the project lead reach out. To clarify, this isn’t a matter of how anyone here feels about the project. Nor is the matter about the staff and representatives of Pix4D’s feelings about the purpose and intent of the project. I am sure you feel this is a benevolent act establishing a commons for the greater good. Perhaps it will help clarify my position if I’ll quote myself back in response (emphasis added for the sake of this conversation):
I cannot know intent, nor can any of us. But, I have been in these various industries long enough to know that stated benevolence now does not guarantee benevolence in the future.
The nature of participation: necessary vs. sufficient controls in commons systems
Feedback is necessary but not sufficient for an open standard, see comments above from Saijin_Naib on the USB standard.
You cannot foster a community-led standard by not first engaging the community in the standard. This is, at this stage, inherently not a community-led standard. Feedback is necessary but not sufficient. Community-led means the community has leadership stakes in the standard. As currently strucutred, it might become a community-informed standard, but not community led.
If you want to understand how to facilitate successful commons, then you cannot go wrong starting with the writings and thoughts of Elinor Ostrom:
We can summarize by recognizing that the current approach violated (at least) the following italicised principles:
Define clear group boundaries.
Match rules governing use of common goods to local needs and conditions.
Ensure that those affected by the rules can participate in modifying the rules.
Make sure the rule-making rights of community members are respected by outside authorities.
Develop a system, carried out by community members, for monitoring members’ behavior.
Use graduated sanctions for rule violators.
Provide accessible, low-cost means for dispute resolution.
Build responsibility for governing the common resource in nested tiers from the lowest level up to the entire interconnected system.
There isn’t a perfect 1:1 analogy for translating these principles to digital commons, for which resource use is generally not the primary problem, but rather enclosure of commons and the threat of future enclosure of commons, especially through the use of liberal licenses and copyright monopoly are. Nevertheless, Ostrom’s writings are a good starting point for these conversations.
Side note: as a Francophone entity, you should probably include MicMac in any community-led efforts, especially as I understand most of the photogrammetry ecosystem to be a direct beneficiary of MicMac’s liberally licensed software ecosystem.
Summary
In summary: change your leadership stakes or your project does not bear the markings of a community led project. Neither good intent nor expression of good intent now from Pix4D staff and leadership guarantees good intent later, so the nature of leadership on any commons-based standard matters. Licensing of the standard matters as well as proper licensing protects against future commons enclosure. I would strongly recommend not using a liberally-licensed standard as this facilitates future forking of the standard, potentially leading to the problems noted with the sqllite standard Saijin_Naib mentions above.
Side note, even if the project structures change, changes do not guarantee participation of OpenDroneMap, as that would also depend on available capacity, interest, and value that it provides our community of users, developers, and data beneficiaries.
That said, I do hope the standard is successful in all the ways it can be: community led, sufficiently protected against commons enclosure, and as a result of correct structures and management providing a well-governed, stable, and perpetually available approach that truly supports research collaboration across ecosystems.
Thanks again for weighing in here to clarify current intent and structures and starting the conversation.
Postscript:
I’m going to assume best intent and simply correct the spelling to OpenDroneMap, no spaces, no s. But, note that this is not a good look for engagement. How sentences are structured, and how projects are spelled matter when engaging with communities.
I also recommend including OpenDroneMap (and MicMac!) explicitly in the list of potential leads of an open standard and not as an afterthought. An open photogrammetry standard that is not explicitly co-lead by any of the existing leaders in the ecosystem is a strange oversight.
Otherwise your post is quite welcoming and engaging. I am obliged to assume good intent, so the above is a small point I wanted to highlight and does not require nor invite any response.
To add to that: if the intent is truly a community-led standard, I’m of the opinion that one should not announce the standard and then seek feedback about the standard. You propose a draft, open a period of discussion from stakeholders, then finalize it. COPC is an example of how this was done quite well.
It’s not too late, but at a minimum Pix3D should mark the spec as a draft and have a window period available for discussing/changing the draft based on stakeholders feedback (aside from the other points highlighted by @smathermather).
Otherwise just call it the “Pix4D Photogrammetry Format”, it will still be useful for others in the field.