Help get this topic noticed by sharing it on Twitter, Facebook, or email.
Oh ... I don't know ... seems Adobe is very receptive to porting their portable apps for iOs ... why would this be so far out of the realm of possibilities? ... not doing so wouldn't hurt Apple or benefit Adobe, it would only punish Apple users ... Getting caught up in the Apple vs Adobe, Flash on mobile devices debate, isn't all that big of a deal as Adobe has spent considerable time and effort working on solutions, not digging their heels in and crying foul ...
We may not see such a feature in the near future because Adobe may have bigger fish to fry and the number of Lr users that could benefit from such a feature wouldn't be too great ... but I don't think Adobe would refuse to offer this idea simply out of spite towards Cupertino ... I for one would not be opposed to such a feature ... it would be a great way to present proofs to portrait clients ...
Yesterday I tried the following Java example code:
and it works indeed: no cryptographic keys necessary, as to "connect" with the Apple TV, for example.
So to display a JPEG image you would:
1. Auto-discover the Apple TV service using Bonjour(*)
2. Determine the display size (or let the user determine it in the "server" application), as to scale images accordingly before sending
3. Send the JPEG data and parameters with a simple HTTP POST request to the IP address and port as discovered in 1.
(*) Apple provides the Bonjour (aka zero-conf) library also on Windows under some Apache license, so no legal issue here. There is also a Linux implementation *hint* *hint* ;)
I wonder whether such an "Apple TV photo show" would be possible as Lightroom plugin? Is the Lightroom plugin API powerful enough for that? And does the "Lua runtime" allow for network connections and linking to external libraries / system calls such as Bonjour (I understand the "Lightroom plugin Lua" is a restricted subset of Lua, no?)?
This is where you get the "Bonjour SDK" (Opensource) for Windows:
On Linux there is an LGPL "zero-conf" implementation called "Avahi", apparently with a "compatibility layer" for "Bonjour". On Mac OS X the required libraries are off course already available.
Apple provides an architecture overview:
As can be seen there is the platform-specific (OS X, iOS) "high-level" part NSNetService and NSNetServiceBrowser. On the lower - and platform-independent - level we have the socket-based "DNS Service Discovery" available in (the part which is also implemented on Linux with "Avahi", for instance).
An example how to user this socket-based service discovery in a cross-platform manner (C++, Qt) is given here:
Obviously this code is only an illustration and to my understanding contains a few glitches (especially when a service is available over more than just one network interface), but it should be straight-forward to adapt to any other framework/language and to understand how to discover the "Apple TV" service.
The rest is then a simple HTTP POST to the discovered address/port, as outlined by this simple shell statement using CURL:
(which according to the SVN comment doesn't work, as CURL doesn't keep the connection alive - but one gets the basic ingredients and parameters. Also refer to the "unofficial protocol" posted at the very top).
Eh voilà - easy as that :)
So Adobe - any developer there feels like hacking away this feature please? :)
I just stumbled across this on the Apple support forum in reference to mirroring to Apple TV ...
"Unfortunately mirroring is not supported from the MacBook Pro. The next operating system "mountain lion" will support mirroring of the desktop, subject to any hardware restrictions there might be."
I would much rather have a system level ability to present to Apple TV wirelessly than to depend upon a per-app coding for the feature ... that way ... no matter what I want to share on a larger screen ... I don't have to wait for the individual developers to implement the feature. Looks like Mountain Lion, OS X 10.8 ... may do just that ...
Perhaps adding your voice in the Apple forum will assist in that goal ...
@Butch_M: You are right: desktop *mirroring* is only available from OS X 10.8 onwards.
However here we explicitly *DON'T* want to *mirror* the photos! In fact, that would (maybe just hardly noticeable) diminuish the quality of the photos. Why? Because desktop *mirroring* means squeezing (yes, compression! Yikes! ;)) the continuous desktop screenshots
into a h264 compressed video and streaming that to the Apple TV. I'm not even sure whether the older Apple TV 2 supports "desktop mirroring", and worse: even on ATV 3 the resolution is restricted to 1280x720 in "desktop mirroring" (which is probably more due to the fact that encoding in HDTV resolution *in realtime*, even at a say modest 15 FPS, is probably out of reach, even for today's hardware - you still want to be able to actually use your desktop at the same time ;)).
So no, "Desktop Mirroring" is something we definitelly don't want for this use-case of presenting high-quality, up to 1920x1080 sized photos!
(Even though I'd agree that it would be a first, acceptable solution).
So what I was talking of is the simple display of photos, and if you had studied and understood the above resources, specifically the "Unofficial Protocol", then you would have realised that the AppleTV a) provides such a service, b) it is dead-easy to use and c) it works today already, on OS X 10.6 even - in fact on every device which is capable of creating and sending simple HTTP POST requests.
Oh and yes, already now every iOS application is kind of "cooking it's own soup" if it wants to display photos on Apple TV: by calling the appropriate iOS API calls which basically boil down to the above ("discover and send").
Does that make sense to you?
This reply was removed on 2012-05-23.
see the change log