Good afternoon, everyone. I'm Travis Brown, the graphics and imaging evangelist. And I'd like to welcome you to the Image Capture Framework session, which is session 515. At last year's WWDC, we introduced Image Capture, which is Apple's technology to allow users to have a really great user experience with digital cameras, where essentially they can just plug their digital camera in and get images off the camera very seamlessly. A key point is Image Capture has always had APIs available for developers to essentially enhance their application with the ability to work with a huge number of models of digital cameras.

That fact's also very important because one of the things we're going to be talking about this year is scanner support, which is being introduced into Image Capture. And so in one sense, you can have a single set of APIs in your application that allow you to retrieve images off a digital camera or access images being taken from a scanner. So it's a very exciting story. So to finish out the story, I'd like to invite Werner Neubrand, an image capture specialist image capture engineer to the stage.

Hello everybody. So I'm going to talk about the Image Capture Framework today. We have a pretty tight agenda, so we will... Look at Image Capture in general very shortly and then look into the scanner support for Image Capture and actually also talk about the Twain Framework and some other changes in Jaguar for the Image Capture Framework itself. And at the end we will have a short Q&A.

Image Capture, where does it fit? Well, you probably saw this set up a couple of times this week and Image Capture technically is part of the Carbon Framework. So Image Capture Framework, part of Carbon Framework, but it can be used from all your Cocoa applications, from all your Carbon applications.

What really is meant when we talk about Image Capture, the framework? Well, we treat the framework as a single central piece technology that deals with image capture devices. We are focused on still images. The nice thing about Image Capture is really it's abstracting the device specifics, meaning you can write a single application that works with multiple devices without knowing too much about the various devices.

It also brings you a driver architecture to create your own camera or, you will see later, scanner modules. And it, of course, supports standard architectures and protocols. So for cameras, for example, we have the PTP protocol. We support mass storage devices. And those devices on PTP on the FireWire and USB.

So if you look at this slide, you get basically an idea of what components are involved. First of all, on the left-hand side we have a camera. The camera is the hardware that you connect to your machine. It will be recognized by the system and a specific camera module that deals with this hardware will be launched. This camera module talks to the Image Capture Framework.

Which really knows about multiple connected devices and can handle multiple clients. So one client that you all get for free whenever you install Mac OS X is the Image Capture Application. And now, just as a reminder, when we talk about Image Capture, a lot of people just see the Image Capture Application, but they have no idea about the underlying framework. So there's really more. It's not just the application.

For example, iPhoto is just another client. It's also using the Image Capture Framework. It's just a replacement in the front end. And in there fit your application as well. So if you want to write an application, we'll see later on, we'll look at some code samples. It's very easy to do that. Write an application that uses Image Capture to access images on a device.

Well, that was last year's slide. This year, we are going to add scanner support. So this year, basically the same setup, we have different modules. So scanner modules also talk, get launched when the scanner is connected, talk to Image Capture, to the framework, and the framework talks to your application, or your application talks to the framework.

So before I was mentioning abstracting the device, how do we do that? Well, we do that by introducing the concept of objects and properties. Objects are the things that deal with or that are used to represent like a device, like an image or a file on a device or a folder. And properties are the things that deal with the real data. Both of them, objects and properties, are identified by a type and a subtype.

Now, last year we were showing you a slide like this, and it's actually also for Jaguar. The setup is exactly the same. So we have at the top, we have a device list that's a single object. It's always there, and that object has reference to all the other devices that are connected. Now if you look at Camera 2 in this case, Camera 2 has three images. So we have three image objects. Camera 2 has also, in this case, two properties. One for the name and one for the icon.

Image 3, I'm just showing that here, but all the other images exactly have the same, has also properties, also name and icon. And then there's a way using image capture APIs to really go and walk through the tree. and allow you an easy access to all the objects and properties.

But that's all good and fine. And we were finding out that having multiple properties, properties for all possible data, is just a hassle to work with. We will actually end up by splitting up all the metadata that belong to an image. We were about to introduce, I don't know, 20, 30, 40 different properties. And it's just a hassle to get those. Because you would have to do a call for each property. And you probably have to know the property type and subtype in front. So the idea was, well, we're introducing XML property dictionary.

And that's actually what we did, and the current system, 10.1, already has that in there. So by reducing the actual properties to just the file data and thumbnail data, so the preview icon, these are the only properties that basically stay. Well, all the others that were introduced in version 10 also stay just for backward compatibility. But the idea is reduce everything with the properties just for the real data, for the image data and thumbnail data. And all the rest is really handled with XML property dictionaries.

So again, thumbnail and actual image data are in properties. All the rest, everything else, is done and handled in XML property dictionaries. How do you get to a property dictionary? Well, there's a new call, and actually it fits barely on that first line. So the long API name, it's ICA Copy Object Property Dictionary. What it does, you pass in an object, and you get back an XML dictionary for that. Well, it's really the best way to get to image or device information.

For device object, you actually get some basic information about the device, like the device name, a reference to the device icon and all that. And for image objects, you get access to the metadata. So if we just look at the device, focus on that, and we see, well, we get the name and, for example, also device capabilities. Can this device take pictures? Can this device delete pictures? Can it synchronize the clock? All these things are just returned within the device dictionary.

Another interesting thing that is returned is actually a way to access all the data, all the images on your device. And this is actually done in two flavors. There's one flattened out, this flattened out sub-dictionary. Actually, it is a CFArrayRef. So it's an array of dictionaries that contains information about all the images that are on the device. And there's also a hierarchical representation, the tree structure. And this one contains not only images, but it contains also other data that's on the device. For example, Depov information.

Or, for example, firmware. That is really represented in the file system. We will have a look at that in a second. And if you look at the... These two, we see really, they have all the basic information that you need in order to access all data on the device.

For the image object, we also return the name, some metadata information, so basically everything that we can extract using QuickTime, the graphics importer. We extract that and put it into a dictionary, which is actually a very easy and convenient way to get to all the information that you might be interested in.

So the best way actually to learn about that and see it in practice. So what I want to do is I want to go over here and launch an application that's actually part of the Image Capture SDK. It's called Image Capture Browser. So what this application does is it basically represents the tree structure that we have inside a device.

So right now I have one camera connected to this camera. If I select that one, then it's talking to the device and brings back the information that it can get. Like in this case, everything in bold is a property. So we have two properties for that device. That's volume label and a camera icon.

It also has a directory, and that directory has a file name as property. So it is 001001. Not very interesting, but actually there's a store number on that device. That directory has another sub-directory, which has another sub-directory, and it actually has the images. So now we can select an image, and we will get some information about that. So these are the properties that belong to this first image, like the file name. DCP 0477. We have thumbnail information, image size. So it's about 236K.

That's all good and well, so basically this application is now showing all the different objects up here and properties. Just before I mentioned that it's really better and easier to just work with the dictionaries. So actually down here, I'm displaying the dictionary for the selected device up here. So for the camera, we have as part of the dictionary, we have a capability information. So this camera supports the DEL1, which means delete one.

It's a camera can take new pictures, and the camera is able to synchronize clock. Then we have the... We flattened out directory information that has all the images really in it. So if you look at the first one here, we see we have an image file name, the file size, we have a reference to a thumbnail property, and a data property. So all we have to do is when we want, for example, to download or get the data for the thumbnail, is pass this as property into the ICA Get Property Data call.

And we have additional information like whether that file is locked or not. So if you scroll down, we see this is the flattened out structure. I don't know how many images we have on here. I guess a couple. So then we get information what device module is handling this device.

Well, here we see it's the PTP camera app doing that. We learn about the file type. We learn what the ICA object for the device is. And down here we have the tree structure. Basically, the same information as in the data structure, but now really represented as an exact copy of the layout on the device memory card.

Okay, so this is just the basic setup, and the Image Capture Browser allows you also to look at the data and tree dictionary basically directly, and it draws you a nice outline. So you see we have one device list, we have, that's the DC4800 camera, and these are the images. But I can also switch to the tree view and then see really the layout on the memory card.

So let's actually, as next thing, look at some sample code to walk the tree. This is a small application. Actually, it's a command line tool that we are going to look at. And all it does is, in its main... Get some parameters. We're not interested in those now, but actually all we want to look at is the dump children function, which takes an object that's the device, the list object, and prints out some information.

So if we look at the... The Dump Children function, all it does is it gets an object and an indent and a number of planks. And for that object that we pass in, we do a get child count. So we want to find out how many children, how many sub-objects are referred by this first object that we look at.

We get back a number in this countPB.count. And now we loop over those. So we go from zero up to the... Number of children, and we do just get nth child, passing in our child loop as the index. This call, getNthChild, actually returns information about the object. And remember I was talking, an object is identified by type and subtype. So this call is returning type and subtype, and that's actually what we are dumping down here.

And if the type, the object type, is a directory, "Or the type is a device, then actually what we are doing is we call the same function, this is just a recursive function, we call into the same function and dump its object children. So if we actually execute this in the command line, It really lists the files that are in here. So now, let's go back to the first slide.

There's another interesting call that we want to look at today, and that's ICA Download File. ICA Download File is a single API that allows you to download a specified ICA object. So the call takes, as all image capture API calls, takes two parameters. The first one is a parameter plug, and the second one is a completion plug. If the completion plug is null, then it's a synchronous call. Otherwise, it's executed asynchronously, and after completion of the call, you will get called in your completion plug.

So the parameter block for the ICA download file looks like this. So you're basically specifying the object. You're specifying a directory, FSREF, that is really the destination directory. Then you specify some flags. The flags could be one of the listed ones like delete after download, create custom icon, rotate it, create or set file type and creator.

Embed a color sync profile. Very convenient. Just a single call, a single flag that you have to make.

To be executed. And on return, this call just returns an FS spec. Oh, sorry, Evers Ref, away from Evers Specs. Okay. So, well, actually, again, let's look at some source code.

What we want to do-- actually, I want to run the application first, and then show you what it really takes to do that. So the application comes up with a table view. It lists some names. These are the images on disk. And file size. We can select one image and we can download it to the picture folder. So let's do that. So here it says it was downloaded to two. And actually, if we go to the picture folder, we should see it.

So what does it take to write an application like that? Actually, it's very simple. So let me open... We see that after we awake from the small Cocoa application, of course, after we awake from Nib, we update our files and then install the notification. Well, updating the files is actually very simple. So first, we get the device list. Okay. And then we get the nth child we're interested in.

The first device that is connected. Get the nth child. Then for that child, we use the new call, the ICA Copy Object Property Dictionary. So we do that down here. And that dictionary on return... The Image Capture Framework is a software that can be used for all kinds of applications. For example, the device name, which is keyed off under IFIL. And we use that to set the window type. And then all we do is we have our own data array and set that to whatever we have in the device dictionary under the data key.

That's all we do. Now, how does that now really display some information? Well, very simple. What we are doing is, since DataArray is a data member of this MyWindow controller, we just take the count and return that as number of rows for the table view. When we are asked to return the values that we are going to display in the table, what we are doing is, we look at the identifier of the table column. If the identifier is the index, then we just return basically the row that gets passed in. If the identifier is the name, then we are asked to display the file name.

Well, that's easy to do. All we have to do is look at our data array. and get the nth object out of that, which was a dictionary. So we're looking at the object at index row that gets passed in, and that dictionary contains for the IFIL key the name of the file. That's all we return. Well, down here, if you ask for the size to display, well, we basically do the same thing. Get that dictionary that's at the end, that row position of the data array, and then ask for the data that's specified by the iSize key.

So that's for displaying. And what we want to do is really, we want to download the file. So we are listening to the mouse down on the download button. So the target for the download button is this here, this download method. And what we're doing in here is, well, we want to get the selected row. Once we have the selected row, we ask for the ICA object value.

Once we have that, then we set up the parameter block for the ICA download file.

Then we execute ICA download files so it will download the specified object and just After that, we want to display where the file was downloaded to. So we're just updating an info string. We don't want to have that there for a long time, so after four seconds, we will clear off that value. Once again, let's quickly run it.

So it's really not much of code that is involved in order to do that. Okay, so let's go back.

and talk about a complete new area for image capture and that's the scanner support. We've been asked to support scanners for quite a while, and I guess now it's really in. And for Jaguar, we will have the scanner support. And I'm going to give you a small architecture overview and talk about some additional APIs for scanners.

Architectural overview is very simple because I guess I told you already everything at the beginning of this session. Because it's the same. So we have a device list and that device list now just supports scanners. So the same thing that was true for cameras is now true for scanners. It's an ICA object. It will have properties. However, handling is a little bit different.

The handling scanners on the image capture architecture is really session-based. For cameras, it was easy to just support multiple clients at the same time. So you could really have two or three applications running at the same time, talking to the same device. You could handle that very easily.

For scanners, it's a bit more complicated because there's really no atomic scan operation. It's really, you get some scanner parameters, you set some scanner parameters, and then you start the scan. So it's really a session that you have to work with. So all our new APIs... Like the ICA Open, this kind of Open session, and Scanner Closed Session are working with a session ID. So for the first one, basically it returns the session ID that you're going to use on all subsequent ICA scanner, whatever, APIs.

There's a scanner initialize and a scanner status call. Scanner initialize basically sets the scanner in a default mode. Getting the scanner status will report the current scanner status and give you information about the device. These are very important calls, the get and set parameter call. Because set and get parameter allows you to control really the scan area resolution and everything you want to do.

And these calls, you'll see that in a second, are really set up around property dictionaries that you pass around. So the get parameters returns your dictionary filled with all the information that the scanner module puts in. And on the set parameters, you fill in information about the scan that you're going to start with the next call, with the ICA scanner start.

Let's have a look at Scanner on the Internet.

What you should see is that we will recognize the device. This is a small application that just shows what devices are connected. We have a Type 1 scanner connected. Let me just look at a small...

So what this does is basically it's just exercising the different APIs. So after I opened the session, I did get back an ICA scanner session ID. And now I can, for example, get scanner parameters. And scanner parameters have information about the device. See, we have tablet height, resolution minimum, maximum, some basic information. I can actually set the parameters.

And by just doing that, I'm filling in some information, for example, the resolution and X and Y, bit depth and all that. So I'm downloading the parameters to the scanner. And with the ICA scanner start, I would actually exercise the downloaded parameters. You probably don't hear it, but the scanner is doing something. Currently, this small app is not displaying anything useful, but let's look at the code.

For example, for the get parameters. So, get parameters. All we do is we create a NNS mutable dictionary. Set that equal to the dict in the ICS get parameters parameter plug. and just do an ICA scanner get parameters. After that, we display the result and see that, we saw that in the window, all the information that we got back. And then we release the dictionary.

Well, for doing the set parameters, we basically do the same. See here? I do get the parameters first, but I'm going to add... I'm going to add a new information to it. I'm doing that down here. I do set The user scan area. And the user scan area is something that I do set up here.

So for the user scan area, I'm setting up and specifying the color mode, bit depth, resolution, and offset width and height. Now this is a very simple setup. You can add much more parameters, but this actually is just enough to do a low-resolution scan of the entire area, scan area.

Looking at the scanner start, well, all it takes is a session ID and then the start, and it currently produces, this plug-in that we have, produces in temp a scanned image directly. And I'm... Just not displaying it right now. However, we have of course also a new version of the Image Capture application that Basically does the same thing. So, Image Capture Application is now handling not only cameras, but also scanners.

The way we do it is we have come up with a plug-in concept for the UI. Basically, it allows you and us to have multiple devices with different UIs all within Image Capture. For example, if you want to have your camera vendor and you want to have your own UI for a specific camera, then it's very, very easy to plug that in.

So in this case, the scanner is really handled by the scanner The Image Capture Framework is a plug-in, and what you can do is... You can do a fine scan or better scan of the selected area and get that. There are some parameters that you can set, but that's just the very first UI. We're still working on that and it will be a fleshed out version in the Jaguar release.

Another important thing is, as for all camera devices, it's also true for scanner devices, we will have device-specific parameters in the image capture application for Jaguar. Could, for example, have device-specific profiles or settings, whether you want to download and create custom icons or not? That's the simple-to-use scanner UI within the Image Capture application.

So there's really one application that does both cameras and scanners. Switch back to the...

Well, scanner drivers are supported by Image Capture and we support basically two flavors. One is the Image Capture native ones. These are the scanner modules that are very similar to the camera modules that we support. And we support twain data sources.

Let's look at the image capture ones first, the native ones first. Well, we again have a scanner device framework that's very similar to the camera framework. It has just a whole bunch of codes that you normally have to deal with when talking to the device and more administrative things, like whenever a device gets connected, you have to register it with Image Capture so that it can talk with that.

So all that code is really provided by us in this framework, one for cameras, one for scanners. And the idea behind it is by just having you implement a couple of functions that talk to the hardware directly, it will be a lot easier for you to create scanner or camera modules.

One thing that we were also asked by a couple of vendors was button support. A lot of the new scanners have a button or multiple buttons in front where you can click to do a copy, click to do an email and all that. And yes, we will support that.

So, Again, we will have something in the scanner framework that deals with that. And we can do it because what you have to do to enable it is really put some information in a special P-list. So this camera or scanner module... has deviceinfo.plist that contains information about the device.

We will have a short overview of the train framework on Jaguar, look at some data sources, and also client applications. Well, Twain was established as an industry-wide standard, and it's used all over the place. I mean, for a long, long time, we have Twain data sources. However, the support on Mac OS 9 was unfortunately not really that great, because a long time it was not updated and all that. But for Mac OS X, I guess we have a really good solution.

So, the three key components that are really important for understanding the overall Twain framework are: we have client applications, very similar to the Image Capture client applications. We have a data source manager, very similar to the Image Capture Framework. And we have data source, very similar to an Image Capture camera or scanner module. So the really important part for Twain and Jaguar really is Twain is part of Jaguar. So for the first time on Macintosh operating system, we are installing Twain by default.

And the nice thing is, if you already have an application running with the current beta,

Stop installing the Twain shared library, the CFM shared library. So if you have an application that you are...

We will install the DSM basically at two different locations. Well, we have, as I said before, Twain as a native Mac-O framework in system library frameworks.

And we have some clue code for CFM-based applications in System Library CFM Support. There's also a new location for the data sources. So if you are going to install a data source, it's no longer in the application support folder, but it's really in System Library Image Capture Twain data sources.

So the Twain DSM was rewritten to be now MacO based. And the nice thing is really it supports then MacO based Carbon and Cocoa applications. And of course, they made sure that Twain supports MacO and CFM based data sources. So both flavors will work. There are a couple of issues if you're currently writing a DS.

Unfortunately, you have to rev. So the client application does not have to do anything, but the DS writers, they have to rev. They have to rev in four points that we want to look at now. The first one is packaging. It used to be that they were just CFM shared libraries, single binary.

Well, that doesn't work good with the framework and the overall Mac OS X, so we ask you to really create bundles. Well, these could be CFM or Mac OS bundles, but put them into a bundle. This gives you actually a lot of advantages. Also, like localization, so you can have multiple languages of your DS in a single binary, a single folder bundle.

Well, for a new Carbon application with the Carbon event model or Cocoa application, there's really no easy place to hook in your wait-next event for that. It was really bad because you had to, like, before calling into wait-next event, you had to call into the DS and give it some idle time.

Then you get the wait-next event, and after that you have to ask the DS, is this event for you? The DS would say no. It comes back to the application, and the application handles it. Kind of bad. It's really this polling mechanism. We want to get away from that. So the new DS has to support the Carbon event model.

It should not be too hard to convert existing DS to this Carbon event model. All you do is basically, wherever you were called and asked to handle an event, now you install Carbon Event Handler for that window or control, and then your handler gets called directly and you handle that event.

The old wait-next-event model was also used to pass information back from the DS to the client application. Well, of course, that's not working anymore. So what we had to do was really introduce a callback mechanism. So a new... The TWAIN client that you will see some source code for TWAIN client written in a small Cocoa app, really will not get data back from the DS based on a wait-next-event call, but it will get called via a callback. and you will get informed through that callback whether there's a mistransfer ready or whether the DS will close.

We also ask you to support an optional feature that was the UI-less operation. So what we really want is that the user choose whether to use the original Twain UI or our very simplified UI within Image Capture. So in Image Capture, in the application, there's an option which one to use. The user can choose.

And we ask you, as a 20DS developer, provide us with a device Info.plist and add that to your bundle. And that device Info.plist should contain some information about the device itself. By just doing that, we will be able to detect, without loading the 20S code, to detect whether a device that's connected is handled by a given DS.

This has a great advantage over the current model because if you you will see that when we use for example Photoshop to handle or to use a TWAIN DS is all they can do, and there's really no way around that, all they can do is go through the installed DSs and add them to a menu.

They cannot at runtime detect whether a DS is able to handle the connected device. Or if there's no device connected, they even list all the devices. And then you open the DS and then the DS will get loaded and will tell you after maybe 10, 15 seconds, well, I couldn't find the device on the bus. That's kind of bad user experience. It would be nice to just dim that menu item or not even show it at all if the device is not connected. So we will get to that whenever we evaluate the device Info.plist.

So for Twain clients, like the previous model, as I said, was around wait next event, and it still works. So if I would show you Photoshop running using the new Twain framework, Photoshop was not modified. It just runs. So what we do is really getting the event calls from Photoshop. We just pass them back immediately and still use that mechanism to really communicate from the DS to the Photoshop application. So the important thing is really here for newer Carbon, newer Carbon means really Carbon event based applications, and Cocoa applications, they really have to register callbacks.

And the callbacks, they look like that. It's very similar to the regular DSM entry call. And all we pass back is, or all we pass into this call is DAT callback and message register callback. And the callback function itself could look like that. It has the same parameters and you get back a message. And the message could be, for example, there's a close DS request.

And then your client application will just call TWDisabledDS and close the DS. So let's have a look at the sample.

Epson, Twain, for Jaguar. So the Epson guys helped us recreate with providing us a new native DS that uses the Carbon event model. And you see the standard Photoshop application is just working. So I can select this and do a scan.

Let's see. So when the application did finish launch, what we do is we initialize Twain. Initializing Twain means we have to set up application identity and call into TWInitialize. This TWInitialize is a function that gets actually part of some Twain sources that are part of the Twain SDK. So you don't have to write that yourself. And just use that. So this is directly out of the SDK. Use that.

Fill in some information like the language, country, and all that. So after the... When TWAIN is initialized, we register a callback. Registering a callback This is a function that we added to the Twain sources. It's basically directly communicating whatever call I was showing you earlier. Well, that's it on launching. So we have a select data source. Well, that's the regular TW Select DS part of the train SDK. And we have... "We have a TW acquire where we do a TW acquire. Unfortunately, currently the native image type is still a pick handle.

So we get back a pick handle and have to convert that into an NSImage because we want to show that. We do that with an NSImage alloc with data and pass in the image data and set the M image and that's basically it. So let's run this small app.

So that's the new native Mac O Twain DSM showing this selection dialog. You noticed before that Photoshop is not using that dialog. Photoshop is just evaluating, examining the DSS directly and adding those DSS that it finds to the import menu. So this application is using the selection dialog. And we can do acquire. The first thing you acquire in this case brings up the 20S.

"We scan in the image, actually it's currently still open, close it, and we just scan in an image in a Cocoa application that's just a couple of lines of code." Okay, so we both have, well we have now two different ways to talk to a scanner. Image Capture and Twain. See the sample application here we were just using Twain APIs to do the scanning. Another question is really for you.

How do both work together? So do you have to install one or remove the others or all that? Well, actually, we will have a Twain bridge. So that means we will have a piece of code, an image capture device module, that talks to a Twain DS. So that means that you can still be all in the image capture world, the ICA API world, and use the 20S.

The advantage of having this train bridge is actually one thing that I mentioned before. That's also the button support. Because train bridge will get launched whenever the scanner is connected. Then this Twain Bridge is running and it actually will monitor device buttons. So you press a button and the Twain Bridge will listen to it. Then depending on the section that you made before, actually it will allow you to trigger the correct action.

So device arbitration is just what I said. And for you, the question now. Which framework should you use? It's really up to your needs. So, Image Capture should give you an easy way to work with Image Capture and 2nds devices. Twain is probably more powerful because you have more control. So the Image Capture Approach is really keep it simple, make it simple for a lot of applications to just have an acquire or import button. But if you really want to go into the depth of controlling the device, Twain might be the right way.

Now let's look at some other changes in the upcoming Jaguar release. First of all, Digital Hub. Digital Hub and Application Launching is something that will be new in Jaguar. And we actually got asked a couple of times, how do I change the hot plug action on a current Mac OS X system? So a lot of people were installing iPhoto, and iPhoto may be their default application for a while, but if they just want to change that to an image capture or another third-party application, how do they do that? Well, unfortunately, they had to go to the image capture application. Although it has only three pop-ups, it was not quite obvious for a lot of people, so we got a lot of questions about that.

So I guess the better solution is really, and not only for image capture devices, but a lot of other devices, since we're claiming to be the ideal digital hub, We will have, and you probably saw that this week already, we'll have a digital hub panel or part in the system preferences. So let me just show you that.

So, going in here, you see System Preferences come up with a Digital Hub part and for photography, well, you can now choose what to do when a camera gets connected, when you insert a picture CD, when you connect a scanner, or when you press the scanner's button. So it's quite often probably that you will want to do nothing when the scanner is connected, because quite often the scanner is connected all the time. And you want to activate your application only when you push a button on it. That's the way to launch it. And while we are here, the upcoming changes, one thing I want to show you as well.

That's new in the new version of the Image Capture application. I was saying before that one application, due to plug-in mechanism, is now able to handle multiple devices and present multiple UIs. See, the same application here is now showing the UI for camera. The only difference to the current version, at least the first difference is there's one pop-up missing, the hot-block action is missing. That's really now part of the digital hub. These options are now, I mentioned that before, are device specific.

So you can specify a profile per camera, and that will stick with that camera.

So if you're at home and you and your wife or you and your husband, they have two cameras. www.img-report.com/image-capture-frame work-applications/ So downloading SAM, well, it's also a bit new UI here. But also one very nice thing is you have the pop-ups also in this window. Basically, you can go to the data browser window, select a couple of images, specify a download folder for these two, press download, and download the two, and download the next four to a different location.

So a couple of things that we actually added to the UI here. For example, you can also add a thumbnail size here and then

So one upcoming change is an extended event notification. The current mechanism was not that suitable to propagate events that come from the device to the client application directly. So currently we are supporting very well device connected, device disconnected, image card removed or put in, or image was taken. This camera actually can take images from within the Image Capture application. Or whenever you delete an image, then also the client application gets notified.

But there are some cameras that have some events that they produce. For example, the camera is connected. You take pictures from there, so there's no interaction from the client application. You take the pictures directly on the device, and you still want to propagate that to the client application. For that, we really had to extend the current event register notification parameter block, so we were adding things to it, like...

So registering and unregistering is actually the same as before.

You register by specifying an object that could be nil to an EXCD to get notified for new notifications of 00 in both cases to get notified on all events. And to unregister, basically use the same parameters as on the registration except specify null as completion proc. So in this case here, we are just doing a registration for all events. And on registration for all events, you see the difference is that my completion proc gets changed by, replaced by another.

DeviceInfo.plist, we talked about that a couple of times before, and we really have that as a way to identify more features of the device. And for example, currently we use that to display a nice camera icon. Depending on the model that you connect, you will see that Image Capture Application comes up with a real nice icon for that device. And that's really done based on the information in the Info.plist.

Well, we also are going to extend that and add some more information in here. For example, a color sync profile. So the color sync profile and device class information is added to the Info.plist. and allows us to use and embed later on the correct profile for your images.

One other thing where we are going to add a new feature that's a pass-through mechanism that's basically a simple way to control device-specific features. So if you know exactly about the device that's connected, most likely that's a vendor-specific application. So if you know about that device and you want to do some private calls and private commands, send that to the device. That's also easy to do now with a pass-through mechanism where Image Capture just treats it as a plug of data. We send it to the device and the device knows what happens with it, what to do.

Metadata for input devices. Well, of course, there are some color issues, and you probably learned earlier this week that Megalos 10 is really a full color-managed environment. And in the ColorSync session, you also learned about a couple of weak links in that whole ColorSync workflow. Like one weak link is right at the beginning. That's whenever we get the images from a digital camera, and they may not contain ColorSync profiles.

But the user may want to embed a ColorSync profile. So what is the best way to do that? Well, actually, a good way is whenever I'm going to embed a profile, I use the default profile for input devices. A better way is the device itself specifies a profile for all its images. Actually, the best way is if the device would specify a per-image profile.

And now it's important for your application, dealing with images, that you preserve the metadata. Preserving metadata... is also preserving embedded profiles. So if the device embeds a profile,

And I guess the last thing I'm going to show you is a small application that we have, and it's called Camera Check.

And the idea behind it is really give the user a chance to hook up his camera and then see about the capabilities for that camera. So in this case, I have the Image Capture application. Just quit that and launch Camera Check. It comes up with a dialog saying, well, a couple of things about the application.

It tells you about its preferences and allows you to...

We'll find out that this device is able to take pictures. So the result is okay. That means if I go back to the Image Capture application, I can actually... "I'm going to drag this one up here. So I have a take picture and what I can do is then really go in here. Take a picture and then after the camera stops flashing, the new picture should show up and be in here. So just, okay, not great. Okay.