#5634 closed enhancement (fixed)
OpenJpeg2: implement MCT creation option for lossless YCC transform
Reported by: | shot2 | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | openjpeg, jpeg2000, ycbcr |
Cc: |
Description
The OpenJpeg2000 v2 library/encoder provides a useful option that greatly enhances compressibility of RGB data, in the form of the MCT (Multi Component Transform) parameter: when set to 1 it enforces a RGB-to-YCC transform step prior to encoding.
This optional step seems the default for current Kakadu, Erdas and OpenJpeg encoders. Only the GDAL JP2OpenJPEG does not allow it, resulting in suboptimal compression. In a test a 283 MB RGB aerial photo compressed losslessly to 1.6:1 without MCT and to 2.4:1 with it (using OpenJpeg v2.0.1). The same applies to lossy compression, that is: much better visual quality for a similar rate, when using MCT.
The MCT step is basically lossless, does not involve subsampling, and seems supported in most GIS software. This is not the case with the YCBCR420 creation option of the current GDAL JP2OpenJPEG plugin, which is lossy and produces files that prove problematic with some software relying on MrSid/Erdas SDKs.
Allowing a GDAL creation option (e.g. -co YCC=YES) would bring the JP2OpenJPEG plugin up-to-par with the many other J2K converters allowing RGB-to-YCC transform for RGB data, either automagically or optionally.
Change History (6)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Implemented suggestion and actually turned the option ON. I've confirmed that Kakadu kdu_compress enable MCT by default. But OpenJPEG opj_compress does not.
trunk r27630 "OpenJPEG: add YCC creation option to do RGB->YCC MCT, and turn it ON by default (#5634)"
@jratike80: PHOTOMETRIC=YCBCR does in addition Cb and Cr subsampling, which is more or less equivalent to OpenJPEG YCBCR420 option.
comment:3 by , 10 years ago
@jratike80: but I've not thought a lot about the naming. So open to suggestions.
comment:4 by , 10 years ago
Thanks. BTW I just checked again: OpenJpeg 2.1/win32 converts RGB to YCC by default. It is further revealed by checking jp2 properties with e.g. kdu_show, or hew dumps from kdu_jp2info.
-mct <0|1|2> Explicitely specifies if a Multiple Component Transform has to be used. 0: no MCT ; 1: RGB->YCC conversion ; 2: custom MCT. If custom MCT, "-m" option has to be used (see hereunder). By default, RGB->YCC conversion is used if there are 3 components or more, no conversion otherwise.
As for the option name, I fear too that photometric=ycbcr is too reminiscent of the usual jpeg-like YCbCr4:x:y lossy subsampling. YCC=yes is decent enough imho especially if turned on by default, only knowledgeable users would consider disabling it. Perhaps should it be made clear that the transform occurs internally and without visual degradation (I'd say without quality loss but I'm wary of using 'losslessly' for the term is already used for the compression).
Off-topic: the frmt_jp2openjpeg.html is in part wrong: Reversible=Yes does not imply lossless compression. This parameter alone is not enough to trigger lossless compression; it just enforces a 5x3 integer-only filter that may allow lossless only if prevented from discarding any information (with e.g. Quality=100 in GDAL, or -r - in opj_compress). You'll get tremendous visual degradation with -co QUALITY=1 -co REVERSIBLE=YES. Similarly -co QUALITY=100 -co REVERSIBLE=NO can't be lossless. And -co QUALITY=100 -co REVERSIBLE=YES -co YCBCR420=TRUE can't be lossless either. So the doc should be disambiguated along these lines:
REVERSIBLE=YES/NO : YES enables lossless compression if QUALITY=100. Defaults to NO. ... YCBCR420=YES/NO : (GDAL >= 1.11) YES if RGB must be resampled to lossy YCbCr 4:2:0. Defaults to NO.
Perhaps add some Creation Issues paragraph detailing how to get perfect lossless, with REVERSIBLE=YES, QUALITY=100, (optionally) YCC=YES, and (necessarily) YCBCR420=FALSE.
comment:5 by , 10 years ago
Kakadu is using Cycc=yes/no and Creversible=yes/no. If GDAL uses ycc=yes/no and reversible=yes/no it would mean two software using same names for the same meaning which would make it almost a de facto standard and that would be fine.
Yes/no should be used in all places so not YCBCR420=FALSE.
How about using PHOTOMETRIC=YCBCR like the GeoTIFF driver http://www.gdal.org/frmt_gtiff.html? It is the same thing, isn't?