Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: wwdc2003-204
$eventId
ID of event: wwdc2003
$eventContentId
ID of session without event part: 204
$eventShortId
Shortened ID of event: wwdc03
$year
Year of session: 2003
$extension
Extension of original filename: mov
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: ...

WWDC03 • Session 204

Image Capture Update

Graphics and Imaging • 1:01:34

With Image Capture Framework, applications can acquire images directly from digital cameras and scanners. Your application can support the most popular forms of digital image capture with a single API. This session explores the enhanced capabilities of the Image Capture Framework, and explains how you can integrate them into your products.

Speaker: Werner Neubrand

Unlisted on Apple Developer site

Transcript

This transcript was generated using Whisper, it may have transcription errors.

Good morning, everyone. I'm Werner Nolkamp, and I'm one of the image capture engineers. And today we will talk about an image capture update. So I will give you a brief introduction to image capture, short overview. Then I will talk about how you can use image capture from within your application.

Very easy, we will see. And then we talk about the scanner support. Scanner support that, as Travis mentioned, was added with Jaguar. And then we have a short look at Twain. And then finally, we will look at the new features, new exciting features in Panther and do some cool demos on that.

So, just looking at the image capture framework, it's a framework that was introduced with Mac OS X, and it's dealing with still image devices. So any camera, or with Jaguar, we started supporting scanners, are really covered by this. So the nice thing really is it's an architecture that takes the device specifics from the application. So you write an application to work with an image capture device, then you and your application does not need to know about that device. There's no need to know a low level protocol to talk to a device. You just use a couple of the actually very few image capture APIs.

If we look at the framework, then let's look at the components that we install by the framework first. I'm not really going into too much detail because we have so many plugins and helper applications. Let's just focus on the main things. One of the main things, of course, is the component that talks to a device. We call it device module. It's actually a background application, UILess, and it runs in your user space.

This device module talks to a specific device or a class of devices. And on the camera side, we were actually very lucky because we can just have a handful of device modules to cover almost 100% of the existing cameras. Now that is possible because a lot of cameras are adopting two really favored protocols. One is the PTP, Picture Transfer Protocol, and the other one is mass storage. So you'll grab a camera and you will see it as a mass storage volume. If you look at all the devices that we support, you see that we have about 10 different camera drivers, where P2P and mass storage are the most important ones. All the others are really vendor-specific.

And the nice thing about these is really, again, they cover a whole family of devices. So there's really no need to have more than these 10, and we really cover a lot. Unfortunately, on the scanner side, it's not that easy. You see we have two modules listed. That's the twin bridge and the type 1 scanner. That's for the Epson class scanners. Yes. But we really want to add more. And hopefully we have a couple of the developers here that can help us do that.

So if you look at the device module again, what sits on top of it is a background application. the image capture extension, that deals with multiple modules, even at the same time. So you can have an application using a scanner and a camera, more or less at the same time, or multiple cameras. On top of that, we have the client application. One client application you all know that we ship with Mac OS X is iPhoto. The other one that we also ship is the Image Capture application. And your application could be one of those using the image capture framework.

Now, these are just the main three components for the entire image capture architecture. Now let's look at how we handle this internally. So internally, we have the notion of ICA objects. ICA objects are these things that are... specified by type and subtype, so they describe the type of the object by OS types and subtypes. They may contain reference to other objects. That allows you to build a hierarchy, a tree. They may contain properties and dictionaries. Properties, that's where we have the real data. The real data was reduced with the Panta introduction to actually adjust the thumbnails and the image or audio data that could be on a camera device.

With Jaguar, actually, we were introducing dictionaries. That's actually a very convenient way. So we are assigning one dictionary to one object, and that dictionary contains all the metadata for that object. So the nice thing with that is we can very easily give you a chance to get access to all EXIF data that you may get from a camera image by just looking at that dictionary, because we stuff all that EXIF data into that dictionary.

Now, with these three building blocks, we actually can create something like that. So we have an object sitting at the top, and then going down, we have two objects that are referred by the root object. They all have dictionaries, and they all may have properties. So in the real world, we always start, when we, for example, look at a camera, with the device list, the root object.

And new for Panther, for that root object, we are going to add also a device dictionary. So on Jaguar system, if you try to get the dictionary for the device list, you wouldn't get anything. For Panther, we give you back a dictionary, and that dictionary contains actually information about all the connected devices. And we are extending even the regular information.

It's not just the device objects that you get. you get information about the devices at IOCAT level. So, for example, you get a location ID or a firewall GUID or an I.O. registry path in that dictionary. That gives you very easy access to a certain device. For example, if your application is only working with a certain type of camera or with your own scanner, then you could really look at that dictionary up front and see if your device is connected.

In the real world, we could connect a camera. That camera will have a dictionary. That dictionary actually contains information about the device, but also about the objects, the images on that device. And we have two properties, the thumbnail and the name, although you could actually get the name from the dictionary as well.

And on that camera, we can have an image. Well, the image, again, would have a dictionary, but for that image, the dictionary would contain the exoskeleton information. The image would have the property. The property one would be the thumbnail information. So you can get very easily get access by just reading that property. Get a thumbnail that you can display in your UI. Or even the actual image data. And of course you can have multiple images on that.

So let's switch to demo four, and I will show you just in a small helper application that we are using to just indicate what kind of applications are running. So you see, we have the image capture extension that I mentioned before, and then I have listed all the different camera modules, and at the bottom I have the image capture application. So let's see what happens when I connect a camera.

I connect the camera and you will see immediately, ah, this is a PDP camera. And it shows up, PDP camera module gets launched and the image capture extension gets launched. Now, of course, I could launch image capture and browse the camera content. I could say I want to download this and this. Thank you. But I will actually launch another utility, the Image Capture Browser. Image Capture Browser is a small utility that comes with the Image Capture SDK.

And it does what the name says. It browses all the image capture devices that you have connected. In this case, we have the camera connected. I can select the camera, and then in bold, I get the actual properties for that camera. But you see down here, it also fetches the dictionary for that camera. So I see an IO registry path. I see capabilities. I see a data structure, a data array, a tree array, and I have like a file name, it's a Canon PowerShot S50. I have a USB location ID and so on. Up here, I can actually browse, go to the first directory. I have two directories on that device. I see that directory has a property. That's the file name.

And I can go through that. I see, oh, there's another, and so on. One nice thing is I can actually go to this data dictionary. It shows you what I was showing before dynamically what you have connected to your system. The data dictionary actually is a flattened out structure. So it shows you at one level deep, the actual data that's on this device. So the Canon PowerShot S50, in this case, has these images. And these are actually the ICA objects.

Now this is flattened out, so we did parse the entire tree that's on this device and flatten it out into a single array. for you to really give you really quick access to all the data on that. If we look at the tree structure, the next tree you see, well, it's not that easy. It's really, if you would walk the tree all by yourself, go to the root object, get the nth child, and so on, and walk the tree, do that for all the dictionaries, and you could get to the same eight images that we have in the data dictionary, much easier to access. The advantage of the tree dictionary is it would also give you non-image related files. So for example, if a camera would contain a firmware update or whatever on that device, on that CF card, then you would see it here.

So this is image capture browser is the utility that comes with the image capture SDK. And whenever you work with image capture devices, it might be very useful to just use that. Okay, let's switch back to the presentation. Now, in the next section, I will talk about what it takes for you, your application, to get access and use image capture framework and image capture devices. process.

There are a couple of levels, a couple of steps that you can do or not do to work with the image capture devices? Well, the first one is a very simple one. With the image capture application, we give you a way to set your application as an automatic task.

It's very nice because it's very easy. All you have to do is the user has to select your application, and then from within the image capture application, you do a download, and what happens is you get an open event for all the downloaded images. Couldn't be easier. Thank you. Only disadvantage is it works only with the image capture application. like you prefer another application as a startup that gets launched when the camera is connected, then this approach wouldn't work. Thank you.

The next one, to make it very simple, actually is added with Panther, and that's the service. You probably know that all Cocoa applications get that for free. So under the application menu, there's a menu item called Services. And this allows you, your application, to use image capture devices directly. it.

For Carbon applications, you have to do a little bit. You have to implement certain Apple events, and you find here a URL where you get more information. you have to implement certain Apple events so that your application will actually take use of the service menu. Service menu is very simple because a service can, on the paste board, basically say, I deliver text or image data. And if your application would allow the pasting in of images, then it automatically supports the service.

The next level with Panther, we are introducing a new way to-- a simple way to use a common UI. Common UI is something like that. So it's very similar to the image capture application itself. In fact, it is the same thing. It's just a plug-in that gets loaded, and we display that. We strip it down a little bit. For example, in this -- Common UI, you currently cannot do any delete or take picture. You cannot change the automatic task or download folder because there's no download folder currently.

And Common UI is used, and we will talk about that in a little bit. Common UI is used with a single new API. You just call this and the UI comes up. User may choose the picture and hit import and you have it in your app. And of course, the old way to work with image capture is really you create your own UI. There are a couple of examples for that. Of course, iPhoto did that. Graphics Converter does that. And FileMaker, I guess, they're using that. The advantage of your own custom UI is, of course, you have full control. The disadvantage is you have to implement more or less everything.

There are just three really very useful APIs for your common UI, and you should take use, really make use of those if you aren't doing already. Because, Instead of, we just showed you that before, when you look at the object tree for a camera, instead of walking the tree directly, you could and you should make use of the dictionary that we provide for you with all the already pre-digested information about the actual images. So let's have a quick look at these three APIs. Well, the first one, get ICA device list, is really the fastest, and actually the only way to get the device list that is really at the root of everything. And from there on, you can go to your different images or of course the devices.

and copy object property dictionary, that's this API that returns the dictionary for a given object. So just get the device list, get the device, the property dictionary for the device list, and then you know what device is connected. You know the ICA object for the connected devices, and from that, you get the dictionary and you have access to all the images.

Here again, that's how the dictionary looks like for a camera or, in this case, a card reader. You see, we, for example, have the capabilities. This card reader allows you to delete images, and it allows you to support the eject. So the image capture UI may bring up an eject toolbar item, saying, well, eject this volume, because it's mass storage. And below, you see the data dictionary that is really an array of dictionaries, one item, one dictionary for each image. Thank you. So it gets a little bit more complicated if you just add more objects. Then again, it's very simple and easy and straightforward to just use the data dictionary with all the images. You know exactly that these are only images.

On the download file, well, it's a very simple API because all it takes is the IC object, and it takes a dictionary ref, where to download the image. and it actually does a little bit post-processing for you. For example, it automatically embeds a color sync profile. Very convenient. You don't have to do anything. It does that.

However, if the image already has a color sync profile embedded, some of the newer cameras do, then of course, we will not re-embed that profile. We will not overwrite that. It allows you to adjust the creation date. So when you download the image, then we set the creation date, if you set that flag on. We set the creation date to the exit information that we can extract out of the image. It creates a custom icon if you want. It can rotate the images.

Okay, let me just do a short demo on the different steps of integration. So if you switch to number four. Yep. So I have the PDP camera still running, and what I can do is I launch the image capture application, and you see I could either download all or just download one, and as... a post-process as an automatic task, I selected preview. So I can show you how this room looked like this morning when nobody was in here. I just do a download. and the image gets downloaded, and preview should launch, and that's it. So very easy for your application to get involved with image capture devices because it just gets launched and get an open event. - I don't know.

So let me show you the second level of integration. I have a version of TextEdit here, and under Services you see Image Capture, and I can select Import Image. It brings up a custom UI. It looks very similar to whatever we just saw before in the application, and I can select... an image and import that and Should take a while. You see it's even too big to display in text edit. But here is the image.

Another way to use the common UI that you just saw as a service is really we could modify TextEdit. Now that was easy to do because TextEdit is really one of the sample apps that you get when you install Panther, sample app for the app kit. So I can very easily add an import image.

And as you see, well, the input image doesn't do anything else, but using the common UI, brings up the common UI, I can select an image, and I can import that, and should be able to display that. It's a very large one. Okay, so... Okay, so that's one way of, another way of using the image capture framework. One other thing I can do is I can, show you a custom implementation, and we just created a very quick and dirty Photoshop plugin that uses a custom UI.

Custom UI based on the three APIs that I was showing to you and the Image Capture custom UI plugin, well, very simple. It just gets the camera icon, the thumbnail. It gets the number of cameras, so if we would have multiple devices connected, just prints that. And then it looks at the data dictionary to get all the images. So I can select one and import that. And these images are large. So it takes a while, but here's the image. 23% and yeah. So we get the image very quickly into any application.

So let's go back to the presentation. And let's look at the scanner support in image capture. Well, one of the main goals was really to have a very simple UI. Make it easy. Make it easy for the standard user to use the scanner. Image capture supports actually two types of device modules. One, the image capture native, and the other one is really the Twain data sources. You may ask, "Why are you doing that?" Well, very simple. Twain data sources, they are available for quite some time, and they probably give you a very good way to work with a certain device.

However, it's not that easy to create a real solid Twain data source. It takes some time because not only you have to talk, actually implement everything to talk to the device, but you also have to implement your own UI. Thank you. Now, with an image capture native scanner module, you're not really worried about the UI because the UI is part of the image capture application. All you have to do is implement, because we have a framework, to really create your own scanner module, implement very few calls, and that actually gives you access to all image capture client applications.

So we have a set of just specifically talking to a scanner We have a set of APIs that were introduced with Jaguar. And we are not going to add any API for Panther. However, we changed the meaning of two APIs. It used to be that ICAs cannot get and set parameters for the APIs to pass in a CFDictionaryRef or in a dictionary, pass all the parameters.

Well, we still maintain that, but we are switching the keys. We are switching the keys to a model that's closer to Twain. So basically, all the twain caps and eye caps, we have those as a key, And the values for those are a dictionary with all the right content for that ICAP structure. Now this actually allows us to be more flexible. First of all, it's probably easier for you with a Twain background to really implement a native scanner now.

For example, for us, it gives us a very easy way to enhance the scanner capabilities because in Jaguar, we could do only flatbed scans. We could not switch to a transparency unit. With Panther, it's easy to do. We more or less mirror what we have on the twain side.

Talking about Twain. Well, Twain is really an industry-wide, it's very established, it's more than 10 years old, standard to access imaging devices. Twain by itself supports cameras and scanners. However, within the image capture environment, we are using only scanners because with the very few camera modules that we have, we cover roughly 100% of the cameras. Maybe not 100, but very close to.

Twain, if you look at the setup, has three key components. First one is the client application. Second is the Twain data source manager, the DSM, and the actual Twain data source. Well, that looks very similar to the image capture setup. Twain DSM is installed with Mac OS X. So back on Mac OS 9 days, a lot of vendors when they were selling their device, they were shipping a CD that actually did install a Twain data source manager. which was really confusing because, first of all, applications could not assume that the Data Source Manager was installed.

or was installed at the correct version, the correct location and all that, since it was not supported by Apple. On Jaguar or Panther, you will find the Twain framework as a Mac O framework in system library frameworks. And for those non-MACO applications, those of you who are still using CFM-based applications, we have a shared library.

that we also install. So really, we ask you, please do not install any DSM. It will really destroy the current setup. And we had a couple of cases where that was happening. So where a client application, your driver maybe, was installing your own version of the shared library, which is a really bad idea. Please rely on that. We ship the latest stuff.

So if you look at the setup, again, this looks very familiar. It's the same or very close setup as we had for image capture. Well, there's a big difference. Big difference is actually that all these three components are running in the same process. With image capture, each block was a different process.

Actually, that has the advantage that we, as a central piece, the image capture background application is always in charge of all the devices, so we can have multiple clients and multiple devices. Well, in the Twain world, it's not that easy to handle that, because you have multiple instances of the DSM actually running.

So how did we integrate Twain with Image Capture? Well, we did that and remember I mentioned that early on. We are using a Twain bridge. Image Capture basically implements a module that talks to a Twain DS. So from the Twain world, it looks like a Twain client. From the Image Capture world, it looks like an Image Capture device module.

Which also means that this thing, whenever you connect the device, this thing gets launched, the twin bridge gets launched, and it will be running as long as the device is connected. We implemented a way, a very easy way for you, to hook up button support. Because a lot of vendors, they ship now these scanners with a scan, email, fax, copy, whatever button in front. And what they really want is that user presses the copy button and then a certain application on the Mac should be launched and should do a copy.

Well, you can do that. You can implement your own button listening plugin, put that into your DS, and then this code gets executed when no one else is using the device. So there's no need for you to write up a special kernel extension in order to do that.

So that's how the setup looks like. So image capture, the train bridge is the, client, it talks to the DSM, and through the DSM to the different DSs. Again, the nice thing, any image capture-aware application can just use Twain data sources. Actually, we have a mode where we present our UI or where you can choose to use the Twain original DS UI if you want.

So the Twain implementation is really currently 1.9, and they came up with the spec in 2000. They describe how to write a Twain client application, how to write a Twain data source. And they have, it's really well organized. So they have a Windows section and they have a Macintosh section. Unfortunately, that section for the Macintosh is really made for Mac OS 9. So the current spec is really not the way you should follow in order to implement a DS or even a Swain client application.

We made some changes. So for the DS, for example, it used to be that those were just shared libraries. Now we really require now a bundle. The bundle has a couple of advantages. For example, we can store additional information in the info or device info.plist that we require.

The info.plist, for example, contains information about the device, the scanner that you are going to hook up. It contains, for example, for a USB scanner, a vendor and product ID. Now why is that important? Well, Twain itself has no way to match, whenever you connect a device, to match that device to a certain DS directly. So what you end up with, you can have like 15 different DSs installed on one machine, And there's no way to get the just active device. With image capture, it's easy, because we just have a scanner device module running, and you can ask image capture, "What is the device?" Well, with Twain, you can iterate over all devices, but there's no way to find an active device. Therefore, unfortunately, I guess, Photoshop cannot handle it differently. If you open Photoshop and look at the Twain DSs that they list, they list all of them, even the ones that are not connected. So that really, when the user picks one, well, it could be connected or not. So you may wait 20 seconds or so before you get a timeout, and then it says, oh, oops, I could not find the device. Not that great of a user experience. So, again, for the image capture part, we really have the information based on your info.plist inside the DS.

that allows us to map the device that is connected, that's plugged in, that we detect on the bus, with a given DS that's installed. result. We switched also to the event model. It used to be that back in the old Mac OS 9 days, there was this wait-next-event loop. There was this constant polling for events. So whenever there was an event, the client application would pass that event to the DS, and the DS could decide, yes, I want to use it, or no, no, I just pass it back to the application, and the application handles the event.

So event model has changed. And the last thing we really ask you, if you are going to write an ONDS, is support the UILess operation. It's an optional feature, but we would really ask you to do it. in order to work with image capture. 'Cause otherwise we could just bring up the standard DS UI and in a bit you will see why that's not that great of an idea always.

So for the Twain client, there's also this new event model where instead of calling wait next event, you could register the callback proc for the case that the DS wants to send you a message. For example, scan data is available. However, for the Twain client, we made it a little bit easier, the transition, because we also allow you to use the old event model. So current Photoshop, for example. Photoshop did not rev for the usage of the new Twain DS and DSM model. They are still using wait next event, and that still works. But for any new application, we would ask you switch over to the new event model, use Carbon Events or Cocoa, register your callback proc and you will get called when the device wants to send some information to you.

Excuse me. So let's now talk about the things that are new in Panther. We have made some image capture enhancements. We are going to talk about image capture networking, web sharing, and a couple of new APIs. Let me start with the image capture enhancement. One thing I mentioned before was really, we added the property dictionary for the device list. Now this may, for a lot of you, it may seem like a little thing that you could live without. Well, it's a very convenient way to get to all the devices at once, also to get to information about the devices. For example, is it a USB device? Is it this specific model of the scanner that is the only one that I'm going to support or ignore?

We did some changes in the UI. So, for example, we have faster launching for image captures, and that's probably those of you who have, like, the new one-gigabyte CF cards or so with thousands of images on it. They noticed that it takes a while before image capture was coming up, bringing up the UI, and was showing the thumbnails. Well, we reduced that time dramatically, And it's much faster launching. And at the initial point, when we do not have all the information about the device, we just bring up a progress bar saying, while we are talking to the device, we are collecting information. And just be patient. It will be there in a couple of seconds.

Then we have a better session handling. It used to be that when two instances of image capture application, for example, were running, and the first one had the scanner session open. Remember, scanner usage is really session-based, so you have to open a session, you have to then do your scanning commands, then close the session before someone else can access the device and open a session.

So what was happening in the past was, first one is active, session is active, you launch the second one, and the second one was saying, well, no device connected. Oh, that's not that great. So we really have a better way to inform you that there's a session ongoing, and also keep that dialogue open, and the first session closes, and whoops, the second one gets active.

We added a couple of scanner image enhancements and progressive scanning. That's on the UI part. And for those of you who work with the train bridge and DSs, in the past, we were using the native transfer, which is unfortunately dated back to, I guess, 10 years ago, when on Mac OS 9, the picked format was such a great thing. And we were using that in the first implementation of the train bridge. Now we switch to memory-based transfer. So that should give us a way to really scan in bands, do larger scans, and use less memory. So let me show that on number three.

You see, on this machine, I do have a scanner connected, Type 1 scanner, and I'm using Photoshop again, but this time I'm using Photoshop from a plugin where I do the standard UI. And scanner wasn't in use, so it takes some time to warm up. and then that time I can show you we have added an image correction section to the UI. The goal again was keep it simple. So we just have the three radio buttons where we allow you to do nothing. That was the current setup where we allow you to do an automatic correction. And here you see actually the progressive scan. So instead of waiting for the entire image to be scanned in, we do it in smaller pieces. And of course we can scan in.

to this area here. I hope you can see that, yeah. So let me do an automatic image enhancement. And you see, well, compared to this, it looks much better. And the nice thing, of course, you can switch to manual and you get the slider settings based on the automatic. You can still enhance it, so you can brighten it up or do some weird things, change the color. take out the color, make it white and all that. So that's all in real time, and actually, you see I can move that around, and with the current setting, I can even design new iMac fissures.

Other than that, you may notice that we, on the options, we give you a way to choose the resolution for an overview scan. So, whenever you work with the overview, if you really want to zoom in quite a bit, then you should make sure that you're not scanning at 25 dpi because that's really just a few pixels that you have to correct, and the results may not be that good. So, what we do is really, on this image correction, we are using ColorSync and actually produce a ColorSync abstract profile, And on the real scan, when we import that, we apply that profile. and yeah, you get your pre-corrected scan. I don't want to do a scan now, it'll take some time, so I'm just gonna quit. Okay, back to the demo, please.

So another thing that we are going to add in Panther is image capture networking. It's a very easy way to share your camera or scanner on a network. And unfortunately, there are a lot of things you have to implement. Well, not quite, because it works with all existing camera and scanner modules. It works with all existing client applications. So iPhoto, out of the box, will just work with network scanning and network cameras. So there's really no new API. So how do we do that? Well, if we look at the standard setup where we have the different components, like device module, image capture, background app, and your client application, just imagine that you have that on two machines.

Now, how can we make it work so that without changing the lower layer, the device module, and the upper layer, the applications, it still works? Well, of course, there's only one thing we have to do is we have to get the middle layers, the image capture, the background applications to talk to each other.

And we do that on your local subnet using Rendezvous. So really, there's no need to configure anything. Whenever you have sharing turned on, Thank you. on one machine, you can select, yes, I want this one, this one shared, but I don't have to type in IP addresses or whatever.

So that's a great way to share scanners and cameras. But we did more. Actually, the ImageCapture web server allows you to share cameras on the internet. Now that's a really great way, and the nice thing again is it works with existing device modules and works with all internet browsers.

And that's really a great way, because then you hook up the camera here, and you can access it on all platforms, all over the world, once you get through to that device. And the nice thing really, this is done without downloading the images first. So you take the pictures, hook it up to your iBook over wireless, you can share it, and people around the world can access the content of your camera.

And that's actually how it is implemented. The image capture web sharing is just another client, a client that we install and we will launch automatically when you select to do it. And the nice thing is really it works with all different clients. So let me show you that. Here we go.

So if you go to number four, yeah, and we quit preview. So again, I have my PDP camera here, and what I want to do is launch the image capture application. Image capture application allows me again to browse, look at all the images. and we added the sharing panel. Now, sharing, first part is I can specify, look for other devices. Look for other devices that are on this subnet.

Then I have an option to share my devices. You can even turn on the web sharing. So let me turn on the web sharing, and as shared name I use Burners Devices, and I'm not using any password. And I can say, share my devices, and then this table view gets enabled, and I can, per device, I can decide whether I want to share it or not. So let me share my devices.

Canon PowerShot. By the way, down at the bottom, you notice that since we enabled the web sharing, you notice the image capture web server gets automatically launched. Thank you. Now, on this machine, well, I don't see anything, of course, because I have to go to machine number three. And let me start from just fresh. So I launch Image Capture.

See, there's no image capture device connected. Well, of course not, because this machine does not have any device connected. Now, I want to access this camera on the other machine. How do I do that? Well, I go to my sharing, and here I do select look for shared devices. I go to my browse, and then in the browse panel, I do see the Canon PowerShot S50, which I can choose to use, and here it is.

So now on this machine I'm using a camera that's connected maybe to another machine in the back room. And it can access it as if it was connected directly. Okay. And notice that we also do, still do support all our APIs. So for example, download file just works. Although, the, directory ref that you specify is really on your local machine. So you specify to download to your local machine, and we internally remap that, get the data from here, and save it on your local machine. So we do exactly what you want. Thank you.

I have another tool to just, it's one of the debugging tools that may end up in the SDK. It allows you to actually look at the different devices, and you see, I see the same object structure on this machine. I can actually select the camera, object ID and I can get for the camera, I can get the property dictionary. It looks like a local device. See all the data structure and all that. Tree structure, everything is here.

just show you the device list object. So the only thing that indicates that this is a non-local thing is really an entry in here that indicates, yes, it is a remote device. And again, the nice thing is down here you see we just run image capture, so there's really no device module invoked on this machine. Thank you. Okay, but I actually did more. So I did not only... Activate this this one to do the local sharing. I also enabled the web sharing and Now, when I open this, how do I get through this machine? I... actually can use rendezvous to detect it.

So select that one and you see, whoops, same content. But just imagine this could be on the other side of the world. Thank you. Now that's a very easy way to access the cameras. If you don't want or have a browser that does not support rendezvous, how do you actually know that the URL, or you call your friend on the other side of the world, well, go to this URL. Well, what is the URL? Well, actually, if we just quickly switch back to number four, in the sharing, ah.

in the sharing panel. Down here you see the URL. Just use that, send that in the email, and they can access it. So if you switch back to number three, And then let's see if I can actually access, since I was using VPN to connect to the Apple campus. So in my office, I did set up a memory stick reader, so I should be able to just access that.

So this one here is really a Sony memory stick reader in Cupertino in the office. But we actually have more. So we have one camera set up and that camera allows you to take pictures. Now, I can switch to remote monitor, and I can actually look at what the canvas looks like right now, and it refreshes, and you see here, when the next image will be taken, so it takes every minute or so you can configure it, it takes a picture and updates the screen. Well, that's one thing you can do with a webcam.

doable, but just imagine the high resolution. This is just a scaled down image, so really you get a lot of details very, very easily. You don't have to, again, type in any IP address, no nothing, all you do, and here it's just refreshing, all you do is hook it up, turn on the web sharing, send the URL to someone, and if they have access to that machine, they can get it.

Going back to the browsing part, if the camera supports it, you can take picture directly. So you don't have to go to this monitor mode. Whenever you want, you can trigger it. You can download. You can even look at the list view so you can actually see when was this picture taken. You see we even had a night shot from last night. We can just download that to disk.

dragging out is probably a better way. Yeah, okay. So again, if you look at that in actual size, you see this is not a cheap webcam resolution. It's much higher quality. Okay, so that's image capture web sharing. Let's go back to the slides. And let's talk about the new APIs that we have in Panther. Well, first of all, and we saw that used by services and also by the modified version of TextEdit, we have this common UI, the ICA import image. It really gives you an easy way to access a kind of nice UI, easy to use. You don't have to worry about thumbnails. It will be speed optimized and present everything.

That's how the API looks like. So all you do is in standard image capture way, you specify a parameter block and a callback proc. And the parameter block has the device object for that you want to bring up the UI. But actually, we made it easier for you. You can just specify zero. And that means if you have a single device connected, well, use that one. If you have multiple devices connected, we bring up a small selection box, and you can let the user choose which one.

There's some flags you can specify. Do you want to have single or multiple selection? You can specify file types that your application is going to support. For example, on the memory stick, I also have an MP3 file, and it wouldn't do any good to allow pasting an MP3 file to a graphics application.

There's also a filter proc that you can specify, and that filter proc gets called for each image before displaying it in the UI. Actually, you can then look at that image and reject it if you don't want to display that. And then you get back and see if ArrayRef with the data for all the user-selected images.

So if you look at the text edit application, what did I have to do in order to implement that? Well, it was very simple because I just created a new method that gets called when the menu item was selected. And I'm basically zeroing out the ICA import image parameter block.

However, I do specify the filter proc and supported file types. So I specify just the callback proc. And as file type, I just specify TIFF and JPEG. So I'm willing to import TIFF and JPEG files. And my callback proc gets called, as I said before, displaying or adding each image to the UI, meaning I have the freedom to reject it if, for example, I'm working only with very small images, I can reject all the ones that are more than a certain size.

And here I have the callback proc, which just calls into a method of the document, and that's the ICA import callback, and all I'm doing in here is checking the return code. I look at the error code in the header file and also look back, do I get back an array of NSData? If so, I get the first element of that array, put it into an NSData, and actually the easiest way to get that into TextEdit was just make use of the pasteboard, so basically act as pasting it in, and that's what I'm doing here.

Another new API that we're going to add is ICA Copy Object Thumbnail. ICA Copy Object Thumbnail is just retrieving the thumbnail. Why would we do that? Because we did it in the past by just using ICA Get Property Data. Well, the reason to do it is really we support multiple formats. In the back, we had our own ICA Thumbnail format, which was just raw data, raw RGB data.

Now we also support JPEG and TIFFs. The advantage of this is they could be actually smaller might be compressed very well, the thumbnail. And the other advantage is really, we are now able to embed the color swing profile directly. So if you ask for a JPEG or TIFF, we will embed the color swing profile and when you display it, it will be correct.

So for this API, again, parameter block and callback block, and what you specify is just the object. You specify the thumbnail format, and you get back thumbnail data. The last thing, it's not actually a new API, but it's a new message type that we introduced with Panther. And we are allowing now third-party applications. There were certain vendors that wanted to use their application, bypassing image capture, their application to talk to a camera device. Now, this is a bit of a problem because whenever you connect the device, an image capture camera module gets launched and it keeps the device.

And the only way in the past to really get to that device was you did reset the bus. We just ask you, please do not reset the bus, brute force and killing all existing image capture client apps or so. So we implemented this ICA device yield message that you just send to a device object, And then image capture will release the device, meaning you and your application can bypass image capture and use the device directly. And here's how you use it. It's very straightforward. It's just an IC object send message parameter block that you clear. You specify the object, and then the message type KICA message device yield, and send that. And then image capture will release the device, and you can work with that. So that's really the end of the image capture overview, and here are the contact persons, Travis and John Simra. If you have any questions, comments, suggestions, bugs that you want to report, these are the right persons to ask. Okay, thank you.