Hi,
I think the pixel value change is caused by the characteristics of JPEG compression method and it cannot be avoided unfortunately.
Wikipedia > JPEG > JPEG compression
http://en.wikipedia.org/wiki/JPEG#JPEG_compression
"The compression method is usually lossy, meaning that some original image information is lost and cannot be restored, possibly affecting image quality."
I'm not sure why JPEG compression and BigTIFF don't work at the same time. Wait for the answer from other member.
Takashi
That makes complete sense but I had expected that the background was not changed.
Geotiff supports other compression methods - lzw, pack-bits etc.. Those are "lossless compression", will not change pixel values.
Can you use one of those as a workaround?
By doing a quick test the other compression methods generate slitt a quite large file.
Is there no possibility to:
- Read a MrSid file
- Clip the area of interest
- Write to geotiff with jpeg compression and still have the background in no data or full black or white?
Seems unlikely to me that something like that is not possible?
Hi Rob,
If the clipped area is contains only data values then it should not be a problem, but since you mention the nodata area this is not the case.
Unfortunatly with any type of compression the edge of the data values will be changed do to the nature of the compression.
A possible way to achieve this will be to clip the raster, create a mask for the area of data values and transform the pixel values of the nodata area, outside the mask to 255 or 0.
Hi,
When I send the image (after the actions I perform) to the inspector it seems exactly what I want:
- Values within the image
- Everything outside the border is nodata
But when writing a geotiff with JPEG compression there show up pixel values in the area that was before no data.
Itay, there is only no data outside the image and not within the clipped area.
It seems that I'm missing something here.
Hi Rob,
Are you setting the nodata values with the RasterBandNodataSetter?
yes:
- clipping
- RasterSelector
- RasterBandNodataSetter (value 0)
Result in inspector
Result in geotiff file
Hi,
compression artefacts is known problem with lossy compression algorightms such as jpg. What you're observing might be
ringing artifacts.
You will probably either have to switch to a non-lossy compression format or look at some
solutions to minimize / remove the artifacts in the nodata-section.
It could be interesting to see if your rasters improve by using the JPEG 2000 writer, it this is supported by your client software.
David
Hi Rob,
Secondly, why is it not possible to use jpeg compression and the BigTIFF option at the same time in the writer?
When compression is used, it is not possible in advance to known the final size of the file (what happens when choosing BigTiff)
Itay
Hi,
Thanks for the help. Got also confirmation from FME support:
1. JPEG compression is lossy - which means that it changes the values of the pixels during the compression process. For this reason JPEG compressed images (as well as most lossy compressions) do not support NoData.
2. There doesn't seem to be any incompatibility between JPEG compression and BigTIFF, so I have created a problem report for our development team (PR48078) to fix the writer failure. I will notify you as soon as the problem is fixed.
Regards
Hi @rvgeneug,
It should be possible to write jpeg compressed tiff without the edge scattering. If you check jpg compression on the tiff writer and a compression level of 0 you will still have jpeg compressed tiff AND have lossless compression, which should give pretty good compression. It's documented on the tiff writer:
https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/jpeg/jpeg.htm
