Hi Jason, I've seen the same thing with an alpha channel. I'm not sure what's up. Using just RGB was successful.
On 7.3, I'm also seeing problems when using more than the main thread on linux. With 7.3, I just noticed today that kdu_get_num_processors() only returns 0 on linux as kdu_arch.cpp is missing #include <unistd.h> so _SC_NPROCESSORS_ONLN and _SC_NPROCESSORS_CONF are undefined. When I enabled _SC_NPROCESSORS_ONLN, I got kdu_get_num_processors() returning 74 on what I thought was a 6 core (aka 12 hyperthread) box. If I change the fall through from 0 to 2, I get all sorts of trouble from internal kakadu assertions and TSAN failures. So I clearly have more investigating to do. I've yet to pass along any of what I've found to Taubman and I haven't yet pushed any of my new tests to github, but I hope to do both soon. And I've yet to see what, if any, discussion is happening in the yahoo group. -kurt On Mon, Feb 13, 2017 at 8:14 PM, jason.liu <[email protected]> wrote: > Hi gdal-dev, > > I am having trouble using GDAL to write 4-band RGBA jp2 file with Kakadu > 7.8. The following minimal code > > > GDALAllRegister(); > > GDALDataset* srcDataset = > (GDALDataset*)GDALOpen("/home/jason.liu/00000783.tif", GA_ReadOnly); > char **papszOptions = NULL; > papszOptions = CSLSetNameValue( papszOptions, "QUALITY", "20" ); > > GDALDriver *driver = GetGDALDriverManager()-> > GetDriverByName("JP2KAK"); > GDALDataset* destDataset = > driver->CreateCopy("/home/jason.liu/00000783.jp2", > srcDataset, > FALSE, > papszOptions, > NULL, > NULL); > > if( destDataset != NULL ) { > GDALClose( (GDALDatasetH) destDataset ); > } > GDALClose( (GDALDatasetH) srcDataset ); > CSLDestroy(papszOptions); > > > crashes Kakadu 7.8 with the following message in stderr: > > ERROR 1: Error in Kakadu File Format Support: > Attempting to create a Component Mapping (cmap) box, one of whose channels > refers to a non-existent image component or palette lookup table. > terminate called after throwing an instance of > 'kdu_cpl_error_message::JP2KAKException' > > > where /home/jason.liu/00000783.tif is a 4-band 16-bit RGBA tif. > > > I have also done the following tests and noted the results: > > 3-band 8-bit RGB tif OK > 3-band 16-bit RGB tif OK > 4-band 8-bit RGBA tif error as above > 4-band 16-bit RGBA tif error as above > > > Am I doing anything wrong here? > > By the way, I am quite certain Kakadu 7.8 supports 4-band RGBA as I can use > their example kdu_compress to produce 4-band RGBA jp2 images. So this looks > to be a problem with GDAL, or the way I am invoking it. > > > Any insights will be greatly appreciated. > > Kind Regards > Jason > > > > > -- > View this message in context: http://osgeo-org.1560.x6. > nabble.com/GDAL-unable-to-write-4-band-RGBA-jp2-file- > with-Kakadu-7-8-tp5307801.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
