Is this normal for Pix4Dfields? Ortho is very weird and stitching also hasn’t been done properly. And does the software take the calibration panel pictures and DLS info into account? I shot these images with a RedEdge. In Pix4Dmapper or Pix4Dag I had to calibrate the images manually, using the reflectance panel pictures…
Hi Jan, thanks for reaching out to us on the community.
Pix4Dfields does not take into account the calibration panel pictures. The DLS will be taken into account in the future but not in the current version.
The reason for the misalignment is due to the angles of each image per band not lining up as expected. MicaSense are aware of this issue within Pix4Dfields and are releasing a firmware update for the camera. You can find more information about this here: https://support.micasense.comhttps://support.pix4d.com/hc/en-us/articles/360005428953-Updating-RedEdge-for-Pix4Dfields
Once you have updated the firmware any new images captured will have the correct alignment and should work fine in Pix4Dfields.
If you would like to use the existing data set within Pix4Dfields you will need to manually update the EXIF data with the correct rig relatives on every image in the data set.
Best wishes, Sam
Thanks Sam, for explaining. However… if I understand correctly… even after the firmware update, will the calibration panel pictures still NOT be taken into account? There’s a difference between those panel pictures and the DLS data of course. In other words… will the calibration panel become obsolete all of a sudden?
I would really like an explanation regarding this matter. I contacted Micasense and they said it is still highly recommended to take a picture of the calibration panel and use it in Pix4Dmapper (you can’t even process multispectral images without it by the way). But they also said that Pix4Dfields doesn’t support this (yet). How can the data be accurately calibrated then, without using the calibration picture and even DLS info?
Hi Jan,
Correct, the calibration panel images are not used by Pix4Dfields when processing to produce the orthomosaic. This is because Pix4Dfields does not do absolute calibrations but instead relative. There is a trade-off between absolute reflectance vs. faster processing with relative reflectance.
Absolute reflectance is research grade analysis whereas relative reflectance serves as an industry grade result for the agricultural community due to the rapid results - something which can be essential for real-time in field analysis requiring other actions outside of the software. Furthermore, Pix4Dfields is designed to be part of this wider workflow, for example producing index maps. NDVI being Normalized Difference Vegetation Index and means you do not need absolute reflectance.
It is possible we will offer use of calibration panels within Pix4Dfields but this would be at a compromise of the speed benefits which many users enjoy producing images still of value to their needs.
One extra point to note, the new Sequoia Plus is calibrated in the factory to absolute reflectance without a calibration target. Whilst I would not wish to hypothesize on whether this is an industry wide move away from calibration targets it allows for rapid image processing within Pix4Dfields whilst maintaining the highest possible quality results.
Regards, Sam
Hi Jan,
Further to my previous message, I should make clear note that the radiometric correction module will be implemented shortly on Pix4Dfields. Pix4Dfields includes a radiometric correction module that corrects for exposure, vignetting, etc. Pix4Dmapper offers a more complex radiometric correction module; this module will be included in Pix4Dfields in the near future. At that point Pix4Dmapper and Pix4Dfields will generate equally radiometrically accurate results.
You might be interested to learn more about how Pix4Dfields works with MicaSense RedEdge camera data. We are hosting a webinar Tuesday 10 July between 17:00-19:00 Central European Summer Time (CEST).
To register: https://register.gotowebinar.com/register/2594277186464873730?source=Pix4D
Thanks for that info and sorry for my late response. I updated my RedEdge as per the instructions and did some flights already. Processing in Pix4Dfields however still isn’t working properly. Take a look at this screenshot… this is after 20 minutes of waiting… only 14% done. It’s just a small dataset with 160 captures (800 photo’s). Processing this set in Pix4Dmapper only took 20 minutes…
Update: after one hour of importing images it still hadn’t reached even 50%, so I cancelled it…
Hi Jan,
Thanks for sharing the issue on the community and attaching the screenshot. We discovered that after the firmware update that a line in the algorithm was reading focal length in pixels instead of millimeters. We have extensively tested this and happy to say the issue has been resolved. An update for this, along with lots of extra new features will be available in Pix4Dfields 1.1. this week.
Once the update is available if you are still unable to process your data set please let us know.
Regards, Sam
Thanks Sam. So, will the trial version be extended then as well? Since I first had to wait for the RedEdge firmware update and now for the new app version. I haven’t been able to view anything yet properly so far 
Hi Jan,
Our team will contact you personally via a support ticket so we can look at the license and address the issue in the best possible way so you are ensured a good trial experience. We look forward to you seeing good results from your MicaSense camera using Pix4Dfields and being able to share your thoughts with the community 
Regards, Sam
Thanks a lot! E-mail received and already got to it with the set I tried to process 2 days ago. Went super fast and looks much better than before the RedEdge firmware update. However… there’s still something a bit off… and I mean the colour of the dirt road next to the canal, in the orthomosaic. Pink instead of tan…
Hi Jan,
Thanks for posting a photo and positive review of the processing speed. The pink hue you are getting is something we have seen very rarely with data sets. I had only seen it on the edge of orthomosaics which is likely due to the color blending algorithm which will not produce the best results on the edges of an orthomosaic because it relies on stitching multiple images together which will be less available here. This is why we would always advise flights having an overlap / buffer area around the area of interest.
I’d like to investigate further the reason behind the results you are getting, whether the color blending is off due to the size of area photographed or if it is misrepresenting the dirt track as you suggest. If you are able to send over some sample images this would help. I’ll send you details on our support ticket where to send these images.
Regards, Sam
Thanks Sam. Doesn’t seem to be an “edge” related issue to me. The area of interest was the canal itself by the way; the water plants more specifically. My reasoning was that if the dirt roads don’t have the correct colour, then maybe there’s something wrong with other colours as well. Standing by for the location where I can send some sample images to
Hi Jan,
Thank you for sending over the images, I have looked at the situation further with our development team and have an update.
The current radiometric correction is looking at the largest area assumed to be the “field” to adjust color balancing. Due to this the pink from the original images is more visible than it would be on an orthomosaic of a field for example. Once the full radiometric correction module has been implemented in a future release then the canal should be processed correctly in this scenario. I’d welcome your feedback once this has been implemented.
Regards, Sam
Sure thing! Just gimme a shout when the new release is available for download