[gdal-dev] Fwd: Re: GDAL unable to write 4-band RGBA jp2 file with Kakadu 7.8

Aaron Boxer boxerab at gmail.com
Mon Feb 20 11:20:57 PST 2017


:):)

On Mon, Feb 20, 2017 at 1:56 PM, Kurt Schwehr <schwehr at gmail.com> wrote:

> Only 370K more LOC left to cover with proper library level unittests.
>
> On Mon, Feb 20, 2017 at 10:01 AM, Aaron Boxer <boxerab at gmail.com> wrote:
>
>>
>>
>> On Sat, Feb 18, 2017 at 8:14 AM, Kurt Schwehr <schwehr at gmail.com> 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 <boxerab at gmail.com> wrote:
>>>
>>>> ---------- Forwarded message ----------
>>>> From: "Aaron Boxer" <boxerab at gmail.com>
>>>> 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" <schwehr at gmail.com>
>>>> Cc:
>>>>
>>>>
>>>>
>>>> On Feb 18, 2017 7:26 AM, "Kurt Schwehr" <schwehr at gmail.com> 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 <schwehr at gmail.com>
>>>> 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 <jason.liu at spookfish.com>
>>>>> 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
>>>>>> gdal-dev at lists.osgeo.org
>>>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> http://schwehr.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> http://schwehr.org
>>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> http://schwehr.org
>>>
>>
>>
>
>
> --
> --
> http://schwehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170220/8aff0351/attachment-0001.html>


More information about the gdal-dev mailing list