Re: [Denemo-devel] Thumbnails

[Richard Shann]

On Fri, 2011-05-27 at 09:09 +0100, Richard Shann wrote:
> On Thu, 2011-05-26 at 23:01 +0200, Till Hartmann wrote:
> > I think what you have to do is to append "::Thumb::URI" to "tEXt" and
> > remove that piece from your current uri string:
> > gdk_pixbuf_save (pb, thumbpath, "png"/*type*/, &err,
> > "tEXt::Thumb::URI",
> > uri [...]) 
> That appears to work, thank you. I say appears as the warning message is
> gone, but I am not sure we have anything to retrieve the information
> currently...
This documentation (below) on the png file structure is enough to write
something to extract the mtime - we advance 8 bytes into the file then
read a 4-byte length (it doesn't say what endianness) and then then see
if the next 4 bytes are "tEXt" and if so if "Thumb::Mtime::" (or
whatever gdkpixbuf has stored...)
hmm...
Documentation below...
Richard
The first eight bytes of a PNG file always contain the following
(decimal) values:
137 80 78 71 13 10 26 10
This signature indicates that the remainder of the file contains a
single PNG image, consisting of a series of chunks beginning with
an IHDR chunk and ending with an IEND chunk.

3.2. Chunk layout
Each chunk consists of four parts:
Length
        A 4-byte unsigned integer giving the number of bytes in the
        chunk's data field. The length counts only the data
        field, not itself, the chunk type code, or the CRC. Zero is a
        valid length. Although encoders and decoders should treat the
        length as unsigned, its value must not exceed (2^31)-1 bytes.
Chunk Type
        A 4-byte chunk type code. For convenience in description and in
        examining PNG files, type codes are restricted to consist of
        uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90 and
        97-122 decimal). However, encoders and decoders must treat the
        codes as fixed binary values, not character strings. For
        example, it would not be correct to represent the type
        code IDAT by the EBCDIC equivalents of those letters. Additional
        naming conventions for chunk types are discussed in the next
        section.
Chunk Data
        The data bytes appropriate to the chunk type, if any. This field
        can be of zero length.
CRC
        A 4-byte CRC (Cyclic Redundancy Check) calculated on the
        preceding bytes in the chunk, including the chunk type code and
        chunk data fields, but not including the length field. The CRC
        is always present, even for chunks containing no data. See CRC
        algorithm.

The chunk data length can be any number of bytes up to the maximum;
therefore, implementors cannot assume that chunks are aligned on any
boundaries larger than bytes.

Chunks can appear in any order, subject to the restrictions placed on
each chunk type. (One notable restriction is that IHDR must appear first
and IEND must appear last; thus the IEND chunk serves as an end-of-file
marker.) Multiple chunks of the same type can appear, but only if
specifically permitted for that type.




> Richard
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel