The data is displayed in the uploadr, which is later sent along to the API with the uploaded batch. Each of the processors uses postMessage() to post the Exif data back out and is caught by the module. One for Exif data, one for XMP formatted IPTC data and one for unformatted IPTC data.
The worker receives the binary string and passes it through multiple Exif processors in succession. FileReader.readAsBinaryString() is called, passing in the blob slice, to read it as a binary string into the worker.īinaryReader.readAsBinaryString(filePart) An event handler is created at this point to handle the reading of the Blob data and pass it into the worker. We create a new FileReader object and pass in the Blob slice to be read. The Exif specification states that all of the data should exist in the first 64kb, but IPTC sometimes goes beyond that, especially when formatted as XMP. Using Blob.slice() we pull out the first 128kb of the image to limit load on the worker and speed things up. Parsing XMP data, for example, is done outside of the worker because the DOM isn’t available in worker threads. Any additional processing is also done at this time. When a web worker calls postMessage() we capture that, check for Exif data and then display it on the page. Then when a user adds an image to the Uploadr we create event handlers for the worker. The first thing we do is pre-fetch the JavaScript used in the web worker thread.
#Photo raw exif editor change time offset code
Once we had a web worker prototype setup, we next had to write to code that would parse the actual bytes. Therefore freeing up the user’s browser, so they can continue using Uploadr while Exif is being parsed. Web workers allow us to offload the parsing of byte data into a separate cpu thread. We then quickly realized that making a user’s browser run through 10 megabytes of data can be a heavy operation. We found a few people had accomplished this already, it’s not a difficult feat, but a messy one. We started doing some testing and research around parsing Exif data by reading a file’s bytes in JavaScript. When they drag those photos into the Uploadr, BOOM, we show them the data they have already entered and organized, eliminating the need to enter it twice. Users can also add titles, descriptions, and tags in a third-party image editing program saving the metadata into the photo’s Exif. It allows us to show the user a thumbnail without putting the entire image in the DOM, which uses a lot of memory and kills performance. Why would we need to parse Exif on the client-side, if we are parsing it already on the server-side? Parsing Exif on the client-side is both fast and efficient. This lead to the realization that we could parse Exif data while the photo is being uploaded, then expose this to the user while they are editing their photos in the Uploadr before they even hit the Upload button. Sometime in the beginning phases of spec’ing out the Uploadr project we realized modern browsers can read an image’s data directly from the disk, using the FileReader API ( ). An opportunity to parse Exif data on the client-side We currently use ExifTool ( ) to parse all of this data, which is a robust, albeit server side only, solution. This page will show you all the data recorded from your camera when a photo was taken, the camera type, lens, aperture, exposure settings, etc. How Flickr currently parses Exif data.Ĭurrently we parse an image’s Exif data after it is uploaded to the Flickr servers and then expose that data on the photo’s metadata page ( ). In this case we are concerned with the tags standard and how it is used in still images. A standard that specifies the formats to be used in images, sounds, and tags used by digital still cameras. Exif is short for Exchangeable image file format.
0 kommentar(er)
