<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 22, 2013 at 10:21 PM, Tomaka, Jacek <span dir="ltr"><<a href="mailto:Jacek.Tomaka@intergraph.com" target="_blank">Jacek.Tomaka@intergraph.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
Recently I tried to compile GDAL 1.10 with libjpeg + IPP 8.0.<br>
I compiled IPP powered jpeglib 6b (taken from old IPP 7.0 samples, as IPP 8.0 examples contain version 8b).<br>
I run into several issues, after some investigation it turned out that different issues appear depending on the configuration of libjpeg library.<br>
1. When libjpeg.IPP is compiled with IPP_SUSPENS defined then JPEG decoding does not work. i.e. gdal_translate from jpeg to tiff produces strange image.<br>
JPEG encoded TIFFs were all right in this configuration.<br>
2. When libjpeg.IPP is compiled with IPP_SUSPENS not defined then JPEG encoded TIFFs decoding produces warning "Warning 1: JPEGLib:Premature end of JPEG file".<br>
JPEG decoding is fine in this configuration. Strangely enough, the decoded images (JPEG encoded TIFFS) seem to be correct in this case, despite the warning.<br>
<br>
Note, I confirmed that IPPJ_HUFF is defined during jpeg, and gtiff formats compilation. If I don't define it I got the same warning but in greater abundance.<br>
<br>
Is there something obvious for You that I am missing? I read <a href="http://trac.osgeo.org/gdal/wiki/JpegIPP" target="_blank">http://trac.osgeo.org/gdal/wiki/JpegIPP</a> but it turns a blind eye on libjpeg configuration.<br>
</blockquote><div><br></div><div>Jacek,<br><br>I don't recall any details about IPP_SUSPENS or IPPJ_HUFF. I'm not sure what is causing your problem and I haven't tried building with IPP for several years now.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also tried to compile GDAL with jpeglib 8b but with no luck. Is this version supported?<br></blockquote><div><br></div><div>My understanding is that modern GDAL's should work with libjpeg 8. If this isn't working, filing a ticket could be helpful.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is GDAL taking advantage of suspended I/O?<br></blockquote><div><br></div><div>Not that I'm aware of.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another issue is that when IPP is doing IDCT when decoding jpegs, autotests fail as it gives different checksums.<br>
Should I open a ticket for it?<br></blockquote><div><br></div><div>No need to file a ticket about this. I would expect the jpeg checksum based tests to fail.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Has anyone had success making jpegs and tiffs compiled against jpeglib + IPP work?<br clear="all"></blockquote></div><br></div><div class="gmail_extra">As I mention, it has been several years since I last did this, though it<br>
did work then with the notes in the JpegIPP trac topic.<br><br>Best regards,<br></div><div class="gmail_extra">-- <br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush | Geospatial Software Developer<br>
</div></div>