With current state of perspective imagery extension, we can define :
sensor_array_dimensions : full panorama width and height
field_of_view and focal_length could allow to compute back cropped area width (but that may be complicated for end users)
We can't however define a vertical cropped range, nor define horizontal/vertical offset compared to full panorama image center.
Do you think this would make sense to extend this extension definition to handle this kind of cases ? May we adopt a scheme like :
sensor_array_dimensions : [ full width, full height ]
visible_area : [ px distance to left, px distance to top, px distance to right, px distance to bottom ]
The name visible_area might not be the best, a name suggesting "you'll only find a subset of pixels really defined in downloadable assets, which is at this space in pixel matrix" would be better.
Hello,
We are working in the Panoramax / GeoVisio initiative on supporting cropped 360° panorama pictures (discussion started here). These are commonly defined through 6 variables :
With current state of perspective imagery extension, we can define :
sensor_array_dimensions: full panorama width and heightfield_of_viewandfocal_lengthcould allow to compute back cropped area width (but that may be complicated for end users)We can't however define a vertical cropped range, nor define horizontal/vertical offset compared to full panorama image center.
Do you think this would make sense to extend this extension definition to handle this kind of cases ? May we adopt a scheme like :
sensor_array_dimensions: [ full width, full height ]visible_area: [ px distance to left, px distance to top, px distance to right, px distance to bottom ]The name
visible_areamight not be the best, a name suggesting "you'll only find a subset of pixels really defined in downloadable assets, which is at this space in pixel matrix" would be better.Best regards.