Well, I made a start as a part of gdal-autotest2... https://github.com/schwehr/gdal-autotest2/blob/master/cpp/third_party/kakadu/coresys/common/kdu_arch_test.cc
On Sat, Feb 18, 2017 at 5:03 AM, Aaron Boxer <[email protected]> wrote: > ---------- Forwarded message ---------- > From: "Aaron Boxer" <[email protected]> > Date: Feb 18, 2017 8:03 AM > Subject: Re: [gdal-dev] GDAL unable to write 4-band RGBA jp2 file with > Kakadu 7.8 > To: "Kurt Schwehr" <[email protected]> > Cc: > > > > On Feb 18, 2017 7:26 AM, "Kurt Schwehr" <[email protected]> wrote: > > Jason, > > Turns out you are hitting a known bug in v7.8 that is fixed in v7.9. From > the kakadu v7.9 docs: > > h. Corrected a tiny, yet very significant bug introduced into the > handling of opacity channel descriptions in version 7.8. The > correction is in function `jp2_channels::set_opacity_mapping', where > the opacity channel's component index accidentally overwrote the > colour channel's component index. > > > Apparently Kakadu does no regression testing before a release 😁 > > > > It's pretty easy to backport the fix if you are currently stuck at 7.8. > It's just a change of a 0 to a 1. > > --- kakadu/v7_8/apps/jp2/jp2.cpp > +++ kakadu/v7_9/apps/jp2/jp2.cpp > @@ -5976,7 +5976,7 @@ > if (lut_idx < 0) > lut_idx = -1; // For consistency in comparisons later on. > j2_channels::j2_channel *cp = state->channels+colour_idx; > - cp->component_idx[0] = codestream_component; > + cp->component_idx[1] = codestream_component; /* Was a bug in version > 7.8 */ > cp->lut_idx[1] = lut_idx; > cp->codestream_idx[1] = codestream_idx; > cp->data_format[1] = data_format; > > The 0 can trigger an error that looks just like you are seeing: > > Error: GdalIO: 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. (code = 1) > > > > On Mon, Feb 13, 2017 at 9:28 PM, Kurt Schwehr <[email protected]> wrote: > >> 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()->GetDri >>> verByName("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.nabbl >>> e.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 >> > > > > -- > -- > http://schwehr.org > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > _______________________________________________ > 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
