libpgf-devel Mailing List for libPGF
libPGF is an implementation of the Progressive Graphics File (PGF)
Brought to you by:
c_stamm
Menu
▾
▴
libpgf-devel — List for developers of the libPGF itself.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(4) |
| 2010 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: bucketbot <buc...@ya...> - 2014-06-09 10:42:32
|
Hi, Can anyone tell me if it would be possible to leverage OpenCL (and thereby GPU stream processors) to parallelize the DWT operations for PGF compression (and decompression)? I assume the DWTs would be the main beneficiary but perhaps there are other parts of the process that would benefit, as well. Thanks! |
|
From: Timothy B. <tj...@mt...> - 2012-05-22 20:29:35
|
Hello,
While working on a project using the ROI feature I came upon a seg fault.
The problem was that a value was going negative when I was not suppose in
the CSubband class. The offending method is the PlaceTile method. Here is
the original method pulled from your documentation:
// allocate memory
if (!AllocMemory()) ReturnWithError(InsufficientMemory);
// correct quantParam with normalization factor
if (m_orientation == LL) {
quantParam -= m_level + 1;
} else if (m_orientation == HH) {
quantParam -= m_level - 1;
} else {
quantParam -= m_level;
}
if (quantParam < 0) quantParam = 0;
#ifdef __PGFROISUPPORT__
if (tile) {
// compute tile position and size
const PGFRect& roi = m_ROIs->GetROI(m_level);
UINT32 xPos, yPos, w, h;
TilePosition(tileX, tileY, xPos, yPos, w, h);
// read values into buffer using partitiong scheme
decoder.Partition(this, quantParam, w, h, (xPos - roi.left) + (yPos -
roi.top)*m_dataWidth, m_dataWidth);
} else
#endif
{
// read values into buffer using partitiong scheme
decoder.Partition(this, quantParam, m_width, m_height, 0, m_width);
}
Here is the new updated method:
// correct quantParam with normalization factor
if (m_orientation == LL) {
quantParam -= m_level + 1;
} else if (m_orientation == HH) {
quantParam -= m_level - 1;
} else {
quantParam -= m_level;
}
if (quantParam < 0) quantParam = 0;
#ifdef __PGFROISUPPORT__
if (tile) {
// compute tile position and size
const PGFRect& roi = m_ROIs->GetROI(m_level);
UINT32 xPos, yPos, w, h;
TilePosition(tileX, tileY, xPos, yPos, w, h);
int startPos = (xPos - roi.left) + (yPos - roi.top)*m_dataWidth;
// read values into buffer using partitiong scheme
decoder.Partition(this, quantParam, w, h,(startPos <= 0 ? -startPos :
startPos), m_dataWidth);
} else
#endif
{
// read values into buffer using partitiong scheme
decoder.Partition(this, quantParam, m_width, m_height, 0, m_width);
}
Tim Bradt
|
|
From: Vlado P. <re...@vl...> - 2011-08-07 10:45:18
|
Dear PGF developers,
when I wanted to install digiKam 2.0, compilation of libpgf failed. So
I tried to compile just libpgf, version 6.11 from the sourceforge site,
and the result was the same:
> [...]/libpgf/Encoder.cpp: In member function ‘void
> CEncoder::WriteMacroBlock(CEncoder::CMacroBlock*)’:
> [...]/libpgf/Encoder.cpp:313:3: error: ‘m_codeBuffer’ was not
> declared in this scope
Looking at the source and seeing quite a few "#ifdef
PGF_USE_BIG_ENDIAN" I assume it's an endian issue again (?). This is
still Linux on a PPC, but I'll probably buy an AMD64 machine
replacement this year...
Regards,
Vlado
--
Vlado Plaga __o
http://vlado-do.de _o/\<,_
update: 2011-05-17 (U)/ (u)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
From: Schweizer R. <rap...@fh...> - 2011-04-22 15:16:33
|
So far the maintainers of digiKam have always provided their patches, so yes, fixes from the KDE repository eventually get applied to mainstream. In my understanding libpgf in KDE is more like a branch than a fork. The branches are periodically synced, s.t. digiKam contains the most recent features and we have the latest patches. Disclaimer: I have not compared KDE and mainstream since digiKam moved to GIT. Best regards, Raphael Schweizer On 2011-04-19 Mateusz Loskot wrote: [...] I'm wondering, is the mainstream being kept in sync with fixes applied to the libpgf fork maintained in the KDE repository? [...] |
|
From: Mateusz L. <ma...@lo...> - 2011-04-19 15:00:40
|
Folks, Gentoo patched libpgf.pc. Perhaps it would be a good idea to apply it to mainstream: https://sourceforge.net/tracker/?func=detail&aid=3289603&group_id=157509&atid=804115 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org |
|
From: Mateusz L. <ma...@lo...> - 2011-04-19 14:42:57
|
Hi, I'm wondering, is the mainstream being kept in sync with fixes applied to the libpgf fork maintained in the KDE repository? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org |
|
From: Mateusz L. <ma...@lo...> - 2011-04-19 14:21:14
|
On 19/04/11 13:08, Stamm Christoph wrote: > Hi Mateusz > > So far, nobody informed us about a C API wrapper implementation. Hi Chris, I see. Thanks. p.s. Not sure why your reply didn't go to the libpgf-devel, so I CC'd my response. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org |
|
From: Mateusz L. <ma...@lo...> - 2011-04-19 09:19:19
|
Folks, I'm looking for a simple C API wrapper for libpgf. Does anyone know if there is anything like that around? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org |
|
From: Mateusz L. <ma...@lo...> - 2010-01-09 02:10:33
|
Stamm Christoph wrote: > Hi > > PGF is an open format with publicly available specification, but > copyright protected with LGPL. So, both the PGF format and the source > code are under LGPL. If you plan to modify the PGF format and/or > libpgf and distribute them, then you are allowed to do it in case you > choose a compatible license for your modified code. In case your > modified file format is not compatible with libpgf, then you are not > allowed to call the new format PGF. > > PGF can be used to build something similar to MrSID. We also > developped something similar, called PGFext, but so far, we didn't > publish any information about it. Hi Chris, That's the answer I was looking for. Thank you very much! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org |
|
From: Stamm C. <chr...@fh...> - 2010-01-08 12:51:40
|
Hi PGF is an open format with publicly available specification, but copyright protected with LGPL. So, both the PGF format and the source code are under LGPL. If you plan to modify the PGF format and/or libpgf and distribute them, then you are allowed to do it in case you choose a compatible license for your modified code. In case your modified file format is not compatible with libpgf, then you are not allowed to call the new format PGF. PGF can be used to build something similar to MrSID. We also developped something similar, called PGFext, but so far, we didn't publish any information about it. Chris -----Ursprüngliche Nachricht----- Von: Mateusz Loskot [mailto:ma...@lo...] Gesendet: Freitag, 8. Januar 2010 00:17 An: Lib...@li... Betreff: [Libpgf-devel] Licensing of PGF specification Hi, Perhaps I'm about to ask weird question but I could not find any clear clarification. What is the copyright and licensing of the PGF format itself? Is this considered as an open format with publicly available specification? Does PGF specificatoin provide users with the liberty to develop, modify and distribute their own implemenations? It is clear to me that source code of the libpgf is LGPL licensed. What about the specification itself? How does it compare to ECW and MrSID on this ground? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Libpgf-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libpgf-devel |
|
From: Mateusz L. <ma...@lo...> - 2010-01-07 23:17:11
|
Hi, Perhaps I'm about to ask weird question but I could not find any clear clarification. What is the copyright and licensing of the PGF format itself? Is this considered as an open format with publicly available specification? Does PGF specificatoin provide users with the liberty to develop, modify and distribute their own implemenations? It is clear to me that source code of the libpgf is LGPL licensed. What about the specification itself? How does it compare to ECW and MrSID on this ground? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org |
|
From: Mateusz L. <ma...@lo...> - 2009-12-24 11:26:08
|
Stamm Christoph wrote: > Hi Mateusz > >> Does it mean portability is a no priority for libpgf library? > > Not at all. So far we tried to support the most popular platforms and > those where users asked for special help. Thanks for confirmation. It sounds good. >> I mean the functions already provided as extension to C/C++ >> Standard Library in Visual C++. > > In case you are interested in a Standard C or STL connection, it > would be the best, you do the necessary changes in platform.h and/or > the PGFStream classes. Afterwards, you can send me the modified files > and we will try to integrate them in further releases. Yesterday, it was my first attempt to get familiar with libpgf and I spotted the use of MFC/Windows API, so it raised my questions. Later on, I dug the code and found that it's wrapped with conditional compilation very well, so should not cause any problems on non-Windows platforms. As you confirms intention to support other platforms, then it's very well. In case I have updates, I'll submit them. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net |
|
From: Mateusz L. <ma...@lo...> - 2009-12-23 17:38:28
|
Stamm Christoph wrote: > Hi Mateusz > > libpgf is originally a Windows project used in several MFC > applications. Does it mean portability is a no priority for libpgf library? > The POSIX compatibility layer has been developed later > for non-Windows platforms. > Using the POSIX compatibility layer also > on Windows would create an additional and needless indirection. I mean the functions already provided as extension to C/C++ Standard Library in Visual C++. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net |
|
From: Stamm C. <chr...@fh...> - 2009-12-23 17:27:41
|
Hi Mateusz libpgf is originally a Windows project used in several MFC applications. The POSIX compatibility layer has been developed later for non-Windows platforms. Using the POSIX compatibility layer also on Windows would create an additional and needless indirection. Chris ________________________________________ Von: Mateusz Loskot [ma...@lo...] Gesendet: Mittwoch, 23. Dezember 2009 13:52 An: lib...@li... Betreff: [Libpgf-devel] Why use of MFC and Windows API? Hi, It's my first post, so I'd like to say hello to all? I'm reading the libpgf implementation, namely PGFplatform.h file. I'm curious what's the reason of use of MFC or Windows API instead of file I/O functions from POSIX comatibility layer provided by Visual C++, it is _read, _write, _lseek and related functions? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Libpgf-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libpgf-devel |
|
From: Mateusz L. <ma...@lo...> - 2009-12-23 13:06:35
|
Hi, It's my first post, so I'd like to say hello to all? I'm reading the libpgf implementation, namely PGFplatform.h file. I'm curious what's the reason of use of MFC or Windows API instead of file I/O functions from POSIX comatibility layer provided by Visual C++, it is _read, _write, _lseek and related functions? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net |
|
From: Raphael S. <rsc...@sc...> - 2009-10-29 13:21:54
|
Dear PGF users a new release (6.09.44) of the codec and the accompanying console application is now available on sourceforge. CHANGES: ======== Codec - fixed decoder crash on bigendian systems Console - channel swap for bigendian - updated to FreeImage 3.13.0 - removed unused header installs Win/VS - fixed VS project settings Please report any issues you encounter. Regards, Raphael |
|
From: Raphael S. <rsc...@sc...> - 2009-10-26 21:56:12
|
Hi Allen thank you for reporting this issue. Other users have reported the same problem as well and we will provide a fix soon. To get a notification you might want to monitor http://sourceforge.net/tracker/?func=detail&aid=2886717&group_id=157509&atid =804113. Regards Raphael Junior libPGF dev team member > -----Ursprüngliche Nachricht----- > Von: Allen Guan [mailto:<hidden>] > Gesendet: Montag, 26. Oktober 2009 20:36 > An: lib...@li... > Betreff: [Libpgf-devel] I have a problem when encoding in little endian > machine then decode in a big endian machine > > Hi, all, > > I have written a program running on Mac, but meet a problem with > obviously big/little endian issue. > > if I encode the data in an intel-cpu machine(little endian), then try > to > decode it in an old machine(big endian), the code crash, and the > following message is received: > ------------- > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_INVALID_ADDRESS (0x0001) at 0xc0000000 > > Thread 0 Crashed: > 0 ...rcompany.yourcocoaframework 0x00171580 > ClearBitBlock(unsigned*, unsigned, unsigned) + 92 > 1 ...rcompany.yourcocoaframework 0x00164d7c > CDecoder::RLDSigsAndSigns(unsigned, unsigned, unsigned*, unsigned*) + > 172 > 2 ...rcompany.yourcocoaframework 0x001651a4 > CDecoder::BitplaneDecode(unsigned) + 292 > ---------------- > it shows the crash is in the ClearBitBlock() function. > > but if I encode the data in the old machine(big endian), then decode it > in the intel-cpu machine(little endian), it just works fine. > > btw, I just tested both encoding/decoding on the old machine(big > endian), it crashed at the same place. looks to me the decoding in big > endian machine has some problems. > > I wonder if any of you could help me on this. Thanks a lot in advance. > > Yours Sincerely, > > -Allen |
|
From: Allen G. <all...@al...> - 2009-10-26 20:39:59
|
Hi, all, I have written a program running on Mac, but meet a problem with obviously big/little endian issue. if I encode the data in an intel-cpu machine(little endian), then try to decode it in an old machine(big endian), the code crash, and the following message is received: ------------- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xc0000000 Thread 0 Crashed: 0 ...rcompany.yourcocoaframework 0x00171580 ClearBitBlock(unsigned*, unsigned, unsigned) + 92 1 ...rcompany.yourcocoaframework 0x00164d7c CDecoder::RLDSigsAndSigns(unsigned, unsigned, unsigned*, unsigned*) + 172 2 ...rcompany.yourcocoaframework 0x001651a4 CDecoder::BitplaneDecode(unsigned) + 292 ---------------- it shows the crash is in the ClearBitBlock() function. but if I encode the data in the old machine(big endian), then decode it in the intel-cpu machine(little endian), it just works fine. btw, I just tested both encoding/decoding on the old machine(big endian), it crashed at the same place. looks to me the decoding in big endian machine has some problems. I wonder if any of you could help me on this. Thanks a lot in advance. Yours Sincerely, -Allen |
|
From: Allen <all...@gm...> - 2009-10-26 19:43:03
|
Hi, all, I have written a program running on Mac, but meet a problem with obviously big/little endian issue. if I encode the data in an intel-cpu machine(little endian), then try to decode it in an old machine(big endian), the code crash, and the following message is received: ------------- Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xc0000000 Thread 0 Crashed: 0 ...rcompany.yourcocoaframework 0x00171580 ClearBitBlock(unsigned*, unsigned, unsigned) + 92 1 ...rcompany.yourcocoaframework 0x00164d7c CDecoder::RLDSigsAndSigns(unsigned, unsigned, unsigned*, unsigned*) + 172 2 ...rcompany.yourcocoaframework 0x001651a4 CDecoder::BitplaneDecode(unsigned) + 292 ---------------- it shows the crash is in the ClearBitBlock() function. but if I encode the data in the old machine(big endian), then decode it in the intel-cpu machine(little endian), it just works fine. btw, I just tested both encoding/decoding on the old machine(big endian), it crashed at the same place. looks to me the decoding in big endian machine has some problems. I wonder if any of you could help me on this. Thanks a lot in advance. Yours Sincerely, -Allen |
|
From: Raphael S. <rsc...@sc...> - 2009-10-22 14:32:32
|
Dear users of bigendian systems we just got hold of a G5 and will start investigating immediately. Regards, Raphael |
|
From: Vlado P. <re...@vl...> - 2009-10-21 16:19:01
|
Dear libpgf developers, digiKam reproducibly crashes on my powerpc system with libpgf enabled. I tried several Linux distributions (Debian, Fedora, and Ubuntu), tried the supplied packages, and self-compiled versions. Only disabling libpgf cured the problem described in this bug report: http://bugs.kde.org/show_bug.cgi?id=210580 Someone commented on that bug suggesting to contact the libpgf maintainers directly, so that's what I try with this message. In case you don't have a bigendian system to experiment with, you might want to try qemu. I had good results running M$ Windows in qemu about two years ago, when I only had a powerpc computer and occasionally needed to test a web site with M$ Internet Explorer: http://www.nongnu.org/qemu/status.html I just tried installing Debian ARM in such a machine today, which was extremely slow, but worked. Only I could not boot the system, and I did not bother exploring that problem further. Instead I downloaded and successfully booted a complete Debian system (on ARM), according to these simple instructions: http://people.debian.org/~aurel32/qemu/arm/ RAM in qemu is limited to 256 MBytes, so I guess actually running digiKam is not an option, but such a virtual machine might be ok for just testing/ debugging the library. Unfortunately I'm not able to do that myself. Regards, Vlado |
|
From: Jan W. <was...@fo...> - 2008-01-09 13:03:07
|
Dear developers,
thank you for providing libPGF in open-source form!
I am endeavouring to speed up loading of large (200 MB) images by
decompressing them on the fly during IO.
While PGF is quite fast compared to JPEG-LS, its decompression =
throughput
turns out to be slower than reading from the hard-drive. Unfortunately =
that
makes it unsuitable for the current application, but I'd like to pass on
several minor changes that were observed to improve performance on this
Athlon x2 system:
- Decoder.h SetSign: OR-in the sign bit directly (avoids a conditional
branch)
void SetSign(UINT32 pos, bool sign)
{
pos |=3D ((UINT32)sign) << 31;
// if (sign && m_value[pos] >=3D 0)
// m_value[pos] =3D -m_value[pos];
}
- BitStream.h SeekBitRange: use pointer instead of base/displacement
addressing, restructure loop to reduce branches, make use of integer
overflow when left-shifting
inline UINT32 SeekBitRange(UINT32* stream, UINT32 pos, UINT32 len) {
UINT32 count =3D 0;
UINT32 testMask =3D 1 << (pos%WordWidth);
UINT32* word =3D stream + (pos >> WordWidthLog);
for(;;)
{
if(*word & testMask)
return count;
count++;
if(count >=3D len)
return len;
testMask *=3D 2;
if(!testMask) // overflow
{
word++; testMask =3D 1;
// fast steps if all bits in a word are zero
while ((count + WordWidth <=3D len) && (*word =3D=3D 0)) {
word++;=20
count +=3D WordWidth;
}
}
}
}
Hopefully this is helpful.
Do you know of any efforts to sacrifice compression ratios for =
decompression
throughput that is competitive with hard drives? My layman's impression =
is
that simple LZ compression of the wavelet coefficients (analogous to =
PNG's
zlib compression of Paeth-filtered pixels) may be successful. Has this =
been
tried during development?
Best Regards
Jan Wassenberg
|
|
From: Thomas S. <ts...@me...> - 2006-05-29 21:23:47
|
Hi Andreas, I already attached my work to the email you responded to. No matter - I've cleaned it up further. The archive attached to this email includes the previous changes as well as the following stuff * Included libpgf.spec.in and added target 'rpm' to Makefile.am * Removed all generated/copied autotools files - they should not be in the repository Still to do: * Make PGFConsole work against the new libpgf structure * Update the visual studio and eclipse project files * Generate pdf manual and include it in the devel rpm Best regards, Thomas Andreas Hofmann wrote: >Hello Thomas, > >thanks for your suggestions for improvements and work done concerning >repackaging. I agree with you that reorganisation of the structure would >be a nice idea. You offered some help, and I gladly take as much help as > I can get. If you could send me an archive of your reorganized project, >I will take a look at it and commit it to subversion. > >Best regards >Andreas Hofmann > > > > > |
|
From: Thomas S. <ts_...@so...> - 2006-05-29 21:23:42
|
Hi Andreas, I already attached my work to the email you responded to. No matter - I've cleaned it up further. The archive attached to this email includes the previous changes as well as the following stuff * Included libpgf.spec.in and added target 'rpm' to Makefile.am * Removed all generated/copied autotools files - they should not be in the repository Still to do: * Make PGFConsole work against the new libpgf structure * Update the visual studio and eclipse project files * Generate pdf manual and include it in the devel rpm Best regards, Thomas Andreas Hofmann wrote: >Hello Thomas, > >thanks for your suggestions for improvements and work done concerning >repackaging. I agree with you that reorganisation of the structure would >be a nice idea. You offered some help, and I gladly take as much help as > I can get. If you could send me an archive of your reorganized project, >I will take a look at it and commit it to subversion. > >Best regards >Andreas Hofmann > > > > > |
|
From: Andreas H. <and...@fh...> - 2006-05-29 15:09:23
|
Hello Thomas, thanks for your suggestions for improvements and work done concerning repackaging. I agree with you that reorganisation of the structure would be a nice idea. You offered some help, and I gladly take as much help as I can get. If you could send me an archive of your reorganized project, I will take a look at it and commit it to subversion. Best regards Andreas Hofmann -- |
