:):) On Mon, Feb 20, 2017 at 1:56 PM, Kurt Schwehr <[email protected]> wrote:
> Only 370K more LOC left to cover with proper library level unittests. > > On Mon, Feb 20, 2017 at 10:01 AM, Aaron Boxer <[email protected]> wrote: > >> >> >> On Sat, Feb 18, 2017 at 8:14 AM, Kurt Schwehr <[email protected]> wrote: >> >>> Well, I made a start as a part of gdal-autotest2... >>> >> >>> https://github.com/schwehr/gdal-autotest2/blob/master/cpp/th >>> ird_party/kakadu/coresys/common/kdu_arch_test.cc >>> >> >> >> That is a good start. >> >> >>> >>> >>> 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 >>> >> >> > > > -- > -- > http://schwehr.org >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
