• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..03-May-2022-

AUTHORSH A D25-Apr-20210

BitStream.hH A D03-May-202211.6 KiB342133

COPYINGH A D25-Apr-202123.8 KiB458386

Decoder.cppH A D03-May-202230.5 KiB1,037616

Decoder.hH A D03-May-20229.4 KiB21773

Encoder.cppH A D03-May-202224.2 KiB831457

Encoder.hH A D03-May-202210 KiB23489

PGFimage.cppH A D03-May-202285.5 KiB2,7331,985

PGFimage.hH A D03-May-202232.6 KiB582128

PGFplatform.hH A D03-May-202220.8 KiB639408

PGFstream.cppH A D03-May-20227.5 KiB275176

PGFstream.hH A D03-May-20227.3 KiB19485

PGFtypes.hH A D03-May-202211.6 KiB286136

READMEH A D25-Apr-20215.2 KiB11477

Subband.cppH A D03-May-202210.4 KiB389251

Subband.hH A D03-May-20227.2 KiB18159

WaveletTransform.cppH A D03-May-202218.7 KiB570399

WaveletTransform.hH A D03-May-20226.1 KiB14647

README

1The Progressive Graphics File
2=============================
3
4For more information see http://www.libpgf.org. There you can find some
5documents concerning this progressive graphic file codec.
6
7This project is hosted on the Sourceforge.net platform. For support and
8questions, please use the installed mailing list and forums there.
9The Sourceforge URL of our project is: http://sourceforge.net/projects/libpgf
10
11=============================
12Release Notes
13
14Version 7.19.3, (Tue, 15 Jan 2019)
15------------------------------------
16
171. The new version is a minor update of version 7.15.25.
18
192. This version fixes a compilation bug seen when ROI support is disabled.
20
21
22Version 7.15.32, (Thu, 6 Aug 2015)
23------------------------------------
24
251. The new version is a minor update of version 7.15.25.
26
272. This version improves the reuse of CPGFImage objects for several decoding operations.
28   It clarifies the usage of CPGFImage::Close() and CPGFImage::Destroy() by deletion of
29   Close(). Several reading operations can be performed in the following way:
30   Open(), Read(), GetBitmap(), ResetStreamPos(), Read(), GetBitmap(), ResetStreamPos(), ...
31   Calling Destroy() frees all allocated ressources and reinitializes the object to the
32   same state as the constructor does. This allows the reuse of the CPGFImage object for
33   encoding and decoding:
34   SetHeader(), ImportBitmap(), Write(), ResetStreamPos(), Destroy(), Open(), Read(), GetBitmap()
35
363. Caching or skipping of user data (meta data) while opening a PGF image can be controlled
37   by a new UserdataPolicy in ConfigureDecoder().
38
39
40Version 7.15.25, (Sat, 20 June 2015)
41------------------------------------
42
431. This new version is a replacement of version 6.14.12.
44   In case you use the ROI decoding, we strongly encourage using version 6.15.25 instead of an older version.
45
462. This version fixes some decoder bugs only seen in ROI decoding.
47   ROI decoding is now also supported for Bitmap and RGB12 image modes.
48
493. This version introduces a new and more efficient data format for binary images (bitmaps).
50   The new format allows ROI decoding.
51   The decoder supports both the old and the new format, but ROI decoding works only with the new format.
52
534. The two reserverd bytes in PGFHeader are now used for a more detailled PGF version number.
54
555. The Visual Studio project files are in the VS12 format.
56
57
58Version 6.14.12, (Wed, 9 April 2014)
59------------------------------------
60
611. The new version is a minor update of version 6.12.24.
62
632. It mainly contains some fixes of memory leaks in the OpenMP part and some improvements suggested by cppcheck and Coverity.
64
653. The Visual Studio project files are in the VS11 format.
66
67
68Version 6.12.24, (Thu, 14 June 2012)
69------------------------------------
70
711. The new version is a replacement of version 6.11.42.
72   In case you use the ROI encoding scheme, we strongly encourage using version 6.12.24 instead of version 6.11.42.
73
742. This version fixes some decoder bugs, sometimes seen in ROI decoding.
75
763. This version allows a simpler user-data handling, especially for uncached metadata. The following two methods
77   in the class PGFimage are designed for this purpose:
78
79	GetUserDataPos() returns in an opened PGF image the stream position of the user data area.
80
81	WriteImage() encodes and writes the image at the current stream position. This method is called after
82	WriteHeader(). In case you want to write uncached metadata into the stream, then do that after WriteHeader()
83	and just before WriteImage(). If you are not interested in writing uncached metadata, then you usually use
84	Write() instead of WriteImage(). WriteHeader() and WriteImage() are called inside of Write().
85
86
87Version 6.11.42, (Sun, 23 Oct 2011)
88-----------------------------------
89
901. The new version is a replacement of version 6.11.24.
91   We strongly encourage using version 6.11.42 instead of version 6.11.24.
92
932. This version fixes some decoder bugs, only seen in lossless compression of
94   large images.
95
963. The rarely used, but sometimes misused, background information (3 Bytes)
97   in the PGFHeader has been replaced by
98
99     UINT8 usedBitsPerChannel;    // number of used bits per channel
100                                  // in 16- and 32-bit per channel modes
101     UINT8 reserved1, reserved2;  // not used
102
103The value usedBitsPerChannel is helpful in case you have more than 8 (16) but
104less than 16 (32) significant bits per channel, stored in the most
105significant bits of a pixel. For example, you have a grayscale image with 14
106bit significant data per pixel stored in the ImageModeGray16 pixel format. In
107case you have left shifted the 14 bits to be the most significant 14 bits,
108then you should set usedBitsPerChannel=14. This will increase the compression
109ratio without any drawbacks, because the 14 bits are internally right shifted.
110On the other side, if the 14 bits are the least significant bits in
111your 16 bit pixel format, then you shoulden�t set usedBitsPerChannel. It will
112be automatically set to 16, but this is no problem, since the not used most
113significant bits per pixel are never coded at all. So, in both cases the same
114compression ratio will result.