RadioVIS3D 0.0.3 DRAFT now available

[Paolo]

Dear colleauges,
please find the draft proposal for the RadioVIS3D technical specification (r. 0.0.3). RadioVIS3D extends RadioVIS allowing both 3D and 2D images slideshows. 

The present draft is more concise than the previous one, and only the differences between the two specs are pointed out. Please find it in RadioVIS3D003 (PDF) or RadioVIS3D003 (docx).

Outstanding points to check:

- consistency and coherence with RadioVIS specification (Ben?)

- image formats: industry standard JPS, standard PNS and MPO are allowed. Are there (sustained) objections?

- application discovery: similar to RadioVIS, with SRV "radiovis3d" for STOMP and "radiovis3d-http" for HTTP

- creation of new topic "image3d", supporting both 3D and 2D images

- RadioVIS3D http request syntax: /radiodns/vis3d/vis3d.json?topic=... 

Please feel free to contribute with ideas, comments and modifications.

Kind regards
Paolo Casagranda

[Paolo]

It has been brought to my attention (thank you Ben) that the modification of the RadioVIS http request syntax is not necessary.

Infact, topic names are different for RadioVIS (image) and RadioVIS3D (image3d).

So the request can be put in this form: /radiodns/vis/vis.json?topic=...

The modification will be included in the next draft.

Kind regards

Paolo

[Russo Francesco]

Hi Paolo,

I’ve two observation:

·         in Radio3DVIS document chapter 6, where there is the description of the slide associated with the provided url, is necessary to include the new 3D image formats (JPS, PNS, MPO).

·         In chapter 5.2, I think the JSON response format can preserve the RadioVIS header parameter names. In case of “show” message, the receiver check if the JSON frame refers to a 3D image by reading the body file extension in the JSON body parameter (JPS, PNS, MPO). In case of  “text” message, there is no difference between RadioVIS and RadioVIS3D.

 

Kind regards

Francesco

 

 

Da: radiovis-3d...@googlegroups.com [mailto:radiovis-3d...@googlegroups.com] Per conto di Paolo
Inviato: giovedì 19 aprile 2012 14:00
A: radiovis-3d...@googlegroups.com
Oggetto: Re: RadioVIS3D 0.0.3 DRAFT now available

 

---

Questa e-mail, ed i suoi eventuali allegati, contengono informazioni confidenziali e riservate.

Se avete ricevuto questa comunicazione per errore non  utilizzatene il contenuto e non portatelo a conoscenza di alcuno. Siete inoltre pregati di eliminarla dalla vostra casella e avvisare il mittente.

E' da rilevare inoltre che l'attuale infrastruttura tecnologica non puo' garantire l'autenticita' del mittente, ne' tantomeno l'integrita' dei contenuti.

Opinioni, conclusioni ed altre informazioni contenute nel messaggio possono rappresentare punti di vista personali a meno di diversa esplicita indicazione autorizzata.

---

[Paolo]

Good points, thank you.

- I'm adding the reference to image formats in chapter 6

- The JSON Header Parameter names can be the same of RadioVIS. However, I think we cannot rely on image extensions only to identify image types. The url doesn't necessarily include image type (e.g. http://example.com/example/image/ can be an image). HTTP 1.1 defines the response header "Content-Type", we should use it on our back-end. However for 3D images there's no official IANA registered MIME Type, AFAIK.

On the Internet I've found references with "image/x-jps" or "image/jps" for JPS, "image/pns" for PNS and "image/mpo" for MPO images, however there's no a IANA entry. Interesting enough, there's the same problem with the RadioVIS APNG image format.

The standard behaviour for a browser is to look for a Content-Type; if not present, 'the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream" '

The issue affects JPS specially, because it's generally composed of two side-by-side images, without attributes specifying it's a stereo image (PNS and MPO images have such attributes).

I propose the following solution. We use the unofficial MIME Types for JPS, PNS and MPO, and the "Content-Type" parameter in the HTTP response header MUST be set to "image/jps", "image/pns" or "image/mpo".

Kind regards

Paolo