As mentioned, for the moment, there is not in our pipeline adding Flir Duo as a rig in our database. Hence the only way to process is RGB in one project and thermal project in another.
R-Jpeg
The R-JPG (radiometric JPG) format is a JPG image with the initial radiometric data embedded in the image metadata. The R-JPEG is a proprietary format, and Pix4Dmapper can read the original radiometric data embedded in the metadata.
But users may want the imagery in another format, for example, tiff or jpg. For this FLIR has a conversion tool internally that changes/transform the imagery from R-JPEG to tiff or jpg. The problem is that we do not know precisely how they process the data so for that we have an internal conversion tool from our side, and we turn imagery in tiff format in a way that we know so that we preserve the radiometric data
All Prior
In general or better said the internal camera parameters ideally should be independent, but this is not always the case. Very often when a project contains uniform data (flat terrain, sand, vegetation), there may occur correlations between the camera parameters since you will have fewer ATP’s at the edge of the images. Having less ATP’s means less accuracy which in your case leads to very high optimisation. Using_ All prior _forces the optimisation to trust more the initial values for initial internal camera parameters values.
_ For processing issues: _
Could you please confirm that focal length, pixel size and distortions are set correctly (see my first comment to Balint)?
@Balint if you successfully processed with the first recommendation you could add the camera model to the user camera database and then load it with the next project. But again it is always recommended to do the calibration with a small dataset (approx 100 images).
As per the dataset I have downloaded, and I will test it from my side.
I have tested the dataset from my side; below I will also enumerate the checklist that I have followed before processing:
first I clean the dataset by removing the takeoff and landing and split the project in 2; splitting the project in 2 assured more flexibility for the calibration
I also need to ensure the pixel size is 17; as from the EXIF is read as 39 I had to change it manually
as the camera is not in our database I had added the normalisation line in the.p4d; you can find the instructions here.
opted for Thermal Camera template
Even though I have obtained satisfactory results, the dataset is not suitable for calibrating a new pair of lens. For calibration, a smaller dataset, with high overlap and grid flight pattern would be more suitable.
@balint could you please give me more details on why you had flown so high? are there any restrictions?
Thanks for the information, just like Reto when we have the Flir Duo Pro r we can share some testing datasets in order to develop a Thermal Processing guide for the Flir duo pro r or XT2. I would be more than happy to help on that.
So probably what I and Reto are interested are the reflectance maps? and they have to be processed separately from the rgb images, once pix4d splits the two we processed the RGB ones normally and the Thermals with the reflectance map turn on
Thanks for your update and for the time spent with the dataset. The simple reason flying 250m AGL is that we need 50 cm/pixel resolution and we have to do survey on a large area: 37 km x 400 m, so it would be highly inefficient to fly lower.
I think we can perform a grid flight plan if that would help pix4d to put the camera into the “official” database.
What is your suggestion for calibrating a new pair of lens - do you need high texture content and 90% sidelap and overlap, or 80-85% is enough ? We can mount the camera on a DJI M600 and fly at 50-80 m AGL.
Unfortunately, we do not have this camera in our office either an available dataset so that we could add it to the database.
As per integrating both cameras as a rig, this is not possible since we are not sure if the cameras are synchronized (depending on the source some say it is some say it is not) and we also do not know the rig translations nor relatives.
@balint since the thermal sensor is generally tricky to calibrate (small sensor, low feature, and contrast, little temperature range within one image etc…) flying at such a high altitude is not helping. What I would recommend is to stay at a GSD around 10cm/pixel and fly the area in smaller projects.
Hi there, I have a final question, since we have to process the two separately, are the RGB and IR going to be correctly overlapping once i open them on a GIS Software? Since the Images have the same GPS location, I assume that can erase differences?
If after step 1 you merge the project the results from step 2 and step 3 will overlap since the same point cloud is used to compute the DSM on which the orthomosaic or the emittance map will be projected.
If you process them separately, you will have to align them using GCP. In case you do not have GCP you can extract some point from RGB and use them as “fake GCP’s” in thermal :-).
I believe the overlap will be ok, but since the camera calibration is done separately they will not match each other in terms of content. Simply the FLIR pictures will be projected onto the DSM generated by RGB. Am I missing something?
So my objective would be to create a RGB orto and a Reflectance map from the radiometric data.
You would recommend merging the two projects after step 1, ok. I can do that, but after that how should i set the parameters (Image properties editor)(processing opotions)(Index calculator)(Radiometric processing and calibration)
Should I select both images types from the image properties editor? and process step 2 and 3 with the reflectance map on (grayscale=grayscale)?
If any of you that were able of producing a thermal orthophoto is able of sharing it to check results. unfortunately i was not able of processing step 3. Did any of you found any problem of creating a reflectance map and the RGB? Do they overlap?
When running step 3 you will have reflectance generated for both projects RGB and thermal. But since you are interested in temperature you should extract the indices only from the grayscale band.
Could you share with me the quality report, log file and p4d file so I could take a look? It may be that you have selected by default an index that cannot be generated due to bands that you have available.
This week we had some problems with the operating system so i dont have with me the files yet, but i will try to share you you once i have them. Can you explain to me the processing options on step 3 and image properties editor once i have both project merged? That way i can confirm my workflow. Any way i will share the log files and the project with you in the next few days.
Quick question as it pertains to the pix4d process for extracting the 4000x3000 JPEG and the 640x512 TIF. It seems the R-JPEG is created differently based on what output the camera is in. As an example:
If your view is set to PIP or OPTICAL ONLY, the R-JPEG uses the optical image as the thumbnail and also contains the full 4000x3000 JPEG (optical) and the 640x512 TIF (thermal).
If your view is set to THERMAL ONLY, the R-JPEG uses the thermal image as the thumbnail and also contains the full 4000x3000 JPEG (optical) and the 640x512 TIF (thermmal).
You have the ability to change this output dynamically. What we are seeing is that when this changes within a dataset, your extraction tool will incorrectly extract the wrong image and place in the “converted” directory.
As an example…Duo Pro 13mm lens
pictures 1-100 the camera is set for THERMAL ONLY… your tool extracts properly the 4000x3000 JPEG and the 640x512(13mm) TIF
pictures 101-110 the camera is changed to OPTICAL ONLY… your tool now extracts the 640x512 optical thumbnail and 640x512 TIF, but it creates as an 8mm camera model. I am assuming because it now extracted the thumbnail version of the TIF, but the TIF size matches the size of the TIF’s added under the 13mm camera model.
Its our own dataset from a recent flight. The issue is with the R-JPEG extraction process well before selecting any options, camera models, processing templates, etc. Once you select a file or directory that has a flir Duo Pro r-jpeg in it, Pix4D launches a separate “extraction process” to split the optical and thermal images from the r-jpeg. Its in that process where I believe the error occurs when the output mode changes within the same dataset.
So I think I will wait until this preprocessing issue has been sorted out. It makes no sense to reproduce the same issue, I believe.
Let’s wait for Pix4D to reply to John’s most recent findings.
We have other datasets where we didnt change the output during the flight and left it as “thermal” and we had no issues.
An additional test of creating a new project and selecting only those images where “optical” was selected produced the same results which is somewhat confusing to me. I was expecting when only selecting those images the exporter would have exported correctly but it still exported 640x512 optical images and not the 4000x3000 images.
This could be a Flir issue as with Flir tools, even though both IR and Optical are there, the optical is only 640x512 when exported, but the file size is almost 3MB as if the full image is there.
I plan to call Flir tomorrow and see if they have any info on this from other users.
My main intention is to process one or two FLIR projects as soon as possible, to learn the basic mechanisms, lots of thing discussed in this thread.
Once I get my own FLIR Duo Pro and the gimbal, I will go and capture my own data, of course. Well prepared beforehand, I would then be capable of producing results without too much support, I hope.
@John: Do you think there is a dataset available allowing to do so?
It looks like there are a lot of datasets, but based on a lack of documentation from Flir and Pix4D engineers not having one it seems the ability to produce a product is hit or miss.
From a thermal standpoint it seems pretty solid just like previous Flir cameras (Tau2)
However, flir has not published the sensor they are using for the optical portion of the Duo Pro so until you have that, or someone takes the time to calibrate it manually, I don’ see much luck with the optical portion.
These cookies are necessary for the website to function and cannot be switched off in our systems.
They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences,
logging in, or filling in forms. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site.
They help us to know which pages are the most and least popular and see how visitors move around the site.
All information these cookies collect is aggregated and therefore anonymous.
If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partner (Google).
They may be used by Google to build a profile of your interests and show you relevant adverts on other sites.
They do not directly store personal information but are based on uniquely identifying your browser and internet device.
If you do not allow these cookies, you will experience less targeted advertising.