JPG file loading - File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).

Sometimes when attempting to load images from .jpg files, some files will not load.  The following warning will display.

 

    File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).

 

If I load the offending file into Windows paint and resave it then it will load.  Ideas?

 

Thanks,

 

-Carl

 

CgPixmap class>>imageFromFile: aFileName
 "Answer a new image loaded from <aFileName>"

 | file readerClass reader image |

 (file := CfsFileDescriptor open: aFileName oflag: 0) isCfsError
  ifTrue: [
   (file := CfsFileDescriptor open: CgScreen bitmapPath first, aFileName oflag: 0) isCfsError
    ifTrue: [
     CgServer default warning: 'Could not open the selected file.'.
     ^nil]].
 readerClass :=
  CgImageFileFormat
   formatMatchingFileHandle: file
   atOffset: 0
   ifNone: [
    file close.
    CgServer default warning: 'File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).'.
    ^nil].
 image := (reader := readerClass new) loadFromFileHandle: file atOffset: 0.
 reader hasErrorOccurred
  ifTrue: [self error: 'Unable to load bitmap file: ', aFileName].
 file close.
 image isNil
   ifTrue: [
    file close.
    CgServer default warning: reader currentErrorString.
    ^nil].
 ^image

Thanks Lou.  That does seem to do the trick.  The guys at Instantiations should consider your change.  :-)

 

-Carl

On Friday, June 12, 2015 at 9:22:02 AM UTC-4, Louis LaBrunda wrote:

Hi Carl,

This sounds like a problem I think I reported but is not fixed yet.  I removed a line of code from a CgJPEGFileFormat class method #formatMatchesByteStream:.  I can't remember if this was a real fix or a circumvention.

Lou

formatMatchesByteStream: byteStream

"Answer true if the input specified by the CgByteStream

byteStream matches the receiver's format.

Answer false if the file does not match the receiver's format.

The input is read starting at the given 0-based offset.

NOTE - Always seek back to original position of the byteStream."

| soi appn originalPosition noMatch |

originalPosition := byteStream position.

noMatch := [byteStream lseek: originalPosition whence: SEEKSET. ^false].

(soi := CgJPEGStartOfImage fromStream: byteStream) verify

ifFalse: noMatch.

appn := CgJPEGAppn fromStream: byteStream.

" Removed by LL to fix test.

(appn verify and: [appn segmentMarker == APP0])

ifFalse: noMatch.

"

byteStream lseek: originalPosition whence: SEEKSET.

^true

On Thursday, June 11, 2015 at 3:13:32 PM UTC-4, Carl Gundel wrote:

Sometimes when attempting to load images from .jpg files, some files will not load.  The following warning will display.

 

    File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).

 

If I load the offending file into Windows paint and resave it then it will load.  Ideas?

 

Thanks,

 

-Carl

 

CgPixmap class>>imageFromFile: aFileName
 "Answer a new image loaded from <aFileName>"

 | file readerClass reader image |

 (file := CfsFileDescriptor open: aFileName oflag: 0) isCfsError
  ifTrue: [
   (file := CfsFileDescriptor open: CgScreen bitmapPath first, aFileName oflag: 0) isCfsError
    ifTrue: [
     CgServer default warning: 'Could not open the selected file.'.
     ^nil]].
 readerClass :=
  CgImageFileFormat
   formatMatchingFileHandle: file
   atOffset: 0
   ifNone: [
    file close.
    CgServer default warning: 'File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).'.
    ^nil].
 image := (reader := readerClass new) loadFromFileHandle: file atOffset: 0.
 reader hasErrorOccurred
  ifTrue: [self error: 'Unable to load bitmap file: ', aFileName].
 file close.
 image isNil
   ifTrue: [
    file close.
    CgServer default warning: reader currentErrorString.
    ^nil].
 ^image

On Friday, June 12, 2015 at 6:22:02 AM UTC-7, Louis LaBrunda wrote:

Hi Carl,

This sounds like a problem I think I reported but is not fixed yet.  I removed a line of code from a CgJPEGFileFormat class method #formatMatchesByteStream:.  I can't remember if this was a real fix or a circumvention.

Lou

formatMatchesByteStream: byteStream

"Answer true if the input specified by the CgByteStream

byteStream matches the receiver's format.

Answer false if the file does not match the receiver's format.

The input is read starting at the given 0-based offset.

NOTE - Always seek back to original position of the byteStream."

| soi appn originalPosition noMatch |

originalPosition := byteStream position.

noMatch := [byteStream lseek: originalPosition whence: SEEKSET. ^false].

(soi := CgJPEGStartOfImage fromStream: byteStream) verify

ifFalse: noMatch.

appn := CgJPEGAppn fromStream: byteStream.

" Removed by LL to fix test.

(appn verify and: [appn segmentMarker == APP0])

ifFalse: noMatch.

"

Per this article in Wikepedia (<a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format):
"For a valid JFIF file, the APP0 marker segment is mandatory right after the SOI marker."

The actual JPEG article (<a href="https://en.wikipedia.org/wiki/JPEG" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;">https://en.wikipedia.org/wiki/JPEG) says:
"The first of these, released in 1992, was <a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" title="JPEG File Interchange Format" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">JPEG File Interchange Format (or JFIF), followed in recent years by <a href="https://en.wikipedia.org/wiki/Exchangeable_image_file_format" title="Exchangeable image file format" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;">Exchangeable image file format (Exif) and <a href="https://en.wikipedia.org/wiki/International_Color_Consortium" title="International Color Consortium" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;">ICC <a href="https://en.wikipedia.org/wiki/ICC_Profile" title="ICC Profile" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;">color profiles. Both of these formats use the actual JIF byte layout, consisting of different markers, but in addition employ one of the JIF standard's extension points, namely the application markers: JFIF use APP0, while Exif use APP1."

I read all that as saying that you can have an EXIF file which is not JFIF compliant and you can have a JPEG image in a file without the file being JFIF formatted.

Even so, it sounds like an unusual file. Where did you get it?

byteStream lseek: originalPosition whence: SEEKSET.

^true

On Thursday, June 11, 2015 at 3:13:32 PM UTC-4, Carl Gundel wrote:

Sometimes when attempting to load images from .jpg files, some files will not load.  The following warning will display.

 

    File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).

 

If I load the offending file into Windows paint and resave it then it will load.  Ideas?

 

Thanks,

 

-Carl

 

CgPixmap class>>imageFromFile: aFileName
 "Answer a new image loaded from <aFileName>"

 | file readerClass reader image |

 (file := CfsFileDescriptor open: aFileName oflag: 0) isCfsError
  ifTrue: [
   (file := CfsFileDescriptor open: CgScreen bitmapPath first, aFileName oflag: 0) isCfsError
    ifTrue: [
     CgServer default warning: 'Could not open the selected file.'.
     ^nil]].
 readerClass :=
  CgImageFileFormat
   formatMatchingFileHandle: file
   atOffset: 0
   ifNone: [
    file close.
    CgServer default warning: 'File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).'.
    ^nil].
 image := (reader := readerClass new) loadFromFileHandle: file atOffset: 0.
 reader hasErrorOccurred
  ifTrue: [self error: 'Unable to load bitmap file: ', aFileName].
 file close.
 image isNil
   ifTrue: [
    file close.
    CgServer default warning: reader currentErrorString.
    ^nil].
 ^image

Hello,

Back in 2001, SWT (The Java port of Cg/Cw in VA) had a <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&amp;id=4780" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fbugs.eclipse.org%2Fbugs%2Fshow_bug.cgi%3Fformat%3Dmultiple%26id%3D4780\46sa\75D\46sntz\0751\46usg\75AFQjCNEjJ8zRVSdEXM6VbO5S8QEI6Gcu-A';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fbugs.eclipse.org%2Fbugs%2Fshow_bug.cgi%3Fformat%3Dmultiple%26id%3D4780\46sa\75D\46sntz\0751\46usg\75AFQjCNEjJ8zRVSdEXM6VbO5S8QEI6Gcu-A';return true;">bug reported on exactly this issue.  The result was, and I just confirmed in the source code, to remove the appn segment verification.  In their particular case, whatever created the image produced a unknown APPN byte (...opening in paint and resaving fixes that up).  However, I see for Exif that readers should be designed to skip over invalid APPN and COM.

All this to say...I think we will remove it.

--Seth

On Friday, June 12, 2015 at 6:50:45 PM UTC-4, Richard Sargent wrote:

On Friday, June 12, 2015 at 6:22:02 AM UTC-7, Louis LaBrunda wrote:

Hi Carl,

This sounds like a problem I think I reported but is not fixed yet.  I removed a line of code from a CgJPEGFileFormat class method #formatMatchesByteStream:.  I can't remember if this was a real fix or a circumvention.

Lou

formatMatchesByteStream: byteStream

"Answer true if the input specified by the CgByteStream

byteStream matches the receiver's format.

Answer false if the file does not match the receiver's format.

The input is read starting at the given 0-based offset.

NOTE - Always seek back to original position of the byteStream."

| soi appn originalPosition noMatch |

originalPosition := byteStream position.

noMatch := [byteStream lseek: originalPosition whence: SEEKSET. ^false].

(soi := CgJPEGStartOfImage fromStream: byteStream) verify

ifFalse: noMatch.

appn := CgJPEGAppn fromStream: byteStream.

" Removed by LL to fix test.

(appn verify and: [appn segmentMarker == APP0])

ifFalse: noMatch.

"

Per this article in Wikepedia (<a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format):
"For a valid JFIF file, the APP0 marker segment is mandatory right after the SOI marker."

The actual JPEG article (<a href="https://en.wikipedia.org/wiki/JPEG" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;">https://en.wikipedia.org/wiki/JPEG) says:
"The first of these, released in 1992, was <a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" title="JPEG File Interchange Format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">JPEG File Interchange Format (or JFIF), followed in recent years by <a href="https://en.wikipedia.org/wiki/Exchangeable_image_file_format" title="Exchangeable image file format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;">Exchangeable image file format (Exif) and <a href="https://en.wikipedia.org/wiki/International_Color_Consortium" title="International Color Consortium" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;">ICC <a href="https://en.wikipedia.org/wiki/ICC_Profile" title="ICC Profile" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;">color profiles. Both of these formats use the actual JIF byte layout, consisting of different markers, but in addition employ one of the JIF standard's extension points, namely the application markers: JFIF use APP0, while Exif use APP1."

I read all that as saying that you can have an EXIF file which is not JFIF compliant and you can have a JPEG image in a file without the file being JFIF formatted.

Even so, it sounds like an unusual file. Where did you get it?

byteStream lseek: originalPosition whence: SEEKSET.

^true

On Thursday, June 11, 2015 at 3:13:32 PM UTC-4, Carl Gundel wrote:

Sometimes when attempting to load images from .jpg files, some files will not load.  The following warning will display.

 

    File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).

 

If I load the offending file into Windows paint and resave it then it will load.  Ideas?

 

Thanks,

 

-Carl

 

CgPixmap class>>imageFromFile: aFileName
 "Answer a new image loaded from <aFileName>"

 | file readerClass reader image |

 (file := CfsFileDescriptor open: aFileName oflag: 0) isCfsError
  ifTrue: [
   (file := CfsFileDescriptor open: CgScreen bitmapPath first, aFileName oflag: 0) isCfsError
    ifTrue: [
     CgServer default warning: 'Could not open the selected file.'.
     ^nil]].
 readerClass :=
  CgImageFileFormat
   formatMatchingFileHandle: file
   atOffset: 0
   ifNone: [
    file close.
    CgServer default warning: 'File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).'.
    ^nil].
 image := (reader := readerClass new) loadFromFileHandle: file atOffset: 0.
 reader hasErrorOccurred
  ifTrue: [self error: 'Unable to load bitmap file: ', aFileName].
 file close.
 image isNil
   ifTrue: [
    file close.
    CgServer default warning: reader currentErrorString.
    ^nil].
 ^image

Opened Case 58094: Relax JPEG reader's assumption that APPN segment immediately follows SOI

On Saturday, June 13, 2015 at 3:36:50 PM UTC-4, Seth Berman wrote:

All,

I've done some more testing and looked specifically at the JFIF image attached to the bug report from the SWT link above.  In that case...it looks like the APPN Segment came just after the Comment segment...which is definitely not the spec.  However, the image should still be readable.  I've looked at quite a few jpeg libraries now and it seems like standard practice to only assume the SOI (Start Of Image) segment is first and valid.  There are some popular jpeg writers that mess it up, but it's just metadata so readers should be able to continue forward.

So removing that assumption still seems like the right approach to me.  I will put in a case and get it fixed for the next release.

Thanks

On Saturday, June 13, 2015 at 11:53:08 AM UTC-4, Seth Berman wrote:

Hello,

Back in 2001, SWT (The Java port of Cg/Cw in VA) had a <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&amp;id=4780" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fbugs.eclipse.org%2Fbugs%2Fshow_bug.cgi%3Fformat%3Dmultiple%26id%3D4780\46sa\75D\46sntz\0751\46usg\75AFQjCNEjJ8zRVSdEXM6VbO5S8QEI6Gcu-A';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fbugs.eclipse.org%2Fbugs%2Fshow_bug.cgi%3Fformat%3Dmultiple%26id%3D4780\46sa\75D\46sntz\0751\46usg\75AFQjCNEjJ8zRVSdEXM6VbO5S8QEI6Gcu-A';return true;">bug reported on exactly this issue.  The result was, and I just confirmed in the source code, to remove the appn segment verification.  In their particular case, whatever created the image produced a unknown APPN byte (...opening in paint and resaving fixes that up).  However, I see for Exif that readers should be designed to skip over invalid APPN and COM.

All this to say...I think we will remove it.

--Seth

On Friday, June 12, 2015 at 6:50:45 PM UTC-4, Richard Sargent wrote:

On Friday, June 12, 2015 at 6:22:02 AM UTC-7, Louis LaBrunda wrote:

Hi Carl,

This sounds like a problem I think I reported but is not fixed yet.  I removed a line of code from a CgJPEGFileFormat class method #formatMatchesByteStream:.  I can't remember if this was a real fix or a circumvention.

Lou

formatMatchesByteStream: byteStream

"Answer true if the input specified by the CgByteStream

byteStream matches the receiver's format.

Answer false if the file does not match the receiver's format.

The input is read starting at the given 0-based offset.

NOTE - Always seek back to original position of the byteStream."

| soi appn originalPosition noMatch |

originalPosition := byteStream position.

noMatch := [byteStream lseek: originalPosition whence: SEEKSET. ^false].

(soi := CgJPEGStartOfImage fromStream: byteStream) verify

ifFalse: noMatch.

appn := CgJPEGAppn fromStream: byteStream.

" Removed by LL to fix test.

(appn verify and: [appn segmentMarker == APP0])

ifFalse: noMatch.

"

Per this article in Wikepedia (<a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format):
"For a valid JFIF file, the APP0 marker segment is mandatory right after the SOI marker."

The actual JPEG article (<a href="https://en.wikipedia.org/wiki/JPEG" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;">https://en.wikipedia.org/wiki/JPEG) says:
"The first of these, released in 1992, was <a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" title="JPEG File Interchange Format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">JPEG File Interchange Format (or JFIF), followed in recent years by <a href="https://en.wikipedia.org/wiki/Exchangeable_image_file_format" title="Exchangeable image file format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;">Exchangeable image file format (Exif) and <a href="https://en.wikipedia.org/wiki/International_Color_Consortium" title="International Color Consortium" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;">ICC <a href="https://en.wikipedia.org/wiki/ICC_Profile" title="ICC Profile" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;">color profiles. Both of these formats use the actual JIF byte layout, consisting of different markers, but in addition employ one of the JIF standard's extension points, namely the application markers: JFIF use APP0, while Exif use APP1."

I read all that as saying that you can have an EXIF file which is not JFIF compliant and you can have a JPEG image in a file without the file being JFIF formatted.

Even so, it sounds like an unusual file. Where did you get it?

byteStream lseek: originalPosition whence: SEEKSET.

^true

On Thursday, June 11, 2015 at 3:13:32 PM UTC-4, Carl Gundel wrote:

Sometimes when attempting to load images from .jpg files, some files will not load.  The following warning will display.

 

    File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).

 

If I load the offending file into Windows paint and resave it then it will load.  Ideas?

 

Thanks,

 

-Carl

 

CgPixmap class>>imageFromFile: aFileName
 "Answer a new image loaded from <aFileName>"

 | file readerClass reader image |

 (file := CfsFileDescriptor open: aFileName oflag: 0) isCfsError
  ifTrue: [
   (file := CfsFileDescriptor open: CgScreen bitmapPath first, aFileName oflag: 0) isCfsError
    ifTrue: [
     CgServer default warning: 'Could not open the selected file.'.
     ^nil]].
 readerClass :=
  CgImageFileFormat
   formatMatchingFileHandle: file
   atOffset: 0
   ifNone: [
    file close.
    CgServer default warning: 'File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).'.
    ^nil].
 image := (reader := readerClass new) loadFromFileHandle: file atOffset: 0.
 reader hasErrorOccurred
  ifTrue: [self error: 'Unable to load bitmap file: ', aFileName].
 file close.
 image isNil
   ifTrue: [
    file close.
    CgServer default warning: reader currentErrorString.
    ^nil].
 ^image

Hi Seth,

Would it make sense to throw a resumable error?  That way the developer could decide to ignore the error and move on or stop.

Lou

On Saturday, June 13, 2015 at 3:51:55 PM UTC-4, Seth Berman wrote:

Opened Case 58094: Relax JPEG reader's assumption that APPN segment immediately follows SOI

On Saturday, June 13, 2015 at 3:36:50 PM UTC-4, Seth Berman wrote:

All,

I've done some more testing and looked specifically at the JFIF image attached to the bug report from the SWT link above.  In that case...it looks like the APPN Segment came just after the Comment segment...which is definitely not the spec.  However, the image should still be readable.  I've looked at quite a few jpeg libraries now and it seems like standard practice to only assume the SOI (Start Of Image) segment is first and valid.  There are some popular jpeg writers that mess it up, but it's just metadata so readers should be able to continue forward.

So removing that assumption still seems like the right approach to me.  I will put in a case and get it fixed for the next release.

Thanks

On Saturday, June 13, 2015 at 11:53:08 AM UTC-4, Seth Berman wrote:

Hello,

Back in 2001, SWT (The Java port of Cg/Cw in VA) had a <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&amp;id=4780" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fbugs.eclipse.org%2Fbugs%2Fshow_bug.cgi%3Fformat%3Dmultiple%26id%3D4780\46sa\75D\46sntz\0751\46usg\75AFQjCNEjJ8zRVSdEXM6VbO5S8QEI6Gcu-A';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fbugs.eclipse.org%2Fbugs%2Fshow_bug.cgi%3Fformat%3Dmultiple%26id%3D4780\46sa\75D\46sntz\0751\46usg\75AFQjCNEjJ8zRVSdEXM6VbO5S8QEI6Gcu-A';return true;">bug reported on exactly this issue.  The result was, and I just confirmed in the source code, to remove the appn segment verification.  In their particular case, whatever created the image produced a unknown APPN byte (...opening in paint and resaving fixes that up).  However, I see for Exif that readers should be designed to skip over invalid APPN and COM.

All this to say...I think we will remove it.

--Seth

On Friday, June 12, 2015 at 6:50:45 PM UTC-4, Richard Sargent wrote:

On Friday, June 12, 2015 at 6:22:02 AM UTC-7, Louis LaBrunda wrote:

Hi Carl,

This sounds like a problem I think I reported but is not fixed yet.  I removed a line of code from a CgJPEGFileFormat class method #formatMatchesByteStream:.  I can't remember if this was a real fix or a circumvention.

Lou

formatMatchesByteStream: byteStream

"Answer true if the input specified by the CgByteStream

byteStream matches the receiver's format.

Answer false if the file does not match the receiver's format.

The input is read starting at the given 0-based offset.

NOTE - Always seek back to original position of the byteStream."

| soi appn originalPosition noMatch |

originalPosition := byteStream position.

noMatch := [byteStream lseek: originalPosition whence: SEEKSET. ^false].

(soi := CgJPEGStartOfImage fromStream: byteStream) verify

ifFalse: noMatch.

appn := CgJPEGAppn fromStream: byteStream.

" Removed by LL to fix test.

(appn verify and: [appn segmentMarker == APP0])

ifFalse: noMatch.

"

Per this article in Wikepedia (<a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format):
"For a valid JFIF file, the APP0 marker segment is mandatory right after the SOI marker."

The actual JPEG article (<a href="https://en.wikipedia.org/wiki/JPEG" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG\46sa\75D\46sntz\0751\46usg\75AFQjCNEX-85g1rd4QpGaW6WesErRN0YgWA';return true;">https://en.wikipedia.org/wiki/JPEG) says:
"The first of these, released in 1992, was <a href="https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format" title="JPEG File Interchange Format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJPEG_File_Interchange_Format\46sa\75D\46sntz\0751\46usg\75AFQjCNG1rSe9osn8vfQRU1j_ieR5dxBDKg';return true;">JPEG File Interchange Format (or JFIF), followed in recent years by <a href="https://en.wikipedia.org/wiki/Exchangeable_image_file_format" title="Exchangeable image file format" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExchangeable_image_file_format\46sa\75D\46sntz\0751\46usg\75AFQjCNHc1JoYnQ2G6l8o0FpZ-ykwfFc5ag';return true;">Exchangeable image file format (Exif) and <a href="https://en.wikipedia.org/wiki/International_Color_Consortium" title="International Color Consortium" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FInternational_Color_Consortium\46sa\75D\46sntz\0751\46usg\75AFQjCNGEmPXRMlCJIETJngq55meG8ZBL7Q';return true;">ICC <a href="https://en.wikipedia.org/wiki/ICC_Profile" title="ICC Profile" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICC_Profile\46sa\75D\46sntz\0751\46usg\75AFQjCNGMS8tbDwckmsOAYFflwkOcFdAkIw';return true;">color profiles. Both of these formats use the actual JIF byte layout, consisting of different markers, but in addition employ one of the JIF standard's extension points, namely the application markers: JFIF use APP0, while Exif use APP1."

I read all that as saying that you can have an EXIF file which is not JFIF compliant and you can have a JPEG image in a file without the file being JFIF formatted.

Even so, it sounds like an unusual file. Where did you get it?

byteStream lseek: originalPosition whence: SEEKSET.

^true

On Thursday, June 11, 2015 at 3:13:32 PM UTC-4, Carl Gundel wrote:

Sometimes when attempting to load images from .jpg files, some files will not load.  The following warning will display.

 

    File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).

 

If I load the offending file into Windows paint and resave it then it will load.  Ideas?

 

Thanks,

 

-Carl

 

CgPixmap class>>imageFromFile: aFileName
 "Answer a new image loaded from <aFileName>"

 | file readerClass reader image |

 (file := CfsFileDescriptor open: aFileName oflag: 0) isCfsError
  ifTrue: [
   (file := CfsFileDescriptor open: CgScreen bitmapPath first, aFileName oflag: 0) isCfsError
    ifTrue: [
     CgServer default warning: 'Could not open the selected file.'.
     ^nil]].
 readerClass :=
  CgImageFileFormat
   formatMatchingFileHandle: file
   atOffset: 0
   ifNone: [
    file close.
    CgServer default warning: 'File is not a supported type of bitmapped image (.bmp, .pcx, .tif, .gif, .jpg).'.
    ^nil].
 image := (reader := readerClass new) loadFromFileHandle: file atOffset: 0.
 reader hasErrorOccurred
  ifTrue: [self error: 'Unable to load bitmap file: ', aFileName].
 file close.
 image isNil
   ifTrue: [
    file close.
    CgServer default warning: reader currentErrorString.
    ^nil].
 ^image