+ update 2020: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means we will NOT develop new features and/or fix most of bugs. We left the tracker running in case somebody from community would like to work on it. Sorry for the inconvenience.
State: closed new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
Using version 7.1.2 to export JPEG images produces an output file that is invalid.
On investigation I found there were four spurious bytes in the header of the output file
(at position 023Ch - 023Fh) removing these bytes corrects the problem.
Easy enough to put right but I shouldn't need to...
For me it seems that your swf file contains the wrong image data.
Interesting that Java and Adobe flash can open it without any problem.
the extra bytes (D9 FF D8 FF) are usually an error header in lower SWF versions, but in
your file it is in the middle of the binary image data.
In some SWFs (maybe lower versoins) the jpeg header was separated to a JpegTablesTag
So probably your image was earlier in a DefineBitsTag (with error header) + JpegTablesTag,
and something converted this to a DefineBitsJpeg2 tag without removing the error header.
You can check this with FFDec:
- change the view to "Hex dump"
- Select DefineBitsJPEG2 (125)/imageData in the tree
The jpeg binary data is hilighted with green color, you can see that the 4 extra bytes are
in the middle of the data.
However FFDec could recompress the image, which would save a correct image file, but i
think this is not a good solution. Currently it is designed to save the original (not
recompressed) image data. So I think this is not a bug in FFDec.
Do you know anything about this SWF? Where is it from? Was it edited earlier?