Any way to disable internal compression entirely?

[luminus]

I have been able to identify artifacts in the final ortho products that are due to the use of jpeg compression internally on the generated mosaics. The input frame data is losslessly compressed, and the exported tif files have lossless compression as well, but the internal tif tiles (by looking through the Photoscan project diretory) use jpeg compression.

In 1.3.5, the Project Compression slider can be set to zero, but it doesn't remove the jpeg compression artifacts. In 1.4.x, the setting is entirely gone.

Is there any way to force Photoscan to not use jpeg compression internally?

This significantly negatively impacts the accuracy of resulting NDVI images. The jpeg blocking is very apparent.

[luminus]

Here is a more apparent example. This is a gray NDVI image as shown inside Photoscan. The top image shows what happens when you select a replacement image over the ortho. The underlying frames do not have the artifacts, but the ortho does.

[Alexey Pasumansky]

Hello luminus,

It doesn't look for me as compression artifacts. Can you provide the screenshot for the same area with Show Seamlines option turned on and also specify the blending mode used?

Even though for 8-bit RGB data PhotoScan applies internal JPEG compression, but it is performed with very high quality setting, so it doesn't seem to be possible to see the JPEG compression artifacts in such zoom level, moreover on the orthomosaic where multiple images are blended together.

[luminus]

I thought it might be a seam line as well, but there is only one seam line that runs vertical through that polygon. The blending mode is mosaic; would that be doing blending well away from the seam line?

Unfortunately I had to quickly redo this project a different way, so it would take me a bit to recreate to show the seam lines.

This was showing up because one of the multispectral channels had a very low signal (pixel values of ~20-30 of 255), and the other was very high.  The low signal channel was set as the primary channel had its brightness settings turned up to 400% in order to process. This showed up on 3 different processing runs of different areas, but using data from the same flight where one of the channels had low pixel values.

I did a test where we brought that specific channel up (histogram expanded it) on the images in the area, and the issue has gone away. That sort of correction however can't be used for NDVI though, as it would produce non-radiometric changes. Although the channel is dark, the signal is well above the noise.

Unless mosaic blending is creating a blocky area like that from two images (seems unlikely), I'm fairly positive we're looking at jpeg artifacts.

[Alexey Pasumansky]

Hello luminus,

The individually rectified images are stored in the same way, so if you do not see any artifacts when Assign Image option is used, it cannot suddenly appear on the orthomosaic.

You can try to disable the blending for the orthomosaic generation and see what happens.

If the problems persists, maybe you can share the subset of the images and the project where we can see the issue.

[luminus]

Appreciate the quick responses!

The ortho being shown in the last screen shot is the result of a raster transform between the dark channel and the brighter channel (NDVI specifically).

I think it is showing up only as a result of the NDVI formula which is making subtle changes between the two channels much more apparent.

Would the Assign Image option apply this same transform to the images being previewed?