Good morning, everyone. I'm Werner Neubrand, 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.

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. And 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'll see that we have about 10 different camera drivers, where PTP and Mass Storage are the most important ones. All the others are really vendor-specific.

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.

"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 the camera, with the device list, the root object.

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: a thumbnail and a 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 excess information. The image would have a 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 a small help 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, 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." 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.

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. So, 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 flattened it out into a single array. "It's for you to really give you really quick access to all the data on that." If we look at the tree structure, then actually 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. Okay. 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.

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.

Only disadvantage is, it works only with the Image Capture application. "If you prefer another application as a startup that gets launched when the camera is connected, then this approach wouldn't work." 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 is a menu item called Services. And this allows you, your application, to use image capture devices directly.

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... The 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. The 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 really make use of those if you aren't doing already. 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. Let's have a quick look at these three APIs. Get-ICADeviceList is the fastest and only way to get the device list object that is at the root of everything. From there on, you can go to your different images or devices.

Copy Object Property Dictionary 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.

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. So I have the PDP cameras 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-processing 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. 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 gets an open event.

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, looks very similar to whatever we just saw before in the application, and I can select...

It 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, you 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, a 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 using the Image Capture Framework. One other thing I can do is I can, I'm going to 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, it 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. 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 the scanner. We have a set of APIs that were introduced with Jaguar. 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 ICAPs, we have those as a key. 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.

Dwayne, 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." Dwayne 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 Dwayne Data Source Manager. Which was really confusing because, first of all, applications could not assume that the Data Source Manager was installed.

And for those non-MACO applications, those of you who are still using CFM-based applications, we have a shared library.

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 Talks to the DSM Through the DSM To the different DSs www.werner-neubrand.com www.werner-neubrand.com www.werner-neubrand.com www.werner-neubrand.com 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. It's really well organized. They have a Windows section and they have a Macintosh section. Unfortunately, that section for the Macintosh is really made for Mac OS 9. 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.p list 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,

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.

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. Because otherwise we could just bring up the standard DSUI, 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.

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 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.

You see, on this machine I do have a scanner connected, a 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...

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.

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.

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.

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. 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, 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 Image Capture 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 let me 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. 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 sub-channel.

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 Werner's 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 device. "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. Now, on this machine, well, I don't see anything, of course, because I have to go to machine number three.

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.

And notice that we also do, still do support all our APIs. So for example, download file just works. Although, the, "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." 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.

"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.

Okay, but I actually did more. So I did not only... I activate this one to do the local sharing. I also enable the web sharing. Now, when I open this, how do I get through this machine?

So select that one and you see, whoops, same content. But just imagine this could be on the other side of the world.

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." "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 memory stick, Sony memory stick reader in Cupertino in the office. But we actually have more. So we have one camera set up

I can switch to a 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.

That's

Going back to the browsing part, if the camera supports it, you can take a picture directly. So you don't have to go to this monitor mode. Whenever you want, you can trigger it. You can download. and 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. And we can just download that to disk. And speed is not that.

"The tracking alpha is probably a better way." 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. Let's talk about the new APIs that we have in Panther.

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.

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. 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 are 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 TextEdit 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. I'm basically zeroing out the ICA import image parameter block. However, I do specify the filter proc and supported file types. I specify just the callback proc, and as file type, I just specify TIFF and JPEG.

I'm willing to import TIFF and JPEG files. My callback proc gets called 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 text edit 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 because they

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

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.

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. Thank you.