[gdal-dev] Problem with garbage bytes of data after EOI marker in single band JPEG

[Ethan Alpert]

I have a very old GDAL based tool I wrote that creates JPEG thumbnails
for GeoTiff's. Since the GeoTiff's can be any size and I used a perl
script to compute the aspect ratio so I can center a reduced size image
in a square thumbnail.

 

I'm looking for any suggestions as to how I can look into the problem
which is described below.

 

 

 

This has been running for years. Recently a customer who receives these
started scanning the JPG's for security threats. Turns out that the
JPG's I've been writing have garbage data after the JPEG EOI marker.

 

Since our production system has a very old version I upgraded GDAL to
1.8.1 and have observed the same problem. Turns out it appears to be VRT
related and only happens with single band (black/white imagery).

 

If I use gdal_tranlsate to just translate the image to JPEG I get a
properly placed EOI (d9ff):

 

[ealpert at sbsenoklgmt07] PACK $  gdal_translate -of JPEG
1020010016BB5500.tif 1020010016BB5500_new.jpg

Input file size is 1356, 7444

0...10...20...30...40...50...60...70...80...90...100 - done.

ealpert at sbsenoklgmt07] PACK $ od -t x2 1020010016BB5500_new.jpg | tail

10610460 288a 8aa2 a228 288a 8aa2 a228 288a 8aa2

10610500 a228 288a 8aa2 a228 288a 8aa2 a228 288a

10610520 8aa2 a228 288a 8aa2 a228 288a 8aa2 a228

10610540 288a 8aa2 a228 288a 8aa2 a228 288a 8aa2

10610560 a228 288a 8aa2 a228 288a 8aa2 a228 288a

10610600 8aa2 a228 288a 8aa2 a228 288a 8aa2 a228

10610620 288a 8aa2 a228 288a 8aa2 a228 288a 8aa2

10610640 a228 288a 8aa2 a228 288a 8aa2 a228 2b8a

10610660 d9ff

 

 

 

If I create a VRT to center the image then use gdal_translate to convert
I get the following error message and the JPEG has garbage at the end
but can still be viewed without any problems in all applications:

 

ERROR:

 

bit length overflow

code 3 bits 6->7


VRT: 

<VRTDataset rasterXSize="1024" rasterYSize="1024">

  <NoDataValue>255</NoDataValue>

  <VRTRasterBand dataType="Byte" band="1">

   <ColorInterp>Gray</ColorInterp>

    <NoDataValue>255</NoDataValue>

    <ComplexSource>

      <NODATA>0</NODATA>

      <SourceFilename
relativeToVRT="1">./1020010016BB5500.tif</SourceFilename>

      <SourceBand>1</SourceBand>

      <SrcRect xOff="0" yOff="0" xSize="1356" ySize="7444"/>

      <DstRect xOff="419" yOff="0" xSize="186" ySize="1024"/>

    </ComplexSource>

  </VRTRasterBand>

</VRTDataset>

 

[ealpert at sbsenoklgmt07] PACK $ gdal_translate -of JPEG test.vrt test.jpg

Input file size is 1024, 1024

0...10...20...30...40...50...60...70...80...90...100 - done.

 

bit length overflow

code 3 bits 6->7

[ealpert at sbsenoklgmt07] PACK $ od -t x2 test.jpg | tail

0231300 90bb 1db7 3ee6 d116 d6fe f50c a157 126c

0231320 ff32 6f98 fb44 9a7f 1f57 7db8 9f90 99ff

0231340 047e 65ce b9f3 fe78 cdcf 4137 e390 105f

0231360 bfaf f372 1fed bd27 a8fe 002b 6c9d bbff

0231400 163d 637d bfe7 b716 ebfe ff7a f6a6 97c3

0231420 fad2 fb37 16fa f160 b7fe ebab 2e5f f985

0231440 ef6f f9b1 b347 293b 1037 9fbe 416f 697b

0231460 b1fd 84ea 8b9b 690b 13ff 5707 07fc df17

0231500 ef84 087f 870e e51b 0127 0000

 

Note there is no EOI marker. 

 

 


This electronic communication and any attachments may contain confidential and proprietary 
information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee 
responsible for delivering this communication to the intended recipient, or if you have received 
this communication in error, please do not print, copy, retransmit, disseminate or 
otherwise use the information. Please indicate to the sender that you have received this 
communication in error, and delete the copy you received. DigitalGlobe reserves the 
right to monitor any electronic communication sent or received by its employees, agents 
or representatives.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120413/bbe19c33/attachment.html