search

google-code-export / thebigpicture

Automatically exported from code.google.com/p/thebigpicture
1 stars 1 forks source link

Jpeg reading and writing is a bit flaky #5

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The JPEG segments need to be ordered in a certain way within a JPEG file.
This should be taken into account for the file writing.

The Exif spec does say something on the subject.

Original issue reported on code.google.com by p.edel...@gmail.com on 13 Mar 2007 at 6:26

GoogleCodeExporter commented 9 years ago

Original comment by p.edel...@gmail.com on 16 Mar 2007 at 10:16

GoogleCodeExporter commented 9 years ago 
This should be resolved before the first alpha release.

Original comment by p.edel...@gmail.com on 17 Mar 2007 at 11:24

GoogleCodeExporter commented 9 years ago 
This attached 1992 JPEG spec might shine some light on this issue, although it
probably misses some segments which were added later.

It is obtained from Wikipedia.

Original comment by p.edel...@gmail.com on 20 Mar 2007 at 8:54

Attachments:

GoogleCodeExporter commented 9 years ago 
The ordering is now more or less correct, but the file structure may be not. 
Jpeg
specifies different ways of encoding an image (progressive/sequential/etc), and 
there
are multiple structures in structures. Right now the reader just reads the 
segments
until in encounters image data, and from there on copies everything verbatim to 
the
end of the file.
The file should be better parsed in the second alpha version.

Original comment by p.edel...@gmail.com on 1 Apr 2007 at 8:21

GoogleCodeExporter commented 9 years ago 
v1-alpha2 is an intermediate release. This issue is shifted to v1-alpha3.

Original comment by p.edel...@gmail.com on 10 Apr 2007 at 9:10

GoogleCodeExporter commented 9 years ago 
There are multiple ways to encode a Jpeg file:
- Sequential: everything is read from start to end (there is one frame in the 
file,
and that frame contains one scan)
- Progressive: the image data is read with improving refinement (there is one 
frame
in the file, and the frame contains multiple scans)
- Hierarchical: the image is read with multiple resolutions (there are multiple
frames in the file).

In each case, the image data is preceded by a place where metadata may be 
sotred. The
difficulty arises with multi-scan and multi-frame images. These also contain 
places
where metadata may be stored throughout. It is not likely that these will ever 
be
used, but it's not impossible.

It's not a big deal to read them, but they have to be written into the same 
parts.

Since both Exif and Jfif require the metadata segments to be present before the 
image
data, it might be a reasonable option to ignore everything that comes after the 
SOF
segments (or DHP in the case of hierarchical files).

Original comment by p.edel...@gmail.com on 22 Apr 2007 at 12:33

GoogleCodeExporter commented 9 years ago 
According to the Jpeg spec, the tables/miscellanious data preceding the image 
data
may contain Quantization table-specification (DQT), Huffman table-specification
(DHT), Arithmetic conditioning table-specification, Restart interval definition
(DRI), Comment (COM), and Application data (APPn). These "be present in any 
order and
with no limit on the number of segments."

In our implementation (revision 55), only these elements are written (if they 
are
loaded) by the Jpeg writer.

Original comment by p.edel...@gmail.com on 22 Apr 2007 at 1:30