<div dir="ltr">Only 370K more LOC left to cover with proper library level unittests.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 20, 2017 at 10:01 AM, Aaron Boxer <span dir="ltr"><<a href="mailto:boxerab@gmail.com" target="_blank">boxerab@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Feb 18, 2017 at 8:14 AM, Kurt Schwehr <span dir="ltr"><<a href="mailto:schwehr@gmail.com" target="_blank">schwehr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Well, I made a start as a part of gdal-autotest2...</div></blockquote><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><a href="https://github.com/schwehr/gdal-autotest2/blob/master/cpp/third_party/kakadu/coresys/common/kdu_arch_test.cc" target="_blank">https://github.com/schwehr/gda<wbr>l-autotest2/blob/master/cpp/<wbr>third_party/kakadu/coresys/<wbr>common/kdu_arch_test.cc</a></div></div></blockquote></span><div><br><br>That is a good start. <br> </div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div></div><div class="m_-8106335269000256801gmail-HOEnZb"><div class="m_-8106335269000256801gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 18, 2017 at 5:03 AM, Aaron Boxer <span dir="ltr"><<a href="mailto:boxerab@gmail.com" target="_blank">boxerab@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_-8106335269000256801gmail-m_-8909021664025204190HOEnZb"><div class="m_-8106335269000256801gmail-m_-8909021664025204190h5"><div dir="auto"></div><div class="gmail_quote">---------- Forwarded message ----------<br>From: "Aaron Boxer" <<a href="mailto:boxerab@gmail.com" target="_blank">boxerab@gmail.com</a>><br>Date: Feb 18, 2017 8:03 AM<br>Subject: Re: [gdal-dev] GDAL unable to write 4-band RGBA jp2 file with Kakadu 7.8<br>To: "Kurt Schwehr" <<a href="mailto:schwehr@gmail.com" target="_blank">schwehr@gmail.com</a>><br>Cc: <br><br type="attribution"><div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Feb 18, 2017 7:26 AM, "Kurt Schwehr" <<a href="mailto:schwehr@gmail.com" target="_blank">schwehr@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_-8106335269000256801gmail-m_-8909021664025204190m_-1937482727096931685m_6504427511881436786quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Jason,<div><br></div><div>Turns out you are hitting a known bug in v7.8 that is fixed in v7.9. From the kakadu v7.9 docs:</div><div><br></div><div><div>h. Corrected a tiny, yet very significant bug introduced into the</div><div> handling of opacity channel descriptions in version 7.8. The</div><div> correction is in function `jp2_channels::set_opacity_map<wbr>ping', where</div><div> the opacity channel's component index accidentally overwrote the</div><div> colour channel's component index.</div><div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Apparently Kakadu does no regression testing before a release 😁</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-8106335269000256801gmail-m_-8909021664025204190m_-1937482727096931685m_6504427511881436786quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>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.</div><div><br></div><div>--- kakadu/v7_8/apps/jp2/jp2.cpp</div><div>+++ kakadu/v7_9/apps/jp2/jp2.cpp</div><div>@@ -5976,7 +5976,7 @@</div><div> if (lut_idx < 0)</div><div> lut_idx = -1; // For consistency in comparisons later on.</div><div> j2_channels::j2_channel *cp = state->channels+colour_idx;</div><div>- cp->component_idx[0] = codestream_component;</div><div>+ cp->component_idx[1] = codestream_component; /* Was a bug in version 7.8 */</div><div> cp->lut_idx[1] = lut_idx;</div><div> cp->codestream_idx[1] = codestream_idx;</div><div> cp->data_format[1] = data_format;</div><div><br></div><div>The 0 can trigger an error that looks just like you are seeing:</div></div><div><br></div><div>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)<br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 9:28 PM, Kurt Schwehr <span dir="ltr"><<a href="mailto:schwehr@gmail.com" target="_blank">schwehr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Jason,<div><br></div><div>I've seen the same thing with an alpha channel. I'm not sure what's up. Using just RGB was successful.<div><br></div><div>On 7.3, I'm also seeing problems when using more than the main thread on linux. </div><div><br></div><div>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.</div><div><br></div><div>So I clearly have more investigating to do.<br></div><div><br></div><div>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.</div></div><div><br></div><div>And I've yet to see what, if any, discussion is happening in the yahoo group.</div><div><br></div><div>-kurt</div></div><div class="gmail_extra"><div><div class="m_-8106335269000256801gmail-m_-8909021664025204190m_-1937482727096931685m_6504427511881436786m_-9097045772684997292h5"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 8:14 PM, jason.liu <span dir="ltr"><<a href="mailto:jason.liu@spookfish.com" target="_blank">jason.liu@spookfish.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi gdal-dev,<br>
<br>
I am having trouble using GDAL to write 4-band RGBA jp2 file with Kakadu<br>
7.8. The following minimal code<br>
<br>
<br>
GDALAllRegister();<br>
<br>
GDALDataset* srcDataset =<br>
(GDALDataset*)GDALOpen("/home/<wbr>jason.liu/00000783.tif", GA_ReadOnly);<br>
char **papszOptions = NULL;<br>
papszOptions = CSLSetNameValue( papszOptions, "QUALITY", "20" );<br>
<br>
GDALDriver *driver = GetGDALDriverManager()->GetDri<wbr>verByName("JP2KAK");<br>
GDALDataset* destDataset =<br>
driver->CreateCopy("/home/jaso<wbr>n.liu/00000783.jp2",<br>
srcDataset,<br>
FALSE,<br>
papszOptions,<br>
NULL,<br>
NULL);<br>
<br>
if( destDataset != NULL ) {<br>
GDALClose( (GDALDatasetH) destDataset );<br>
}<br>
GDALClose( (GDALDatasetH) srcDataset );<br>
CSLDestroy(papszOptions);<br>
<br>
<br>
crashes Kakadu 7.8 with the following message in stderr:<br>
<br>
ERROR 1: Error in Kakadu File Format Support:<br>
Attempting to create a Component Mapping (cmap) box, one of whose channels<br>
refers to a non-existent image component or palette lookup table.<br>
terminate called after throwing an instance of<br>
'kdu_cpl_error_message::JP2KAK<wbr>Exception'<br>
<br>
<br>
where /home/jason.liu/00000783.tif is a 4-band 16-bit RGBA tif.<br>
<br>
<br>
I have also done the following tests and noted the results:<br>
<br>
3-band 8-bit RGB tif OK<br>
3-band 16-bit RGB tif OK<br>
4-band 8-bit RGBA tif error as above<br>
4-band 16-bit RGBA tif error as above<br>
<br>
<br>
Am I doing anything wrong here?<br>
<br>
By the way, I am quite certain Kakadu 7.8 supports 4-band RGBA as I can use<br>
their example kdu_compress to produce 4-band RGBA jp2 images. So this looks<br>
to be a problem with GDAL, or the way I am invoking it.<br>
<br>
<br>
Any insights will be greatly appreciated.<br>
<br>
Kind Regards<br>
Jason<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/GDAL-unable-to-write-4-band-RGBA-jp2-file-with-Kakadu-7-8-tp5307801.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.nabbl<wbr>e.com/GDAL-unable-to-write-4-b<wbr>and-RGBA-jp2-file-with-Kakadu-<wbr>7-8-tp5307801.html</a><br>
Sent from the GDAL - Dev mailing list archive at Nabble.com.<br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/gdal-dev</a></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_-8106335269000256801gmail-m_-8909021664025204190m_-1937482727096931685m_6504427511881436786m_-9097045772684997292HOEnZb"><font color="#888888">-- <br><font color="#888888"><div class="m_-8106335269000256801gmail-m_-8909021664025204190m_-1937482727096931685m_6504427511881436786m_-9097045772684997292m_-6358560168769488007gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</font></font></span></div><font color="#888888">
</font></blockquote></div><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-8106335269000256801gmail-m_-8909021664025204190m_-1937482727096931685m_6504427511881436786m_-9097045772684997292gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</font></div>
<br>______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/gdal-dev</a><br></blockquote></div><br></div></div></div>
</div>
</div></div><br>______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/gdal-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-8106335269000256801gmail-m_-8909021664025204190gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--<div><a href="http://schwehr.org" target="_blank">http://schwehr.org</a></div></div>
</div>