Proposal for 3D extension to RadioVIS application
Paolo
Dear RadioDNS Project colleauges,
I’d like to show you a proposal we were
discussing, to understand if it would be feasible and useful.
The idea is to allow a simple method to enable 3D image
slideshows in
RadioVIS application. The method can be completely backward
compatible, both
with the applications and the device types, and patent free (as
far as I know –
of course it must be further investigated).
ￜ
In Rai there’s great attention to all the 3D production technology and to the increasing interest of customers to 3D content. 3D content is “cool” (also in a marketing sense), and devices supporting auto-stereoscopic 3D displays are more and more widespread. Think about the smart-phones already supporting good quality auto-stereoscopic 3D screens (and FM radio, of course) . So the future is already here.
RadioVIS
application doesn’t support 3D images at the moment, however the
framework is powerfull, and it could be easy to add this
feature. I think it would be a nice advertisement
for all the RadioDNS Project (ok, not for insiders, but the
success of the
technology is based on wider targets…).
Technically, to give a kick off to the discussion, in the
RadioVIS technical specification we could to create a new topic
for 3d images, so we are completely backwards compatible, maybe:
"image3d" (added to the already defined "image"). The enabled
client (e.g. HTC EVO 3D phone) should subscribe to the image3d
topic and not to the image topic. E.g.
SUBSCRIBE
destination: /topic/fm/it/5201/09210/image3d
ack: auto
Then, the server will send the right images
to the enabled 3d client. They can be also completely different
from the 2D ones, it's up to the broadcaster.
SHOW http://www.crit.rai.it/pubdir_rdns/radio2/545c5d1a-8d66-457e-ae62-5ef0ce171415.jps
I see one there’s at least one legacy issues, related to the fact that RadioVIS is based on WorldDMB Slideshow advanced profile. But perhaps this issue can be overcome with the help of the very smart RadioDNS experts.
What do you think about it?
Thank you for the attention and feedback
Kind regards
Paolo
Boštjan Jerko
Dear RadioDNS Project colleauges,
I’d like to show you a proposal we were discussing, to understand if it would be feasible and useful. The idea is to allow a simple method to enable 3D image slideshows in RadioVIS application. The method can be completely backward compatible, both with the applications and the device types, and patent free (as far as I know – of course it must be further investigated).
In Rai there’s great attention to all the 3D production technology and to the increasing interest of customers to 3D content. 3D content is “cool” (also in a marketing sense), and devices supporting auto-stereoscopic 3D displays are more and more widespread. Think about the smart-phones already supporting good quality auto-stereoscopic 3D screens (and FM radio, of course) . So the future is already here.
Paolo
currently, the most popular 3D image formats are simple side-by-side images. JPS is a double JPEG, the same for PNS and PNG. The MPO format is a little more complex and suitable for more applications (http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf) however there's no gain compared to JPS and PNS, and it's not so popular, as far as I know.
So, if your customers receive your RadioVIS stream with 10kbps, a full 3D Enabled RadioVIS stream would require 20kbps (i.e. *all* images are 3D).
Of course if we could calculate the correlation between the images we can have a bandwidth reduction (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.1674). On the other hand, have a look at currently available products (photocameras and smartphones): they all use simple sbs. Anyway, compression of stereo image pairs is a very interesting topic and perhaps it can be further discussed and analyzed in the future.
Also consider this: the number of real 3D images in a 3D Enabled RadioVIS stream could also be limited to some important topics: e.g. picture from studio or significant event, advertisements and so on. The RadioVIS application is very attractive (it can really be seen as a *standalone* service in some cases), the 3D part could even improve it.
Kind regards
Paolo
Il 22/10/2011 10:27, Bo�tjan Jerko ha scritto:
Hi Paolo,
I think that's a good idea. The only think I'm not sure about is how much traffic 3D image creates. Is it more or roughly the same as "regular" image?
Bo�tjan
On 10. okt. 2011, at 12:23, Paolo wrote:
Dear RadioDNS Project colleauges,
I�d like to show you a proposal we were discussing, to understand if it would be feasible and useful. The idea is to allow a simple method to enable 3D image slideshows in RadioVIS application. The method can be completely backward compatible, both with the applications and the device types, and patent free (as far as I know � of course it must be further investigated).�
In Rai there�s great attention to all the 3D production technology and to the increasing interest of customers to 3D content. 3D content is �cool� (also in a marketing sense), and devices supporting auto-stereoscopic 3D displays are more and more widespread. Think about the smart-phones already supporting good quality auto-stereoscopic 3D screens (and FM radio, of course) . So the future is already here.
RadioVIS application doesn�t support 3D images at the moment, however the framework is powerfull, and it could be easy to add this feature. I think it would be a nice advertisement for all the RadioDNS Project (ok, not for insiders, but the success of the technology is based on wider targets�).
Technically, to give a kick off to the discussion, in the RadioVIS technical specification we could to create a new topic for 3d images, so we are completely backwards compatible, maybe: "image3d" (added to the already defined "image"). The enabled client (e.g. HTC EVO 3D phone) should subscribe to the image3d topic and not to the image topic. E.g.
SUBSCRIBE destination: /topic/fm/it/5201/09210/image3d ack: auto
Then, the server will send the right images to the enabled 3d client. They can be also completely different from the 2D ones, it's up to the broadcaster.
SHOW http://www.crit.rai.it/pubdir_rdns/radio2/545c5d1a-8d66-457e-ae62-5ef0ce171415.jps
As far as I know, some formats can be proposed as they are patent free. jps and pns could be chosen, as they are based on formats already accepted by RadioVIS. However, this is just to kick off discussion.
I see one there�s at least one legacy issues, related to the fact that RadioVIS is based on WorldDMB Slideshow advanced profile. But perhaps this issue can be overcome with the help of the very smart RadioDNS experts.
What do you think about it?
James Cridland (RadioDNS)
currently, the most popular 3D image formats are simple side-by-side images. JPS is a double JPEG, the same for PNS and PNG. The MPO format is a little more complex and suitable for more applications (http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf) however there's no gain compared to JPS and PNS, and it's not so popular, as far as I know.
So, if your customers receive your RadioVIS stream with 10kbps, a full 3D Enabled RadioVIS stream would require 20kbps (i.e. *all* images are 3D).
Of course if we could calculate the correlation between the images we can have a bandwidth reduction (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.1674). On the other hand, have a look at currently available products (photocameras and smartphones): they all use simple sbs. Anyway, compression of stereo image pairs is a very interesting topic and perhaps it can be further discussed and analyzed in the future.
Also consider this: the number of real 3D images in a 3D Enabled RadioVIS stream could also be limited to some important topics: e.g. picture from studio or significant event, advertisements and so on. The RadioVIS application is very attractive (it can really be seen as a *standalone* service in some cases), the 3D part could even improve it.
Kind regards
Paolo
Il 22/10/2011 10:27, Boštjan Jerko ha scritto:
Hi Paolo,
I think that's a good idea. The only think I'm not sure about is how much traffic 3D image creates. Is it more or roughly the same as "regular" image?
Boštjan
----
homepage: http://www.japina.euval202igra: http://www.t-42.eu/val202igrahackshackers:
On 10. okt. 2011, at 12:23, Paolo wrote:
Dear RadioDNS Project colleauges,
I’d like to show you a proposal we were discussing, to understand if it would be feasible and useful. The idea is to allow a simple method to enable 3D image slideshows in RadioVIS application. The method can be completely backward compatible, both with the applications and the device types, and patent free (as far as I know – of course it must be further investigated).
In Rai there’s great attention to all the 3D production technology and to the increasing interest of customers to 3D content. 3D content is “cool” (also in a marketing sense), and devices supporting auto-stereoscopic 3D displays are more and more widespread. Think about the smart-phones already supporting good quality auto-stereoscopic 3D screens (and FM radio, of course) . So the future is already here.
RadioVIS application doesn’t support 3D images at the moment, however the framework is powerfull, and it could be easy to add this feature. I think it would be a nice advertisement for all the RadioDNS Project (ok, not for insiders, but the success of the technology is based on wider targets…).
Technically, to give a kick off to the discussion, in the RadioVIS technical specification we could to create a new topic for 3d images, so we are completely backwards compatible, maybe: "image3d" (added to the already defined "image"). The enabled client (e.g. HTC EVO 3D phone) should subscribe to the image3d topic and not to the image topic. E.g.
SUBSCRIBE destination: /topic/fm/it/5201/09210/image3d ack: auto
Then, the server will send the right images to the enabled 3d client. They can be also completely different from the 2D ones, it's up to the broadcaster.
SHOW http://www.crit.rai.it/pubdir_rdns/radio2/545c5d1a-8d66-457e-ae62-5ef0ce171415.jps
As far as I know, some formats can be proposed as they are patent free. jps and pns could be chosen, as they are based on formats already accepted by RadioVIS. However, this is just to kick off discussion.
I see one there’s at least one legacy issues, related to the fact that RadioVIS is based on WorldDMB Slideshow advanced profile. But perhaps this issue can be overcome with the help of the very smart RadioDNS experts.
What do you think about it?
Thank you for the attention and feedback
Kind regards
Paolo
James Cridland, Secretary, RadioDNS Project http://radiodns.org/
Where new platforms and radio collide: http://james.cridland.net/blog/
Paolo
only a few considerations. Existing receivers software (and spec for them) would be untouched if we require that only 3D capable devices subscribe to the image3d topic, and to image topic only as a fallback. So, an existing 2D device would keep on subscribing to image topic.
Following the guidelines in "Annex A: Acceptable device implementations", a possible strategy could be:
- 2D receivers (and existing receivers, of course) will follow the existing spec
- 3D enabled receivers will try to subscribe to image3d topic first, and to image if the content provider didn't implement the 3D flow
- image3d *can* include 3D jps and pns images; the receiver subscribing to image3d *shall* be able to render them as well as traditional jpeg, png and apng images
As far as I know, simple jps and pns formats will be easily scaled to a 3D screen, as they simply are side by side jpeg and the rendering is up to the device. The device must do proper rendering and scaling. And if a required format is not supported, the RadioVIS application should take care of that (like an audio player: if the device doesn't support mp3 streaming, the application should take care of that). E.g. the HTC Evo 3D supports jps; LG Optimus 3D seems to support it too. We're going to check these features on real devices soon.
Just for sake of completeness (and brainstorming), here is another more complex approach, *alternative* to defining a new image3d topic. We could specify 3D client capabilities using the traditional image topic, and sending additional device capabilities using a custom (optional) SUBSCRIBE header. As you can read in STOMP 1.1 spec: "STOMP servers MAY support additional server specific headers to customize the delivery semantics of the subscription". So, a SUBSCRIBE additional header could be for example "client-capabilities: 3d". This subscription header tells the server that this client would like to have 3d contents, if available.
Kind regards
Paolo
Pete Redhead
- 3D enabled receivers will try to subscribe to image3d topic first, and to image if the content provider didn't implement the 3D flow
One thing to keep in mind here is that the Stomp server may not return an error if a client subscribes to a topic that does not exist. For example, if ActiveMQ is configured to allow anonymous users to create topics, the subscription will be accepted but messages will never be delivered.
This may make knowing when to fall back to the /image topic more complicated. A service may have a slow slide rotation speed, therefore having a timeout wouldn't be ideal.
Best wishes,
Pete
Paolo
do you think this behaviour can be enhanced if the server automatically forwards the image3d subscription to the image fallback topic? It's not necessary that the client drives this process, as we can imagine that image3d topic includes both 3d and 2d images (and, as a special case, only 2d images). And this feature is supported by ActiveMQ. Does it make sense?
Kind regards
Paolo
Pete Redhead
If I understand your email correctly, wouldn't that entail all servers to be configured with an /image3d topic that relays the original /image topic?
Personally, I think a more elegant solution would be to create a separate _radiovis3d SRV record. Then a 3D device could query the 3D record first, if no result is returned try the standard _radiovis one.
This allows 3D slides to be run in parallel with existing ones and eliminates the issue of clients subscribing to topics that never receive messages.
Best wishes,
Pete
Paolo
Personally, I like very much your solution. It simply solves the problem in a beautiful way, and it's cheaper than the forward. I think it's also scalable if other types of images/services/data will be added (other possible SRV records).
Kind regards
Paolo
Il 27/10/2011 15:00, Pete Redhead ha scritto:
Hi Paolo,
Ben Poor
Paolo
thank you for your comment. If I understand correctly, you propose to
separate the RadioVIS specification and the 3D support, creating a sort
of small additional 3D RadioVIS spec. Honestly I thought it could be a
simple addendum to the RadioVIS spec, however it you think it can be
clearer and more effective, for me it's OK.
I'm going to prepare a proposal for the RadioDNS board.
Kind regards
Paolo
