Retaining EXIF data

[Fastie]

Pat Coyle reports that the output files from the Fiji macro do not have EXIF data even when the input files did have EXIF data.

[jywarren]

I'm happy to write a script to extract EXIF data, and perhaps dump it into a text file... but i haven't tried the macro yet and don't really know what the workflow looks like yet. If it's a graphical interface and people aren't expecting any command-line scripts, it might not be helpful to have a batch script which collects the EXIF data.

I'll try the macro out soon enough, but it's just a thought.

[Fastie]

In order to submit the ImageJ macro NRG output files to Hypr3D, I had to add EXIF data to them (Hypr3D refused to work without EXIF). I used Exiftool: http://www.sno.phy.queensu.ca/~phil/exiftool/. It is completely command line, but seems to be comprehensive, so it could do whatever we need. I created a batch file with photo pairs of the jpgs from the camera and the matching output from Ned's script. It looked like this:

exiftool -tagsfromfile LeeNIR-20120523-176-11.jpg CRW_0063_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-13.jpg CRW_0064_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-16.jpg CRW_0066_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-25.jpg CRW_0075_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-27.jpg CRW_0077_NRG.jpg and so on...

I used Excel to concatenate the lists from directory listings. This requires staying on top of which file goes with which. The LeeNIR-20120523-176-xx.jpg files are from the camera and the CRW_xxx7_NRG.jpg files are from the ImageJ output files. Hypr3D was happy with the results.

[jywarren]

Hypr3d folks seem to be watching what we're doing... we could ask for a feature to simply append a dumped set of exif tags in a certain format, with image file names. Something like:

{ filename: "image_1001.jpg", exif: "EXIF DATA HERE" },
{ filename: "image_1002.jpg", exif: "EXIF DATA HERE" },
{ filename: "image_1003.jpg", exif: "EXIF DATA HERE" },
{ filename: "image_1004.jpg", exif: "EXIF DATA HERE" },

Then we could write a script to easily generate that file from a list of images, and Hypr3d could offer that on their site too.

On Tue, Jun 5, 2012 at 2:49 PM, Fastie < reply@reply.github.com

wrote:

In order to submit the ImageJ macro NRG output files to Hypr3D, I had to add EXIF data to them (Hypr3D refused to work without EXIF). I used Exiftool: http://www.sno.phy.queensu.ca/~phil/exiftool/. It is completely command line, but seems to be comprehensive, so it could do whatever we need. I created a batch file with photo pairs of the jpgs from the camera and the matching output from Ned's script. It looked like this:

exiftool -tagsfromfile LeeNIR-20120523-176-11.jpg CRW_0063_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-13.jpg CRW_0064_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-16.jpg CRW_0066_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-25.jpg CRW_0075_NRG.jpg exiftool -tagsfromfile LeeNIR-20120523-176-27.jpg CRW_0077_NRG.jpg and so on...

I used Excel to concatenate the lists from directory listings. This requires staying on top of which file goes with which. The LeeNIR-20120523-176-xx.jpg files are from the camera and the CRW_xxx7_NRG.jpg files are from the ImageJ output files. Hypr3D was happy with the results.

---

Reply to this email directly or view it on GitHub: https://github.com/nedhorning/RegisterPhotos/issues/4#issuecomment-6133145

[Fastie]

I guess the only thing Hypr3D needs from the EXIF data is the camera model (plus lens), and the focal length. So if we ask for a new Hypr3D function, maybe it would be to have that in the EXIF data of the first image uploaded.

[nedhorning]

This is probably best done outside of the Imagej/Fiji macro.

It shouldn't be too difficult to write something that will read the input file we use for the registration macro so the user doesn't have to do any formatting. The input would be the following information: image registration text file directory of photos that will be used as the EXIF source (must have images listed in the image registration text file) directory of files that will receive the EXIF data (output files from the registration macro) type of images that will receive the EXIF data (NRG, Color NDVI, Clipped visible image)

With that information the program should be able to do what it needs to do.

[nedhorning]

Is anyone interested in writing a script? I probably won't unless there is reasonable interest. The spreadsheet option is quite simple since the registration macro just appends NRG, NDVI_Color, or clipped to the input file names. Cutting and pasting from the macro text file makes it pretty simple to create a batch file like Chris did.

[Fastie]

The only files that have the desired EXIF data are the jpg files that the camera saves when it saves the RAW files (and I assume the DNG files too if that option is taken). By default the camera names the jpgs IMG_xxxx.jpg and names the RAW files CRW_xxxx.CR2 where xxxx is the same accession number. So that makes matching synchronous pairs easy, as long as two things don't happen:

1) One of the cameras fails to shoot an image 2) the files are renamed as they are transferred to your computer.

[edit: The above is not true. See my next comment. The two cameras will not be using the same accession number]

In my brief experience, both of these things DID happen. Especially when I was using radio triggering, but also when I used the MK111 timer, one or the other camera sometimes failed to shoot when the other captured an image. Also, my workflow is to use Lightroom to transfer photos from the SD card to the computer in order to create a database with tags, metadata, etc. I always rename the files during transfer to make the names more meaningful. I think I can preserve that xxxx number, but I have never had a reason to before.

So I might need a new workflow. But that would not solve the problem of individual cameras failing to shoot. So the user might have some work to do to create that first list of photo pairs. And the user has to be sure that CHDK is using the default naming conventions or at least be aware of which conventions are used.

There is probably no foolproof way of doing this. Users should be made aware of workflows that make it easier.

[Fastie]

My last message had a logic flaw.

Although the jpg and RAW files produced by a camera have the same xxxx accession number, each camera will be using a different series of accession numbers. So the NIR and VIS images will not have the same number even if neither camera missed any captures. IF no captures have been missed, it will be easy to match NIR and VIS image files by adding some number to xxxx on all the files from one camera.

[edit: the utility described below is completely unnecessary] The utility program that is needed would display the NIR and VIS images of a putative synchronous pair and allow the user to accept them as a pair or move to the next image for one or the other until another pair is displayed. It would be important to be able to view lots of the other images to look for the missing mate in case a camera had missed several captures. Then a list could be generated of the matched pairs. This is obviously not a trivial piece of code.

Of course the RAW files would first have to be converted to tiff or something that can be displayed. The DNG files are probably easier to display without converting, but they have to be converted anyway, so that step should precede the pair matching step.

But none of this is needed if Pat is correct and the CHDK DNG files have EXIF data. In that case, the EXIF timestamps in each DNG file can be used to match the synchronous pairs from the two cameras. A list of synchronous NIR/VIS pairs of DNG and/or JPG files could be generated and used as the text file for the Fiji macro and as the basis for a batch file for returning the EXIF data to the ImageJ output files after the macro had run.

So ignore everything I have written lately except the last paragraph. [edit: ignore the last paragraph, too]

[Fastie]

My previous comments were not very helpful except that they might have allowed me to understand the problem a little better. Here is my latest fuzzy logic.

1) The workflow that avoids jpeg has two justifications: Avoiding jpeg compression artifacts might allow better registration and it might reveal more detail in the NDVI patterns. However, we have not tested whether the pure tiffs register better than jpegs, and we have not demonstrated that the increased resolution resulting from tiffs allows improved interpretation. So it is hard to recommend the arduous non-JPEG workflow to any but the most dedicated IR camera tool user. It is a lot easier to use jpegs because 1) they are much smaller, and 2) they do not need to be converted. But using only jpegs does not eliminate the need to make a text file with image pairs for the ImageJ macro, or the task of restoring EXIF data to the output files from the ImageJ macro.

2) Even if jpegs are used, the synchronous pairs of NIR and VIS photos from the two cameras must be found. The smartest way to do this is to carefully synchronize the clocks on the cameras to within a few seconds (less than half of the shooting interval) before capture. Then the jpegs will sort by “file creation date” in most common viewers with the pairs side by side (revealing any missed photos). Using the file creation date, it should be straightforward to write a script to output a list of matched NIR/VIS pairs ready for the ImageJ macro. This script can be a big time saver if there are multiple missed photos by one or both of the cameras.
3) Sorting the images by “file creation date” will work without the need for EXIF data, as long as the method for transferring images from SD card to hard drive does not alter the date. Maybe we can’t guarantee that all users will transfer the files with creation date intact. This sorting by creation date should work even for RAW files with no EXIF data. So I guess it should be possible to write a script to produce a list of matched NIR/VIS pairs based on the file creation date for DNG files or for RAW files with no EXIF data.

[edit] 3.5) If the RAW or DNG files have been converted to tiff, the file creation date of the tiffs will not be useful for matching pairs. So a script would have to use the accession number in the filenames to link to an image file produced by the camera to find the matches based on the file creation dates.

4) After the ImageJ script has run, four new files are produced for each NIR/VIS pair (e.g., CRW_0066_Clipped.tiff, CRW_0066_NDVI_Float.tiff, CRW_0066_NRG.tiff, CRW_0066_NDVI_Color.tiff). These new files apparently have no EXIF data regardless of input files, and their file creation date is not useful for matching them with the original files which still have EXIF data. EXIF data is important for submission to Hypr3D, and might be handy to have for other reasons, but it is not necessarily critical.

5) Any EXIF data will probably work for Hypr3D as long as it has the correct camera model and focal length. So a script or Exiftool batch file could write the same EXIF data to all of the output files. But there may be other reasons to have the correct EXIF data on all the output image files and all descendent files.

6) To restore the correct EXIF data to the ImageJ output files, each file must be matched with one of the files in the NIR/VIS pair that it was made from. The only information available for this matching is the camera accession number in the file name. The accession number in the output files are currently just copied from the VIS input file. Because of this naming convention, a script can produce a batch file for Exiftool which can copy the correct EXIF data to each output file. Or the script could do the copying itself. The correct EXIF data must come from a camera jpeg or file derived from a DNG file. If the VIS input image was derived from camera RAW, it will have no EXIF data and the script will have to find the data in the camera jpeg with the same accession number. (Alternatively, a script could have restored the EXIF data to the input image file before processing by the ImageJ macro.)

7) Ideally, the script would accommodate the renaming of jpegs as they are transferred from SD card to hard drive. The camera accession number will have to be present in the new file name, but the name will not be as predictable as the default camera filenames. This might require some user input so the script can parse the new name.

8) The actionable items in this list are: a. From numbers 2 and 3 above: Write a script to output a text file with the matched NIR/VIS pair filenames ready for the ImageJ macro. The matches are discerned from the file creation dates (times) of the image files. If the RAW or DNG files have been converted to tiff, this is harder because the original file creation dates are lost. b. From number 6 and 7 above: Write a script to produce a batch file for Exiftool which can copy the correct EXIF data to each of the files output from the ImageJ macro. Or the script could do the EXIF copying itself. The matching of pre- and post- macro files is discerned from the camera accession number in the filenames – the number from the VIS input filename is used in all output files.

[nedhorning]

I wouldn't be surprised if JPEGs give equally good registration results but there are some other reasons for recording TIFF (or other lossless formats) such as improved image classification results. Using lossless images will improve interpretation capabilities but that improvement might not always be significant. The main reason for recording these larger images for me would be that I can always reduce the quality and file size from a lossless format but I can not go in the other direction. I'm in favor of trying to simplify that process.

For the actionable items I'm willing to create a spreadsheet example/template that could be used to facilitate making an Exiftool batch file to add EXIF data to images output from the registration macro if people are interested in that. It's not an ideal solution but it would illustrate a simple (but a little clunky) step-by-step process. In the longer term I might work on something slicker but I need to get back up to speed with Java or something else first. I'm happy to work with someone interested in doing the programming. I could probably put together some pseudo-code to describe the process.

[Fastie]

For testing purposes, there are now 13 NIR/VIS pairs of TIFF files made from camera RAW files in the FijiTiffs folder at dropbox. These are from the Lee, NH flights and include pairs that are easy to register and some that are harder to register. In the TextFiles sub-folder, there are a few text files ready for input to Ned's ImageJ macro. One of these text files has a list of all 13 pairs. In the CameraJPG folder there are 13 camera jpegs of the VIS half of each pair. These have EXIF data (the TIFF files do not). All the image filenames use the default camera or CHDK naming conventions.

There is also a text file with the links between the camera JPGs (with EXIF data) and the output files from the ImageJ macro (which will have no EXIF). This could be the basis for a script to copy the EXIF data to the output files.

This whole folder could be moved to some more convenient place if one is found.

[Fastie]

Ned, I am not sure hysteresis is sufficient justification for avoiding lossy compression. Unless there is a good chance that tiffs are going to allow more meaningful interpretation of the NRG or NDVI images, dealing with big files, long shutter intervals, file conversion, partitioned SD cards, and missing EXIF data may not be a good investment of time and energy. The question is whether the IR camera itself can produce good enough data to merit treating it with great precision. The unknown width of the NIR and red bands, the potential for band overlap, and the inclusion of green wavelengths in the red band might make our efforts to avoid lossy compression unrewarding. There does not seem to be a good way to answer these questions without a lot of testing, but my first experience with the non-lossy workflow has raised doubts about its cost:benefit ratio.

[nedhorning]

All good points. I have been working on some testing protocols but it's slow going. Discovering the weak links for different applications will help us understand constrains but will also provide ideas on what needs improving. Maybe we need another outing to increase the inspiration again.

[jywarren]

I'm sorry i've been distracted by spectrometry and website work the last couple days. As to the delicate balance of good-enough-and-more-likely-to-succeed vs. better-results-and-more-thorough-but-harder, i tend to want to demonstrate "fluency" in the easier path first, then slowly inch towards a more rigorous and higher-end methodology. Mainly because lots of people doing it pretty well seems more worthwhile than very few people doing it super well. So perhaps we might focus on the low-hanging fruit and describe a complete working method that's more minimal, before trying to bite off too much.

[nedhorning]

I think we're more or less of the same mindset. I try to work on making it easier to get better more thorough results. We all have personnel preferences like the TIFF/JPEG discussion illustrates but ideally most of the the tools I work on will improve work-flows regardless of those preferences. I also want to research some of the technical details since that is helpful to make improvements.

Regarding the main topic of this issue unless someone else takes this on I will probably start working on a solution to replace the spreadsheet alternative to deal with EXIF and imagepair matching in the next couple weeks. My current thinking is to write it in Java and possibly add it as an ImageJ plugin. For the time being it might make sense to create a plugin group for all of these aerial photo plugins so all the functions are in one place. Any other thoughts?

[Fastie]

RAW vs JPG: We should be prepared to explain how choosing RAW or DNG over JPG could possibly produce better results (although we are not quite sure they do), but also explain exactly how this choice could make one's life more difficult.

Macro vs Plugin: It's great to hear about Ned's plans to continue development. I assume plugins are a more robust way to distribute and implement the programs. It might also make it harder for some to contribute to its development (requires Java) but that is probably irrelevant. We should be sure to publicize this development process and encourage more beta testing and more ideas about features, etc. Frequent updates at PLOTS and the forums about new versions, added features, etc will allow more to contribute.