Viewing Bug Advanced Details
599 Other crash always 02-24-06 12:11 02-28-06 10:55
dramsbro  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DLSkew causes segfault
DLSkew is causing a segfault in DLSkew::dlCalculateSkew(). I tested with several unrelated TIFF, JPEG, and GIF images, and always the same result. Below is the program output and gdb stack trace.

[spikes51@lamppc24 bin]$ ./DoclibCommandLine -input ~/DocLib\ Commandline/sample2_skewed_L.tif -deskew -output ~/temp.jpg
Opening /fs/lamphomes/spikes51/DocLib Commandline/sample2_skewed_L.tif
Deskew Image..
Segmentation fault

[spikes51@lamppc24 bin]$ gdb DoclibCommandLine
GNU gdb Red Hat Linux (6.1post-1.20040607.52rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run -input ~/DocLib\ Commandline/sample2_skewed_L.tif -deskew -output ~/temp.jpg
Starting program: /fs/lamphomes/spikes51/doclib/linux24/bin/DoclibCommandLine -input ~/DocLib\ Commandline/sample2_skewed_L.tif -deskew -output ~/temp.jpg
Opening /fs/lamphomes/spikes51/DocLib Commandline/sample2_skewed_L.tif
Deskew Image..

Program received signal SIGSEGV, Segmentation fault.
0x0807f493 in DLSkew::dlCalculateSkew ()
(gdb) backtrace
0 0x0807f493 in DLSkew::dlCalculateSkew ()
0000001 0x0807ee41 in DLSkew::dlDetectSkew ()
2 0x0804eaaf in DLCommandLineParser::processCommand ()
3 0x0804b819 in main ()
(gdb)
Bug Notes
meyers_tim   
02-24-06 14:16   
Daniel, can you please attach an image that is causing this problem?
dramsbro   
02-27-06 18:11   
I've tried uploading several different image files from several different browsers, but I keep getting an error when I click "Upload File." As I said in the original description though, pretty much ANY image should crash it when you run deskew. So far, I've tried about 10 completely unrelated images, and every single one of them has crashed the program.
meyers_tim   
02-28-06 10:55   
This issue has been resolved on the unclassified net. It may or may not be present on the internal version as the changes that caused the problem were done externally since the last release.

The problem was related to a problem with casting. It would somehow corrupt the memory in such a way that the tail of a DLPointList would be 0x01 as opposed to NULL - resulting in overextending the bounds and a seg fault.




Viewing Bug Advanced Details
601 Other trivial always 02-27-06 18:16 02-27-06 18:22
dramsbro  
dramsbro  
normal  
resolved  
fixed  
none  
none  
DoclibCommandLine - no error status returned
DoclibCommandLine does not return error status properly. The program always exits with status value 1, regardless of error condition. Being able to detect errors in this fashion is essential when calling the program from a web interface, and is also a generally good practice.
Bug Notes
dramsbro   
02-27-06 18:21   
A fix for DoclibCommandLine.cpp has been checked into CVS--now it returns zero by default, and one if there is some sort of error.
dramsbro   
02-27-06 18:22   
See bugnote above -- fix is in CVS.




Viewing Bug Advanced Details
598 Other trivial always 02-24-06 11:53 02-24-06 14:15
dramsbro  
meyers_tim  
normal  
resolved  
unable to duplicate  
none  
none  
Execute permissions for make.pl, configure
The latest CVS copy does not contain the proper execute permissions for the make.pl and configure scripts.

[spikes51@lamppc24 ~/doclib]$ ls -l configure
-rw-rw-r-- 1 spikes51 doc 129894 Feb 24 11:33 configure
[spikes51@lamppc24 ~/doclib]$ ls -l ReleaseDocs/make.pl
-rw-rw-r-- 1 spikes51 doc 11007 Feb 24 11:33 ReleaseDocs/make.pl

I have to manually do chmod u+x on these files before being able to run them. They should come out of CVS ready to go.
Bug Notes
meyers_tim   
02-24-06 14:15   
I just double checked the permissions on these files and they are both set to have execute permissions.




Viewing Bug Advanced Details
595 Other feature always 02-20-06 11:47 02-23-06 19:02
amsakak  
amsakak  
normal  
resolved  
fixed  
none  
none  
"make.pl 0 install" installation errors
Erros encountered when running "make.pl 0 install." Unable to install all binary executable, library, and headers files. See attachments.

Download latest code then run
make.pl 0 make >& make.out
make.pl 0 install >& make.install
Run on Redhat Linux machine. Output obtained by running on Saki's Dell laptop.
0000595-params (3 KB) 12-31-69 19:33
0000595-make.install (33 KB) 12-31-69 19:33
0000595-make.out (108 KB) 12-31-69 19:33
Bug Notes
amsakak   
02-23-06 19:02   
Code modifications made to HWFeatures, PageLayout, and the core doclib. For HWFeatures, things compiled fine but there were plenty of unneccessary files that were removed. All modes of "make.pl" were tested except the "save" mode. After verifying success, the changes were checked into CVS.




Viewing Bug Advanced Details
596 DLDocument major always 02-22-06 13:05 02-22-06 13:25
zhugy  
zhugy  
normal  
resolved  
fixed  
none  
none  
Exception occurs when invoking the DLZone copy construction
The following exception is thrown when I push back a zone to a list:

dlzone.cpp:80: <DLZone::=()> It is illegal to invoke copy function to reset a zone with an already initialized DLPage*s!
0000596-DLZone.cpp (30 KB) 12-31-69 19:33
Bug Notes
zhugy   
02-22-06 13:21   
When a zone is supplied as argument to the push_back function, it is passed by value. A temporary copy of the zone is created by the DLZone copy constructor. The following lines from the DLZone copy constructor should be removed as both the zonePage and parentZone of the temporary zone copy are not initialized yet when invoking the copy constructor. They should be placed in DLZone copy member function though, to prohibit resetting an existing zone by simply doing equality assignment.

else if (zonePage != NULL)
{
throw DLException(DL_PARAMETERS_EXCEPTION, "<DLZone::=()> It is illegal to invoke copy function to reset a zone with an already initialized DLPage*s!", __FILE__, __LINE__);
}

else if (parentZone != NULL)
{
throw DLException(DL_PARAMETERS_EXCEPTION, "<DLZone::=()> It is illegal to invoke copy function to reset a zone with an already initialized parent zone pointer!", __FILE__, __LINE__);
}
zhugy   
02-22-06 13:24   
The bug is resolved
zhugy   
02-22-06 13:25   
The modification is checked into CVS server.




Viewing Bug Advanced Details
570 DLImage feature always 01-17-06 16:31 02-22-06 13:06
meyers_tim  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
Update Documentation for DLJPEGImage::dlIsImgCorrupted()
The documentation for DLJPEGImage::dlIsImgCorrupted() is apparently misleading in how it describes the purpose of the function. Please update to clearly reflect that it detects it is simply a report on whether or not libjpeg performed error correction during load.
Additionally, gawarho is reporting that this function is returning conflicting values when an image is loaded via memory as opposed to file-based.
Bug Notes
chen_kevin   
02-09-06 10:34   
Added documentation:

/**
* Indicates if the image was considered corrupted upon loading.
* Each image object will have it’s own error recovery/correction
* algorithm when loading an image. Look at image objects for more details.
* \return bool
*/
bool isImageCorrupted();
chen_kevin   
02-09-06 10:37   
Tim,

The load for memory/file-based for JPEG is the same piece of code. Can you verify with gawarho (Glen?) if this problem still exist?

-Kevin
meyers_tim   
02-22-06 13:06   
Documentation has been fixed. The conflicting values no longer seem to be a problem, but the method is not getting regular use so it may occur later.




Viewing Bug Advanced Details
594 DLImage crash always 02-20-06 09:44 02-22-06 11:50
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DLIMage crashes when opening an image
It appears that when DLImage attempts to open a .png image it crashes in DLDIS image routines. The image displays with the ImageMagick display command with no error/warning messages.
See ~gawarho/### for the code, build and run scripts and a pointer to the image causing the problem.
Bug Notes
meyers_tim   
02-22-06 11:50   
Fixed and reinstalled internally. A relink should solve the issue.




Viewing Bug Advanced Details
578 DLComponent feature always 01-31-06 13:08 02-17-06 13:04
mirekg  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
addon template needs updating????
I was going to use templateDOCLIB as a starting point for an add-on, however, I notice it only has src and doc directories. Shouldn't it have windows, linux and their associated subdirectories as well?
Bug Notes
meyers_tim   
01-31-06 14:17   
The windows and linux subdirectories are created during the creation of a project file (on windows) and compilation (on linux).
meyers_tim   
01-31-06 15:15   
Kevin, is the Windows directory missing / need to be added? Or a template .Net project file or something?
chen_kevin   
02-17-06 13:04   
Added a windows project for add-on template module




Viewing Bug Advanced Details
541 Doclib Addons feature always 10-10-05 15:12 02-17-06 12:29
gawarho  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Logo Detections prints message when no logo found
It appears tha DLLogoDetect.cpp at line 99 prints to STDOUT or STDERR a message indicating that no logo was found -- instead of using the Logger??????
Bug Notes
chen_kevin   
02-17-06 12:29   
Cout statement has been converted to "throw DLLogoException()"




Viewing Bug Advanced Details
542 Doclib Addons feature always 10-11-05 11:37 02-17-06 12:25
gawarho  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Doclib website needs to provide access to documentation
Need to be able to access documentation for DOCLIB add-ons at the doclib web site -- and preferably have a overall access to doclib and doclib add-ons from one top level page.
Bug Notes
chen_kevin   
10-13-05 13:42   
Added DOCLIB documentation to the DOCLIB release beta 0.12 and 0.13.

Should we provide links to DOCLIB addon APIs? DOCLIB users can not download DOCLIB addons (source & lib) from this website. We can only provide DOCLIB addons to authorized users.
chen_kevin   
02-17-06 12:25   
Will design DOCLIB release download website. Documentation will be available for all authorized users for add-ons




Viewing Bug Advanced Details
585 Doclib Addons crash always 02-10-06 10:54 02-16-06 12:01
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
LogoDetection crashes
I have a program that takes a list of files and then runs logo detection on them. I run various lists of files through and it seems to work fine; however at least one list it fails on the same file. However, if I run just this one file through it does not crash.

DLImage img(file);
DLLogoDetect logoD;
DLZone logoZ = logoD.dlDetectLogo(img);
int score = logoD.dlGetScore();

Purify shows it failing at DLLogoDetect::dlImage2Gray_LogoDetect [DLLOgoDetect.cpp line 300]

I will make a directory with the source code, test files, bld and run scripts in my home directory under the bug tracker # assgined to this report.
Bug Notes
gawarho   
02-10-06 11:26   
I also see that as I process images in the list that has the "bad" image in, I get some Free Memory Writes (FMW) and Array Bounds Write (ABW).

I do not know what image(s) is causing this.
meyers_tim   
02-16-06 12:01   
The FMW/ABW has been fixed. They were related to the same problem. I do not believe fixing them has introduced any artifacts to the algorithm, but it'd be good to keep an eye out nonetheless.

Fix has been implemented on both the internal and external nets.




Viewing Bug Advanced Details
592 DLImage crash always 02-15-06 09:49 02-16-06 11:54
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none 0000593  
none  
DLImage eats up a lot of memory and then Crashes
DLImage eats up a lot of memory and then crashes when opening an image.

See ~gawarho/### for sample code, build and run scripts and a list file with two images that cause the failure.
Bug Notes
gawarho   
02-15-06 09:53   
May be related to 593.




Viewing Bug Advanced Details
593 DLImage major always 02-15-06 09:51 02-16-06 11:53
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DLImage has a memory leak
Purify shows that memory is leaked.
See ~gawarho/### for test code, run and bld scripts, and test file.
Bug Notes
gawarho   
02-15-06 09:52   
May be related to 592.
meyers_tim   
02-15-06 15:23   
Glen, I have been unable to replicate this concern using the code you supplied, as well as using DoclibCommandLine. When I run against this image, Doclib exits gracefully after an exception is thrown. Purify lets me know that a Memory Allocation Failed, and that this was the cause for the exception.
gawarho   
02-15-06 15:58   
Tim,
I specified the wrong file in the run script. I changed it
so you should now get the memory leaked error.
Glen
meyers_tim   
02-16-06 11:53   
resolved on the internal and external nets.




Viewing Bug Advanced Details
588 DLImage minor always 02-13-06 16:06 02-14-06 15:29
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DLSkew::dlDetectSkew gets Array Bounds Reads
I have a program that iterates through a list of filenames creating a DLImage one at a time for each file and then attempts to determine the skew of the image.

Purify shows that it gets Array Bounds Reads (ABRs).
A directory in ~gawarho/### where ### is the bug tracker # contains the sample source code, build script, run script and sample filelist.
Bug Notes
meyers_tim   
02-14-06 15:29   
Bug has been fixed on external and internal nets. DOCLIB reinstalled on internal net.




Viewing Bug Advanced Details
586 Doclib Addons crash always 02-10-06 15:41 02-14-06 13:52
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
Handwritten/Machine Printed id now crashes
This program used to work until just recently (today).

I have some tif's it works on and others it fails. It appears to have issues when it tries to rotate the image inside the addon.
My code is simply

DLImage img;
img.dlLoadImage(filename);
DLMachHandDetect::dlDetecthandMachHw(imt, score, docType); // craps out on this call

See ~gawarho/bug# for sample code, images, etc.
Bug Notes
meyers_tim   
02-14-06 13:52   
fixed on internal and external nets. DOCLIB reinstalled on internal net.




Viewing Bug Advanced Details
587 DLImage crash always 02-13-06 08:53 02-14-06 12:51
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DLImage crashes when loading image from memory
I have another instance of a crash of DLImage
when loading from memory versus a file.
See ~gawarho/### for sample code, build scripts, and run scripts --- where ### is the bug tracker number
Bug Notes
meyers_tim   
02-14-06 12:51   
This bug has been resolved on both the external and internal nets. Doclib has been recompiled and installed on the internal net, so a relink should solve this issue.




Viewing Bug Advanced Details
23 major always 12-17-03 09:47 02-10-06 13:09
jjbran2  
chen_kevin  
high  
resolved  
fixed  
none  
none  
#include-ing standard libraries
When using #include to use standard library code, the latest standard conventions should be used. For example, use
#include <iostream>
but not
#include <iostream.h>
In addition, when including old-style C libraries, use
#include <cstdlib>
instead of
#include <stdlib.h>
Eventually, the ".h" standard libraries will no longer work as they will be removed from future compilers.

Especially important is to determine which string library you mean to use-- <cstring> is much different from <string>, and <string.h> means different things on different systems.

Thanks,
Josef
Bug Notes
jjbran2   
01-05-04 11:27   
Some locations where I've observed this:
DLImage.cpp
DLConnectedComponents.cpp
DLException.h
chen_kevin   
05-11-04 13:09   
Changed C includes to C++ includes

<stdlib.h> to <cstdlib>
<stdio.h> to <cstdio>
<math.h> to < cmath>
jjbran2   
07-29-05 11:52   
Found some new ones:

DLFileBasedIO uses #include <stdio.h>

DLSkew and DLTypes use #include <math.h>
chen_kevin   
02-10-06 13:09   
Removed remaining "c" includes form DOCLIB




Viewing Bug Advanced Details
526 DLImage major always 09-08-05 12:51 02-10-06 12:42
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
dlPasteImage for binary images modifies target image past subimage boundaries
When using DLImage::dlPasteImage() to paste a binary subimage into a binary target image, if the subimage's width is not divisible by 8, the function will mistakenly overwrite part of the target image to the right of the pasted region. Since the current dlPasteImage() just copies bytes to bytes, it must be modified to only copy the correct number of bits for the last byte in the row.

In addition, this function does not calculate the correct starting column coordinate for the paste for binary images.
See the attached images for an example. The source image is the one with the diagonal stripe pattern (pattern.tif). The paste image is an 83x83 all-white binary image (white83x83.tif). The output from image.dlPasteInImage(subimage,50,50) is in qqq.tif. Note that while it is correctly pasted in row 50, the paste incorrectly begins in column 136. Also note the addition of the black border, 5 pixels wide, to the right of the pasted region.
0000526-pattern.tif (12 KB) 12-31-69 19:33
0000526-white83x83.tif (0 KB) 12-31-69 19:33
0000526-qqq.tif (7 KB) 12-31-69 19:33
0000526-result.tif (7 KB) 12-31-69 19:33
Bug Notes
admin   
12-05-05 15:48   
Kevin, please confirm that this has been fixed and resolve this bug. Thanks
chen_kevin   
02-10-06 12:42   
Correct the start and end calculation when pasting BW images. Result.tif is the output image.




Viewing Bug Advanced Details
584 DLImage feature always 02-09-06 13:05 02-09-06 15:52
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
dlGetColorModel return code discrepancy
I call this method on an pbm image with only 0 & 255 values in its color map and it returns 0 which is not defined by the possible values in DLColorTypes.
See reporter for more information.
Bug Notes
gawarho   
02-09-06 13:20   
On some formats (BMP & PBM) of images Doclib does not appear to set the ColorModel.
meyers_tim   
02-09-06 15:52   
This bug has been fixed on both the internal and external nets for PBM




Viewing Bug Advanced Details
581 DLImage block always 02-07-06 18:31 02-09-06 15:50
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
Memory Leak
I have a program that simply creates a DLImage from a memory based array of bytes.

When I run JPEGs through everything appears fine. Program runs continuously over a list of JPEGs -- no crashes, no process size growth.

Using the same program but giving it a list of TIFF images, and it eats up memory very quickly until the system runs out.
Program and list of files available from reporter.

Program is simple:
foreach file in list
read file into buffer
img = new DLImage(bufferPtr, bufferLength);
delete img;
delete [] buffer;
end foreach

Bug Notes
gawarho   
02-07-06 18:40   
See reporters home directory and then a subdirectory named with the bug report # for sample code and list files.
gawarho   
02-08-06 07:28   
Another note: I made a change to the file to call new DLImage(filename) and it works with no memory leak on JPGs and TIFFs.

Thus the problem is just with doing new DLImage(dataPtr, dataLength) when the data buffer has a TIFF image.
meyers_tim   
02-09-06 15:50   
This bug has been fixed on both the internal and external nets.




Viewing Bug Advanced Details
516 DLShape trivial always 08-08-05 16:49 02-08-06 17:29
jjbran2  
chen_kevin  
low  
resolved  
fixed  
none  
none  
two data members fillShape and fillFlag appear to be redundant
There are two boolean data members in DLShape:
fillShape and fillFlag. Only fillShape is now in use, checked by DLRectShape to see if it should draw a filled rectangle. We should remove one or the other.
Bug Notes
jjbran2   
08-08-05 16:51   
In addition, if you set a fill color, the fill flag is automatically set as well. There should be a way to unset the fill flag, too.
chen_kevin   
02-08-06 17:29   
FillFlag has been removed since 0.13




Viewing Bug Advanced Details
558 DLImage feature always 11-28-05 14:09 02-08-06 17:26
meyers_tim  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
DLImage = operator not handling tag copying correctly
When using = to set a DLImage to another DLImage, the contents of the DLTagList are not making the crossover.
Bug Notes
chen_kevin   
02-01-06 11:18   
need copy operator for DLTagList
chen_kevin   
02-08-06 17:26   
added copy operator to DLTagList




Viewing Bug Advanced Details
527 DLImage trivial always 09-08-05 14:03 02-08-06 17:17
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
dlAddImage could take a const reference
Right now, DLImage::dlAddImage() has the signature
(DLImage&, int, int). It could instead take a const reference, making the function
dlAddImage(const DLImage& , int, int)
allowing for one liners such as

DLImage i3 = i1.dlAddImage(i2.dlReverseImage(), 0, 0);
this also applies to dlPasteImage() and dlSubtractImage()
Bug Notes
chen_kevin   
02-08-06 17:17   
old APIs:

dlSubtractImage(DLImage& aImg, int xcoor, int ycoor) const
dlAddImage(DLImage& aImg, int xcoor, int ycoor) const

New APIs:

dlSubtractImage(const DLImage& aImg, int xcoor, int ycoor) const
dlAddImage(const DLImage& aImg, int xcoor, int ycoor) const




Viewing Bug Advanced Details
583 DLComponent feature always 02-08-06 16:57 02-08-06 17:09
chen_kevin  
chen_kevin  
normal  
resolved  
fixed  
none 0000515  
none  
DLShape - Want variable line thickness
Desired an option to set the line thickness when drawing lines and shapes.
Bug Notes
chen_kevin   
02-08-06 17:09   
Look at bug 515




Viewing Bug Advanced Details
500 Other feature always 07-25-05 15:39 02-08-06 16:56
mirekg  
chen_kevin  
high  
resolved  
fixed  
none  
none  
Modifications needed to doxyfile settings
I just modified the doxygen setting for the jargon add-on to force doxygen to include entries for those items that do not have comments and to include source code cross references. The doxyfiles for all add-ons, doclib itself, and the template on the website should be updated in the same way. Even if we have not had time to write documentation it is useful to see a complete list of classes/methods in the doxygen documenation. This should be done prior to release 13.
Bug Notes
chen_kevin   
02-08-06 16:56   
DOCLIB version 0.13 has a standard doxyfile for DOCLIB and addons.




Viewing Bug Advanced Details
262 DLDocument feature always 09-23-04 08:39 02-08-06 16:46
zhugy  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Text line extraction function from document image
This text line extraction function includes three key steps: fine global deskewing, horizontal projection for locating the line spacing and vertical projection for recognizing the head and tail on each line.
Keep in mind that while GETLINES does not perform deskewing, it does detect the locations of text lines in a document image. GETLINES (or DLGetLines?) was checked in
CVS around August 9, 2004.
Bug Notes
sdsampa   
10-26-04 10:33   
please resolve this bug if it has been implemented, tested, and checked into CVS.
meyers_tim   
02-06-06 17:22   
Kevin, do you have any idea if this has been implemented, tested, and checked into CVS? I would tend to believe this was taken care of a long time ago, as it looks like back around this time, UMD liked to add Bug Tickets as a way of announcing new features that were already added.




Viewing Bug Advanced Details
337 DLConnectedComponent feature always 01-27-05 16:54 02-08-06 16:39
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Interface for accessing individual DLComponents from DLConnectedComponent object
Currently, the only thing you can really do with the DLConnectedComponents object is run filters; we use the two dlGet...Comp() functions to return copies of the DLComponent's in a vector. This is fine for most uses, but perhaps inefficient to make copies of each if you just want to get the stats on them using the dlGet functions.

Perhaps we could provide a function that returns a const_iterator to the vector of DLComponents that you would use as shown below in "Additional Info". Also needed would be something like begin() and end() functions so one could loop along all components.
cc.dlCreateConnectedComponents(image);
comp_iterator ii = cc.getComponentIterator();

ii++ etc.

ii->dlGetArea(); and so on.
Bug Notes
chen_kevin   
05-26-05 09:34   
/**
* DLCompIterator is an iterator class to help terverses through
* through the DLComponent vector. The DLCompIterator provides
* ways without having knowledge of the internals of the DLComponent class.
*
* All the public functions of DLComponent has been wrapped into
* the DLCompIterator object. User should only need to interact with the
* DLCompIterator object to access all DLComponent information.
*
*
* Example:
*
* try{
* DLImage bwImage("..\\..\\..\\data\\testImages\\ann-052_1bit.tif");
* DLImage colorImg = DLBitsPerPixelConverter::dlBinary2Color(bwImage);
* DLImage outImage(colorImg.dlGetWidth(), colorImg.dlGetHeight(), DL_BITDEPTH_24, true);
*
* DLConnectedComponents cc;
* cc.dlCreateConnectedComponents(bwImage);
*
* cc.dlFilterCCHeightBetween(200, 500);
*
* DLCompIterator compItr = cc.dlGetFilteredComponentIterator();
* //Or
* // DLCompIterator compItr = cc.dlGetFilteredComponentIterator();
*
* while(compItr.dlIsValidComponent())
* {
* cout << idx << endl;
* DLRectShape rect(compItr.dlGetColMin(), compItr.dlGetRowMin(),
* compItr.dlGetColMax() - compItr.dlGetColMin() + 1,
* compItr.dlGetRowMax() - compItr.dlGetRowMin() + 1);
*
* rect.dlDrawShape(&colorImg);
* compItr++;
* }
*
* colorImg.dlSaveImage("c:\\temp\\out\\colorCC2.tif");
*
* } catch (DLException &E) {
* cout << E.DlGetErrMsg() << endl;
*
* }
*/
jjbran2   
09-13-05 18:57   
we should make sure to implement a few more of the functions people will expected to have access to for iterators. we already have the preincrement (i.e. ++i)
but still need

postincrement (i++)
predecrement (--i)
postdecrement (i--)

also, the implementation of these functions, as well as the fiterator constructor, should be moved out to the .cpp file.

edited on: 09-13-05 19:10
meyers_tim   
02-06-06 18:10   
Josef, is this still an issue? It does not look like the DLCompIterator construct exists in DOCLIB anymore.
chen_kevin   
02-08-06 16:39   
DLCompIterator no longer exist




Viewing Bug Advanced Details
260 DLImage feature always 09-22-04 19:54 02-06-06 17:19
zhugy  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
Hough transform class for straight line
The DLHoughTransform object represents the normalized accumulator bins of straight lines in the parameter space. It is a grayscale and derived from DLImage. Its member functions include global Hough transform and local Hough transform.

Line features from image can be extracted by Hough transform member functions.
Bug Notes
meyers_tim   
02-06-06 17:19   
DLHoughTransform is part of Core DOCLIB. For more information see its documentation.




Viewing Bug Advanced Details
261 DLDocument feature always 09-22-04 20:30 02-06-06 17:18
zhugy  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
DLDocumentTagList class as container of document attributes
The DLDocumentTagList object is a container of document attributes.
0000261-DLDocumentTagList.h (2 KB) 12-31-69 19:33
Bug Notes
zhugy   
11-17-04 20:04   
This old version of DLDocumentTagList has been replaced by DLTagList
meyers_tim   
02-06-06 17:18   
This has been replaced by DLTagList




Viewing Bug Advanced Details
259 DLDocument feature always 09-22-04 19:50 02-06-06 17:17
zhugy  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
DLZone implementation
DLZone is a logic container for a segment of a DLPage object. Its members include a protected DLImage pointer, an extensible list of DLZone attributes, coordinates of the DLZone within the DLPage, and a list of child DLZones that can be located within the current DLZone.
0000259-DLZone.h (8 KB) 12-31-69 19:33
Bug Notes
zhugy   
11-17-04 20:08   
The DLZone class is a general container for objects on a document page. This is a completely revised version.
meyers_tim   
02-06-06 17:17   
Because DLZone has been part of DOCLIB for such a long time, I'm going to go ahead and resolve this bug.




Viewing Bug Advanced Details
297 DLDocument feature always 11-17-04 20:12 02-06-06 17:17
zhugy  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
DLDocument implementation
The DLDocument class is the uppermost level in the DocLib document hierarchy.
0000297-DLDocument.h (3 KB) 12-31-69 19:33
Bug Notes
meyers_tim   
02-06-06 17:17   
Because DLDocument has been part of DOCLIB for such a long time, I'm going to go ahead and resolve this bug.




Viewing Bug Advanced Details
299 DLDocument feature always 11-29-04 17:17 02-06-06 17:16
zhugy  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
Command line DLDocument batch test
We have developed a command line DLDocument batch test for testing the efficiency and robustness of the new DLDocument designs. Different from the regression test that focuses on the accuracy on DLImage related operations, DLDocument batch test is intended for exhaustive high-workload test for a big pool of images. It is capable of recording running time on each task and catching all the known exceptions in an output file specified.

The batch test makes use of the DLTestManager and DLTest objects developed earlier. Users create a test case by adding a new DLTest to the DLTestManager, which handles exceptions and output. We can have multiple test cases running in sequence.

Overload the virtual function DLTest::go() by your own code for batch test. You can refer to the DLDocumentBatchTest.cpp in the project as a batch test template, where the sections to insert your own code is highlighted.
Bug Notes
meyers_tim   
02-06-06 17:16   
The code for this is present in CVS in the doclib/src directory.




Viewing Bug Advanced Details
296 DLDocument feature always 11-17-04 20:06 02-06-06 17:14
zhugy  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
DLTagList replaces the old DLDocumentTagList
The DLTagList object is a container of document attributes. This revised version replaces the old DLDocumentTagList.
0000296-DLTagList.h (2 KB) 12-31-69 19:33
Bug Notes
meyers_tim   
12-19-05 10:49   
Can this be closed?
meyers_tim   
02-06-06 17:14   
This has been integrated with DOCLIB. More information can be found in its documentation and its source can be obtained in CVS.




Viewing Bug Advanced Details
258 DLDocument feature always 09-22-04 19:44 02-06-06 17:13
zhugy  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
DLPage implementation
DLPage is a new object that serves as a basic logic container for single-page document image processing. Included within each DLPage object are a protected DLImage member, an extensible list of DLPage attributes, and a list of DLZones which represent the segments on the DLPage.

DLPage constructor function encapsulates the document segmentation functions. Upon declaration, the list of DLZones (root zones) on the page are populated by the located segments. Lines of text within this list of root zones on the DLPage can be extracted and stored within the child zones following a tree hierarchy.
0000258-DLPage.h (3 KB) 12-31-69 19:33
Bug Notes
zhugy   
11-17-04 20:09   
The DLPage class represents the logical content of a document page. This is a completely revised version.
meyers_tim   
12-19-05 10:50   
Can this be closed?
meyers_tim   
02-06-06 17:13   
Because DLPage has been part of DOCLIB for such a long time, I'm going to go ahead and resolve this bug.




Viewing Bug Advanced Details
422 Other feature always 04-20-05 15:48 02-06-06 16:30
liyi  
meyers_tim  
normal  
resolved  
not a bug  
none  
none  
DLxml is a class whose input is DLDocument and output is xml tree.
DLxml is a class whose input is DLDocument and output is xml tree.

It works for multiple page but page need to be segmented using some add-ons before input to this class

Constructor:
DLxml( DLDocument dlDoc, DLTagList dlTaglist )

xml tree is generated in constructor, and could be saved by using
DLxml::dlSaveToXmlFile( string filename )

This add-on is checked out to cvs server
Bug Notes
chen_kevin   
04-22-05 09:40   
Yi,

DLxml needs to be checked into CVS.

-Kevin
meyers_tim   
02-06-06 16:30   
It is my understanding that DLXML is a UMD add-on that has already been created and is being used.




Viewing Bug Advanced Details
300 DLDocument feature always 11-30-04 15:41 02-06-06 16:28
liyi  
meyers_tim  
normal  
resolved  
duplicate  
none 0000422  
none  
A class for generating simple XML tree
This is a class for generating XML tag file. Currently it only supports a small subset of XML standard (only attributes, data and nodes) and cross platform and is implemented using STL. User can load/save a XML tag file, traverse XML tree, and add/delete nodes, add/modify/delte attributes.
This class has a private member (type: string), whose content is the XML tree. A pointer to the start tag of current nodes is elaboratly maintained when users travel this tree. A example is also included.

This class is not included in current version of Doclib.
0000300-XML.zip (5 KB) 12-31-69 19:33
There are no notes attached to this bug.




Viewing Bug Advanced Details
572 DLComponent feature always 01-23-06 10:20 02-06-06 14:54
mirekg  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
Clarify documentation on depth
Where image depth is a parameter (e.g. DLImage) the documentation needs to specify the valid range/parameters for the depth. The user should be pointed to the DL_ constants that should be used.
Bug Notes
chen_kevin   
02-01-06 11:00   
Lynn, Please provide example
mirekg   
02-01-06 12:53   
I poked around and it looks like this has been done. At one point I was looking at documentation that did not spell out the valid "depths".
meyers_tim   
02-06-06 14:45   
It appears this has been taken care of.




Viewing Bug Advanced Details
579 DLImage major always 02-02-06 07:53 02-06-06 11:13
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none 0000544  
none  
Do not get sames results
When resizing an image via a C++ program versus a Java using JNI program, the resulting images are not bit for bit equal.
See reporter for more information. Lynn and Tim have been informed of the problem already.
Bug Notes
meyers_tim   
02-06-06 11:13   
See Bug 544. This is an issue with the Java Virtual Machine and its interpretation of floating point numbers.




Viewing Bug Advanced Details
580 Doclib Addons major always 02-02-06 09:33 02-06-06 11:13
gawarho  
meyers_tim  
normal  
resolved  
duplicate  
none 0000544  
none  
Handwritten/Machine Print does not get same results
When resizing an image via a C++ program versus a Java using JNI program, the program does not report the sames results.
See reporter for more information.
Bug Notes
meyers_tim   
02-06-06 11:13   
See Bug 544. This is an issue with the Java Virtual Machine and its interpretation of floating point numbers.




Viewing Bug Advanced Details
573 DLImage minor always 01-24-06 11:10 02-03-06 12:28
meyers_tim  
meyers_tim  
low  
resolved  
fixed  
none  
none  
dlGetChannels() does not return a DLColorType
Several times in DLBitsPerPixelConverter.cpp the following two lines make an appearance:

int numBytesPerPix = tImg.dlGetChannels()
if(numBytesPerPix == DL_BINARY) {...}

This is logically incorrect in spite of the fact that it works correctly; its like comparing apples to oranges and not getting yelled at because they are both fruits.

The problem is this:

dlGetChannels() returns the number (integer) of image data channels "usually 3 for 24-bit color RGB images, and 1 for binary, grayscale or palettized images"

DL_BINARY is an enumerated value of DLColorTypes with the constant value of 1. Because DL_BINARY is an integer, compilers won't yell, and the correct answer is being given without the right question being asked.

Essentially, the original coder wanted to ask the question "Is this image a 24-bit color RGB image?", but the way it is written, it appears that the question is "Is this a binary image?" But what someone trying to interpret the code will not realize is that DL_BINARY, when used incorrectly in this instance, actually means "binary, grayscale or palettized images".
Bug Notes
meyers_tim   
02-03-06 12:28   
I have fixed the occurrences of this problem in DLBitsPerPixelConverter.cpp




Viewing Bug Advanced Details
517 DLMorphology minor always 08-10-05 17:51 02-01-06 11:36
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none 0000575  
none  
DLMorphology operations don't copy DLImage header
The various DLMorphology operations do not copy the DLImage's header to the new output DLImage. Therefore things like the image's resolution values are not transferred to the new image.
Bug Notes
jjbran2   
08-12-05 12:59   
We should check any function that returns a new DLImage, such as those in DLBitsPerPixelConverter and several in DLImage itself.

Also, the colormodel flag seems to suffer from this more than the others, please pay special attention to colormodel.
chen_kevin   
02-01-06 11:36   
Please look at bug 575




Viewing Bug Advanced Details
511 DLLogger crash always 08-02-05 11:47 02-01-06 11:30
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
segfault in DLLogger caused by uninitialized output file name
If I do

dlLogger.dlSetLogType(DL_FILEOUT);

without a file name, a segfault is caused by the attempted write to the uninitialized FILE * logOutstream.

I suggest that if you set the log type to DL_FILEOUT that you either give a default log file name or throw an exception if you don't provide a file name.

Furthermore, there should be no essential difference between output to a file and output to standard out/error -- they are both available as streams in the C++ standard library. We should consider replacing the FILE* type calls with stream calls and find a way to convert the printf style command into stream output.
Bug Notes
chen_kevin   
08-26-05 11:12   
Added error check in dlSetLogType() when setting DL_FILEOUT without a file name. Changing the FILE* to c++ stream still remains an issue. Currently, we have a variable paramater dlLog(...) which is only works with prinf. Need to resolve this issue before we can fully change over to c++ stream.
jjbran2   
08-26-05 11:43   
One idea: we could pass that version of dlLog(...) to sprintf, and then dump the string to whichever stream was desired. Not necessary to do this right away...
chen_kevin   
02-01-06 11:30   
Changed dlSetLogType(logtype) to dlSetLogType(logType, logFile)




Viewing Bug Advanced Details
444 DLDocument feature always 05-19-05 15:31 02-01-06 11:22
chen_kevin  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
DLPage, DLDocument, DLZone Forward ref error
We are getting compilation errors with forward referencing issues in DLPage, DLDocument and DLZone using Visual.net c++ 2002 version 7.0 . We will need to resolve this issue because our clients are using the lower version of .net c++ (We are using .net 2003 V 7.1). I have tried to find a solution to this problem but that involves the knowledge of the the DLDocument design.

One thing that might be causing this problem is in the "list<DLZone/DLPage/DLDocument> name" variable. You must have DLZone as a list of pointers because of the forward referencing of DLZone (list <DLZone*> name)
Bug Notes
meyers_tim   
10-03-05 16:47   
Can this be closed now?




Viewing Bug Advanced Details
334 DLComponent feature always 01-25-05 12:31 02-01-06 11:09
mirekg  
chen_kevin  
normal  
resolved  
fixed  
none 0000324  
none  
need to get rid of image size limit for gif
Right now there seems to be a restriction on the size of a gif image (width and height). This is probably a legacy limitation from eyepoke. If the height/width exceeds the limit the reader exits.
Looking into replacing the GIF object with Phill's Gif object .
There are no notes attached to this bug.




Viewing Bug Advanced Details
512 DLImage tweak always 08-05-05 09:21 02-01-06 11:07
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none 0000334  
none  
can DLGIFImage::dlConvertStructToDLImage() be made private/protected?
can DLGIFImage::dlConvertStructToDLImage() be made private/protected?

also, can the class definitions

class DLLocalGIFImage;
class DLGlobalGIFImage;

be made protected/private?
Bug Notes
chen_kevin   
02-01-06 11:07   
Looking to replace the current GIF object with Phil's GIF object.




Viewing Bug Advanced Details
540 DLImage tweak always 10-07-05 13:25 02-01-06 11:05
meyers_tim  
chen_kevin  
normal  
resolved  
fixed  
none 0000334  
none  
DLGIFUtilities error reporting
Currently, DLGIFUtilities does not throw exceptions, it simply returns a 0 when something goes wrong and relies on DLGIFImage to say "error in DLGIFUtilities". This however is quite vague. I feel that DLGIFUtilities should be updated to throw Exceptions instead of returning 0 whenever an error occurs.
There are no notes attached to this bug.




Viewing Bug Advanced Details
569 DLImage feature always 01-12-06 17:31 02-01-06 11:03
gawarho  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
New ability to access library version #
It would be great to be able to have a standard call to DOCLIB and its addons to retrieve a text string of the version number and possibly release date.

If nothing else this information could simply be retrieved by doing a strings command piped to grep to get the version # of the libraries.
Bug Notes
chen_kevin   
02-01-06 11:03   
To access DOCLIB version number,

#include "DLVersions.h"
cout << DL_VERSION;




Viewing Bug Advanced Details
576 DLComponent major unable to duplicate 01-30-06 15:18 01-31-06 10:57
mirekg  
meyers_tim  
normal  
resolved  
unable to duplicate  
none  
none  
unable to open jpeg file
I tried to use DoclibCommandLine to convert one of the cedar image (054a.jpg) to tiff. I get error messages and the image does not convert correctly. Command I am using in DoclibCommandLine -input 054a.jpg -output test.tif
Bug Notes
chen_kevin   
01-31-06 10:08   
I have tested "DoclibCommandLine -input 054a.jpg -output test.tif" with the latest DOCLIB code and worked fine. Please attach your version of the test image.
meyers_tim   
01-31-06 10:52   
I have tested using the internal copy of the image provided and it worked fine for me.

edited on: 01-31-06 10:53
meyers_tim   
01-31-06 10:57   
This issue appears to have fixed itself after a clean build of doclib




Viewing Bug Advanced Details
506 Other major always 07-29-05 11:44 01-31-06 10:26
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
naming of certain data types, structs, classes could conflict with other libraries
We have made a good attempt at creating unique names for our Doclib classes; our naming convention that requires each class name to start with DL... makes it unlikely that we will have a name collision with other libraries that a DOCLIB user might be programming with.

However, there are many types, structs, classes and #defines still lying around that have names that are too generic and could cause collisions.

The worst offenders are in DLCcConst.h, which I realize got dragged in with the TWOBIT connected component code. This will be the toughest to tease out but it will be worth it.

Here is a list we should fix:

in DLBitsPerPixelConverter.h:
enum BINARIZE_TYPE

in DLCcConst.h:
#define round <--- really bad
#define Setarr(a,n,y,v)
#define Malloc(w,x,y,z)
#define Calloc(w,x,y,z)
#define Realloc(w,x,inc,y,z)
#define Swap(a,b,t)
#define retMaxVal
#define retMinVal
Other #defines should be redone as const static int, etc.

in DLConst.h:
#define DL_MAX
#define DL_MIN
enum ColorTypes
enum BWColors
const static int PPM_MAX_LINE_LENGTH
const static char * DIR_SEPARATOR

in DLGIFImage.h:
many #defines should be redone as const static

in DLGIFUtilities.h:
struct LZWtable
struct image_format

in DLImageFactory.h:
struct ltstr

in DLIOStream.h:
enum Endian

in DLPoint.h:
struct POINTLIST (by the way, consider using STL's list<DLPoint> for this!)

in DLSkeleton.h:
#define MATRIX_SIZE

in DLTypes.h:
#defines: some should be eliminated, some should be typedefs, some should be functions

in mfs_file.h:
I realize this is from an outside source, but we should find a way to get rid of some of the worse #defines like #define TRUE.


we should never need to #define a min(x,y), max(x,y) or swap(x,y) function. These are now part of the standard library and are found in #include <algorithm>.
Bug Notes
jjbran2   
07-29-05 11:48   
Much of these can be fixed by adding on the "DL" prefix.

We should also consider moving class-specific typedefs inside their class definitions. Example: enum BINARIZE_TYPE could be moved inside DLBitsPerPixelConverter, and would then not even be required to have the DL prefix.

That would be clearly best for things like struct ltstr in DLImageFactory and enum ENDIAN in DLIOStream, which are internal function objects or data types only used by the class for internal processing.
jjbran2   
07-29-05 11:51   
Reminder sent to chen_kevin, mirekg, sdsampa

please take a look at this one, not for this release, but it should be the next thing we tackle.

Anyone making addons they want to be distributed with Doclib should particularly be made aware of these issues when they are naming things in their software.
meyers_tim   
01-30-06 13:52   
Much of this has been taken care of. Kevin - confirm?
chen_kevin   
01-31-06 10:26   
All #defines has been removed except for dlRealloc() and dlSetarr() used by DLConnectedComponents. Will be removed when DLConnectedComponents is designed to take out TB code.




Viewing Bug Advanced Details
275 Other feature always 10-18-04 16:36 01-31-06 10:11
mirekg  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Reading of gif images is slow
In doing some profiling of a doclib application I observed that reading gif images is taking a significantly longer time than reading tif images. Much time is being spent in the DLGIFUtilities::initialize_LZW_table routine. It is in fact being called numerous times. It needs to be examined for efficiency and we should investigate whether this or any other tables needed by the gif reader can be included as static data areas in doclib, rather then being created.
Bug Notes
sdsampa   
11-29-04 12:08   
I did my benchmarking on Car_8bit_rotate_30degree.gif which is a 649 KB
file. The benchmark consisted of 1000 load/save operations performed
from a FOR loop in a DOS batch file. By subtracting the time at start
from the time at finish, and dividing by 1000, I determined that the
average load/save opeation took 447ms. After code changes, the
benchmark test took 262ms. This is a speed up of 170%.

Also, I replaced all printf and cout statements with dlLogger and
migrated all C structs into C++ classes. More static methods of the
DLGIFUtilities Class could be moved into the new classes.
sdsampa   
12-06-04 18:08   
problems with loading binary and grayscale images was found. Had to roll-back to previous version. Must revisit to rectify.
chen_kevin   
01-31-06 10:11   
looking into redesign of GIF object




Viewing Bug Advanced Details
568 DLImage major always 01-12-06 16:52 01-25-06 10:30
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
dlResizeImage does not produce the same results as in previous version
I use dlResizeImage to build thumbnails. The results of the same program I use just relinked with the latest version of DOCLIB, generates thumbnails that do not look like the thumbnails generated previously.
See reporter for sample files, source code and binaries of the two programs (linked to different versions of DOCLIB).
Bug Notes
meyers_tim   
01-25-06 10:30   
I've reverted the algorithm on the internal net, so the same results should come out now. In the future, we may offer multiple options with regard to resizing algorithms.




Viewing Bug Advanced Details
571 DLImage major always 01-19-06 15:48 01-25-06 10:28
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
dlDownscaleColor2Binary
I did not see a bug entry for this error -- I have talked with the DOCLIB developers and wanted to make sure that it does not slip through the cracks.

When using dlDownscaleColor2Binary, I get images with horizontal staggered lines in my output image.
See reporter for code and test image(s).
Bug Notes
meyers_tim   
01-25-06 10:28   
This issue has been fixed on the internal net. It was due to a calculation error in dlDownscaleGray2Binary_global.




Viewing Bug Advanced Details
567 DLImage block always 01-12-06 12:58 01-24-06 10:05
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none 0000552  
none  
File and memory load yields different results
When I use DLImage(filename) the image loads and creates a DLImage. When I use DLImage(dataPtr, dataLength) or DLImage(dataPtr, dataLength, DLBaseImagePtr), the image does not load in a DLImage object.
I thought that using the appropriate DLBaseImage pointer in the creation of a DLImage would have effectively been the same as DLImage(filename).

When trying the memory based creation of DLIMage, I get the followign message:

Exception:DLJPGImage.cpp:477: <DLJPGImage::dlLoadImage()> Decompression Error!

Please see reporter for sample images, source code, etc.
Bug Notes
meyers_tim   
01-17-06 13:01   
Is this a duplicate of Bug 552 that is being replicated due to use of an old version of DOCLIB?
meyers_tim   
01-24-06 10:05   
The fix implemented for bug 552 was never checked in, therefore the same problem was occuring in the installed binaries.




Viewing Bug Advanced Details
566 DLImage major always 01-11-06 14:05 01-17-06 16:16
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
Downscaling from color to binary fails
After to upgrading to the newset version of DOCLIB, 0.13B,
my program that used to convert from color to binary or from gray to binary does not produce the same results. In one case the image is blank and in some cases it just has short horizontal lines. In all cases the image converted properly when using the older version of DOCLIB
See bug reporter at customer site for more information, sourc code and same images if needed.
Bug Notes
meyers_tim   
01-17-06 16:16   
This appears to be an artifact of version mismatching, and has since been resolved with a new installation of DOCLIB on 1/17/06




Viewing Bug Advanced Details
565 Doclib Addons major always 01-10-06 10:40 01-12-06 15:32
gawarho  
meyers_tim  
normal  
resolved  
duplicate  
none 0000564  
none  
No documentation for document Id algorithm
There is no Doxygen documentation for the Document Id algorithm.
Bug Notes
gawarho   
01-10-06 10:41   
This is a duplicate of 564 -- accidentally clicked twice when I submitted 564.




Viewing Bug Advanced Details
417 Other minor have not tried 03-24-05 12:29 12-29-05 08:40
amsakak  
mirekg  
normal  
resolved  
fixed  
none  
none  
ld: warning: file libtiff.so: section .stabstr: malformed string table, initial or final byte
When linking into the Tiff library with ld (don't know what ld is), I receive the message
ld: warning: file libtiffl.so: section .stabstr: malformed string table, initial or final byte
This occurs when compiling code that is not part of Doclib but I was told to enter this bug regardless.
Bug Notes
chen_kevin   
12-28-05 11:42   
Saki,

Can you verify this bug if still exist?

-Kevin
amsakak   
12-28-05 15:33   
I entered this bug 8 months ago at Lynn's request. I have no idea what was done to generate the error message. Perhaps Lynn can provide assistance?
mirekg   
12-29-05 08:40   
Unfortunately I don't recall all the details on this (operating system, compiler used, linker used, etc.) but I do recall looking into this and determining it was not a doclib problem. It had something to do with the version of the linker being used.

I asked that a bug be entered so we could capture that knowledge.




Viewing Bug Advanced Details
302 Other minor always 12-03-04 14:43 12-28-05 11:38
chen_kevin  
chen_kevin  
normal  
resolved  
fixed  
none 0000334  
none  
DLGIFImage is always converting other image objects to 24 Bit images when loading.
Need to modify DLGIFImage to load images to the correct color depth (1, 8 and 24 bits). Currently, it is always loads the image to 24 bit color.
Bug Notes
chen_kevin   
12-28-05 11:38   
Looking into replacing the GIF object with Phill's Gif object




Viewing Bug Advanced Details
309 Other trivial always 12-09-04 17:20 12-28-05 11:18
amsakak  
chen_kevin  
low  
resolved  
fixed  
none  
none  
Compilation warning messages for Sunos59 and Linux24
The attachment shows the compilation stderr output when compiling at the customer site on a Sunos59 then a Linux24 machine. Note that the compile flags were set to maximize the warning messages output.

I have the attachment printed out in hardcopy if anyone wants it.
0000309-compilationOutput.txt (148 KB) 12-31-69 19:33
Bug Notes
chen_kevin   
12-28-05 11:18   
Warnings should be removed with Release 0.13




Viewing Bug Advanced Details
290 DLImage feature always 10-28-04 18:17 12-28-05 11:10
mirekg  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
DLImage documentation needs to clarify valid ranges for methods
The documentation(comments) for DLImage need to be beefed up to make it clear what the valid values are for parameters. For example there is a method DLImage(int w, int h, int depth, int data). There is no indication of the valid entries for depth. The documentation should specify DL_BITDEPTH24,etc.

Along the same lines. I did a grep on "24" and see many places where this is hard-coded. Should we be using the doclib constant?
Bug Notes
chen_kevin   
12-28-05 11:10   
Documentation updated with DOCLIB Release 0.13




Viewing Bug Advanced Details
560 Doclib Addons feature N/A 12-15-05 15:18 12-19-05 16:33
amsakak  
amsakak  
normal  
resolved  
fixed  
none  
none  
DoclibTestSuite automated Makefile creation
Tim is creating an add-on called DoclibTestSuite which will be able to test both the core doclib library and the add-ons. Unlike the current regression test, DoclibTestSuite will test a wide variety of situations rather than a limited number of specific ones. This will require some test to be created for each add-on which bears some resemblance to /home/meyers_tim/sandbox/doclib/src/DoclibTestSuite/testDLImageHead.cpp. In order for the DoclibTestSuite binary to run, it needs to know the various add-ons and which have a file equivalent to "testDLImageHead.cpp" which will be used for testing. Ideally, this information should be contained in the Makefile used to compile DoclibTestSuite. The question is, how do we get that information to the Makefile?

Might be able to have an environment variable defined which will contain this information. Then, maybe use the make.pl wrapper script to set values for this variable.

Or, perhaps the DoclibTestSuite Makefile.am file could have something set up to search the various add-ons for the desired information. The latter would be ideal but perhaps more difficult.
0000560-DoclibTestSuiteTemp.tar (340 KB) 12-31-69 19:33
Bug Notes
amsakak   
12-19-05 16:27   
I believe I've come up with a good solution that will work regardless of whether or not DoclibTestSuite is called with the "make.pl" wrapper script or with the "./configure; make clean; make" command lines. The key is to define the desired locations in the "params" file. Suppose we want to know the full path names of all occurrences of the "testDLImageHead.cpp" file in the core doclib and its add-ons. In order to do this, add
setenv TESTFILELIST `find $DOCLIB -name "testDLImageHead.cpp" -exec ls {} \;`
to "DoclibTestSuiteTemp/params." After sourcing "params," the environment variable "TESTFILELIST" will contain the full path names of all occurrences of "testDLImageHead.cpp."

In order to call the contents of "TESTFILELIST" in the makefiles, add
@(for file in $(TESTFILELIST); do ls -l $$file; done)
to "DoclibTestSuiteTemp/src/libDir/Makefile.am." This will loop over all values stored in "TESTFILELLIST," performing an "ls -l" on each. Note that you can call whatever command you want; it doesn't have to be "ls -l."

See and run the attached "DoclibTestSuiteTemp.tar" to view how this actually works. After untarring, store the directory at the same level as the other doclib add-ons. Then replace the original "params" file with the one attached. Source the new "params" file. Next, enter "DoclibTestSuite" to the same level as the "configure" file. Call "./configure; make clean; make" and see how "ls -l" is run on all "testDLImageHead.cpp" files in the same directory as "params" or in directories under it.

Zero in quickly on these two lines that are the meat of the process by searching on "SAKI ADDITION" then look at the line directly above.

This code has been tested with successful results on both Redhat Linux and a Sunos59 operating systems.
amsakak   
12-19-05 16:33   
Let me know if I can be of further assistance.




Viewing Bug Advanced Details
485 Other major always 07-01-05 10:29 12-19-05 10:35
amsakak  
meyers_tim  
high  
resolved  
fixed  
none  
none  
LogoDetectDOCLIB unable to compile
This error has been verified on both Mediaproc and the Dell team laptop.

Making all in LogoDetectTestDriver
make[1]: Entering directory `/home/amsakak/sandbox/LogoDetectDOCLIB/src/LogoDetectTestDriver'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I../LogoDetectLib -I../../../doclib/include -I/home/amsakak/sandbox/doclib/resource/include -I/home/amsakak/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/sandbox/doclib/resource/linux/include/zlib -I/home/amsakak/INSTALL/linux24/include TestLogoDetect.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../LogoDetectLib/DLLogoDetect.h:6,
from TestLogoDetect.cpp:6:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
TestLogoDetect.cpp:128:2: warning: no newline at end of file
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
g++ -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -o LogoDetect_commandLine TestLogoDetect.o -L../../linux24/lib -L../../../doclib/linux24/lib -L/home/amsakak/sandbox/doclib/resource/linux -L/home/amsakak/INSTALL/linux24/lib -lLogoDetectLib -lDoclib -ltiff -ljpeg -lpng -lz -lm
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x1049): In function `DLZone::dlSetZoneWidth(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x11c5): In function `DLZone::dlSetZoneHeight(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
collect2: ld returned 1 exit status
make[1]: *** [LogoDetect_commandLine] Error 1
make[1]: Leaving directory `/home/amsakak/sandbox/LogoDetectDOCLIB/src/LogoDetectTestDriver'
make: *** [all-recursive] Error 1
Bug Notes
amsakak   
07-06-05 09:15   
I just downloaded the most recent doclib and add ons as of July 6, 2005. LogoDetectDOCLIB still does not compile:

Making all in LogoDetectLib
make[1]: Entering directory `/home/amsakak/DOCLIB/sandbox/LogoDetectDOCLIB/src/LogoDetectLib'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I./ -I../../../doclib/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/zlib -I/usr/local/include DLLogoDetect.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from DLLogoDetect.h:6,
from DLLogoDetect.cpp:1:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I./ -I../../../doclib/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/zlib -I/usr/local/include DLLogoException.cpp
ar cru libLogoDetectLib.a DLLogoDetect.o DLLogoException.o
ranlib libLogoDetectLib.a
../../linux24/lib/libLogoDetectLib.a successfully created.
make[1]: Leaving directory `/home/amsakak/DOCLIB/sandbox/LogoDetectDOCLIB/src/LogoDetectLib'
Making all in LogoDetectTestDriver
make[1]: Entering directory `/home/amsakak/DOCLIB/sandbox/LogoDetectDOCLIB/src/LogoDetectTestDriver'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I../LogoDetectLib -I../../../doclib/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/zlib -I/usr/local/include TestLogoDetect.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../LogoDetectLib/DLLogoDetect.h:6,
from TestLogoDetect.cpp:6:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
TestLogoDetect.cpp:128:2: warning: no newline at end of file
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
g++ -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -o LogoDetect_commandLine TestLogoDetect.o -L../../linux24/lib -L../../../doclib/linux24/lib -L/home/amsakak/DOCLIB/sandbox/doclib/resource/linux -L/usr/local/lib -lLogoDetectLib -lDoclib -ltiff -ljpeg -lpng -lz -lm
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x1049): In function `DLZone::dlSetZoneWidth(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x11c5): In function `DLZone::dlSetZoneHeight(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
collect2: ld returned 1 exit status
make[1]: *** [LogoDetect_commandLine] Error 1
make[1]: Leaving directory `/home/amsakak/DOCLIB/sandbox/LogoDetectDOCLIB/src/LogoDetectTestDriver'
make: *** [all-recursive] Error 1
meyers_tim   
12-19-05 10:35   
This was due to some API changes in Doclib Beta v. 0.13. They were resolved before release.




Viewing Bug Advanced Details
487 Other major always 07-01-05 10:34 12-19-05 10:35
amsakak  
meyers_tim  
high  
resolved  
fixed  
none  
none  
PageLayoutDOCLIB unable to compile
This error has been verified on both Mediaproc and the Dell team laptop.

Making all in PageLayoutLib
make[1]: Entering directory `/home/amsakak/sandbox/PageLayoutDOCLIB/src/PageLayoutLib'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I. -I../../../doclib/include -I../../../JargonDOCLIB/src/JargonScriptIDLib -I../../../getLinesDOCLIB/src/getLinesLib -I/home/amsakak/sandbox/doclib/resource/include -I/home/amsakak/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/sandbox/doclib/resource/linux/include/zlib -I/home/amsakak/INSTALL/linux24/include objectInfoClass.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../../../JargonDOCLIB/src/JargonScriptIDLib/JScript.h:7,
from objectInfoClass.h:6,
from objectInfoClass.cpp:10:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
objectInfoClass.cpp: In constructor
`objectInfoClass::objectInfoClass(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, JScript*, int, char*, int,
int, int)':
objectInfoClass.cpp:168: warning: format argument is not a pointer (arg 4)
objectInfoClass.cpp:170: warning: cannot pass objects of non-POD type `struct
std::string' through `...'; call will abort at runtime
objectInfoClass.cpp:170: warning: format argument is not a pointer (arg 4)
objectInfoClass.cpp:406:9: warning: "/*" within comment
objectInfoClass.cpp: In member function `objectInfo*
objectInfoClass::computeObjectInfo(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, int)':
objectInfoClass.cpp:317: warning: unused variable `unsigned char*pixels1'
objectInfoClass.cpp:320: warning: unused variable `unsigned char*newr_image'
objectInfoClass.cpp:322: warning: unused variable `int long_line_count'
objectInfoClass.cpp:323: warning: unused variable `int*iList'
objectInfoClass.cpp:324: warning: unused variable `int*line_segs'
objectInfoClass.cpp:327: warning: unused variable `int big_line_count'
objectInfoClass.cpp:834:9: warning: "/*" within comment
objectInfoClass.cpp:855:9: warning: "/*" within comment
objectInfoClass.cpp: In member function `void
objectInfoClass::computeInterlineSpacingFeatures(DLImage*, DLlineInfo*, int,
float*, float*)':
objectInfoClass.cpp:865: warning: unused variable `int cols'
objectInfoClass.cpp:1140:1: warning: "/*" within comment
objectInfoClass.cpp:1143:1: warning: "/*" within comment
objectInfoClass.cpp: In member function `int
objectInfoClass::tbComputeDCT(double*, int, double**)':
objectInfoClass.cpp:1175: warning: assignment to `unsigned char' from `double'
objectInfoClass.cpp:1175: warning: argument to `unsigned char' from `double'
objectInfoClass.cpp: In member function `void
objectInfoClass::writeG4TiffGray(char*, float*, int)':
objectInfoClass.cpp:718: warning: `double rotation_angle' might be used
uninitialized in this function
objectInfoClass.cpp:722: warning: `DLImage*outImage' might be used
uninitialized in this function
objectInfoClass.cpp: In member function `void
objectInfoClass::writeG4Tiff(char*)':
objectInfoClass.cpp:762: warning: `DLImage*outImage' might be used
uninitialized in this function
../../../doclib/include/DLConnectedComponents.h: At top level:
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
../../../JargonDOCLIB/src/JargonScriptIDLib/JMorphology.h:6: warning: `char
JARGONVERSION[33]' defined but not used
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I. -I../../../doclib/include -I../../../JargonDOCLIB/src/JargonScriptIDLib -I../../../getLinesDOCLIB/src/getLinesLib -I/home/amsakak/sandbox/doclib/resource/include -I/home/amsakak/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/sandbox/doclib/resource/linux/include/zlib -I/home/amsakak/INSTALL/linux24/include objectPairClass.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../../../JargonDOCLIB/src/JargonScriptIDLib/JScript.h:7,
from objectInfoClass.h:6,
from objectPairClass.h:5,
from objectPairClass.cpp:2:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
In file included from objectPairClass.cpp:2:
objectPairClass.h:9:34: ..\utility_hm\Tarray.h: No such file or directory
In file included from objectPairClass.cpp:2:
objectPairClass.h:61: 'CTArray' is used as a type, but is not defined as a
type.
objectPairClass.h: In destructor `objectPairInfo::~objectPairInfo()':
objectPairClass.h:65: `doc_array' undeclared (first use this function)
objectPairClass.h:65: (Each undeclared identifier is reported only once for
each function it appears in.)
objectPairClass.h: In member function `objectPairInfo&
objectPairInfo::operator=(objectPairInfo)':
objectPairClass.h:94: `struct objectPairInfo' has no member named `doc_array'
objectPairClass.h: At global scope:
objectPairClass.h:107: 'CTArray' is used as a type, but is not defined as a
type.
objectPairClass.h: In member function `void pairCluster::Add(int)':
objectPairClass.h:116: `memberlist' undeclared (first use this function)
objectPairClass.h:118: `CTArray' undeclared (first use this function)
objectPairClass.h:118: syntax error before `;' token
objectPairClass.h:121: `tmp' undeclared (first use this function)
objectPairClass.h:209:7: warning: no newline at end of file
objectPairClass.cpp:3:23: polyclass.h: No such file or directory
objectPairClass.cpp: In member function `void
objectPairClass::readDataWithScores(FILE*)':
objectPairClass.cpp:236: warning: int format, objectType arg (arg 3)
objectPairClass.cpp:236: warning: int format, objectType arg (arg 4)
objectPairClass.cpp:236: warning: int format, float arg (arg 7)
objectPairClass.cpp:236: warning: char format, different type arg (arg 19)
objectPairClass.cpp:236: warning: char format, different type arg (arg 20)
objectPairClass.cpp:236: warning: too few arguments for format
objectPairClass.cpp: In constructor `objectPairClass::objectPairClass(const
char*, FILE*)':
objectPairClass.cpp:305: warning: int format, objectType arg (arg 3)
objectPairClass.cpp:305: warning: int format, objectType arg (arg 4)
objectPairClass.cpp:305: warning: int format, float arg (arg 7)
objectPairClass.cpp: In constructor
`objectPairClass::objectPairClass(objectInfo*, int, int, FILE*)':
objectPairClass.cpp:353: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:345: using obsolete binding at `i'
objectPairClass.cpp: In member function `void
objectPairClass::printScoreInfo(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >)':
objectPairClass.cpp:453: warning: int format, double arg (arg 8)
objectPairClass.cpp: In member function `void
objectPairClass::printInfo(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >)':
objectPairClass.cpp:494: warning: int format, double arg (arg 8)
objectPairClass.cpp: In member function `void
objectPairClass::merge(objectPairClass*, int)':
objectPairClass.cpp:728: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:726: using obsolete binding at `i'
objectPairClass.cpp:743: warning: assignment to `int' from `float'
objectPairClass.cpp:743: warning: argument to `int' from `float'
objectPairClass.cpp:764: name lookup of `merged' changed for new ISO `for'
scoping
objectPairClass.cpp:731: using obsolete binding at `merged'
objectPairClass.cpp: In member function `void
objectPairClass::frequencyBasedPrune(int, FILE*)':
objectPairClass.cpp:822: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:810: using obsolete binding at `i'
objectPairClass.cpp: In member function `void
objectPairClass::frequencyBasedPruneForScoring(int)':
objectPairClass.cpp:882: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:870: using obsolete binding at `i'
objectPairClass.cpp: In member function `void
objectPairClass::scoreBasedPrune(float)':
objectPairClass.cpp:914: warning: unused variable `int pruned_count'
objectPairClass.cpp: In member function `void objectPairClass::prune()':
objectPairClass.cpp:976: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:952: using obsolete binding at `i'
objectPairClass.cpp:994: warning: assignment to `int' from `float'
objectPairClass.cpp:994: warning: argument to `int' from `float'
objectPairClass.cpp: In member function `void objectPairClass::prune2(bool,
bool)':
objectPairClass.cpp:1015: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1046: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1059: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1069: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:1020: using obsolete binding at `i'
objectPairClass.cpp:1071: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1099: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1122: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1125: `struct objectPairInfo' has no member named `
doc_array'
objectPairClass.cpp:1126: `struct objectPairInfo' has no member named `
doc_array'
objectPairClass.cpp:1129: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1130: `struct objectPairInfo' has no member named `
doc_array'
objectPairClass.cpp:1346:2: warning: no newline at end of file
/usr/include/c++/3.2.3/bits/locale_facets.h: At top level:
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
../../../JargonDOCLIB/src/JargonScriptIDLib/JMorphology.h:6: warning: `char
JARGONVERSION[33]' defined but not used
make[1]: *** [objectPairClass.o] Error 1
make[1]: Leaving directory `/home/amsakak/sandbox/PageLayoutDOCLIB/src/PageLayoutLib'
make: *** [all-recursive] Error 1
Bug Notes
amsakak   
07-06-05 09:19   
I just checked out the latest doclib and add-ons as of July 6, 2005. Thing still do not compile for PageLayoutDOCLIB.

Making all in PageLayoutLib
make[1]: Entering directory `/home/amsakak/DOCLIB/sandbox/PageLayoutDOCLIB/src/PageLayoutLib'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I. -I../../../doclib/include -I../../../JargonDOCLIB/src/JargonScriptIDLib -I../../../getLinesDOCLIB/src/getLinesLib -I/home/amsakak/DOCLIB/sandbox/doclib/resource/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/zlib -I/usr/local/include objectInfoClass.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../../../JargonDOCLIB/src/JargonScriptIDLib/JScript.h:7,
from objectInfoClass.h:6,
from objectInfoClass.cpp:10:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
objectInfoClass.cpp: In constructor
`objectInfoClass::objectInfoClass(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, JScript*, int, char*, int,
int, int)':
objectInfoClass.cpp:168: warning: format argument is not a pointer (arg 4)
objectInfoClass.cpp:170: warning: cannot pass objects of non-POD type `struct
std::string' through `...'; call will abort at runtime
objectInfoClass.cpp:170: warning: format argument is not a pointer (arg 4)
objectInfoClass.cpp:406:9: warning: "/*" within comment
objectInfoClass.cpp: In member function `objectInfo*
objectInfoClass::computeObjectInfo(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, int)':
objectInfoClass.cpp:317: warning: unused variable `unsigned char*pixels1'
objectInfoClass.cpp:320: warning: unused variable `unsigned char*newr_image'
objectInfoClass.cpp:322: warning: unused variable `int long_line_count'
objectInfoClass.cpp:323: warning: unused variable `int*iList'
objectInfoClass.cpp:324: warning: unused variable `int*line_segs'
objectInfoClass.cpp:327: warning: unused variable `int big_line_count'
objectInfoClass.cpp:834:9: warning: "/*" within comment
objectInfoClass.cpp:855:9: warning: "/*" within comment
objectInfoClass.cpp: In member function `void
objectInfoClass::computeInterlineSpacingFeatures(DLImage*, DLlineInfo*, int,
float*, float*)':
objectInfoClass.cpp:865: warning: unused variable `int cols'
objectInfoClass.cpp:1140:1: warning: "/*" within comment
objectInfoClass.cpp:1143:1: warning: "/*" within comment
objectInfoClass.cpp: In member function `int
objectInfoClass::tbComputeDCT(double*, int, double**)':
objectInfoClass.cpp:1175: warning: assignment to `unsigned char' from `double'
objectInfoClass.cpp:1175: warning: argument to `unsigned char' from `double'
objectInfoClass.cpp: In member function `void
objectInfoClass::writeG4TiffGray(char*, float*, int)':
objectInfoClass.cpp:718: warning: `double rotation_angle' might be used
uninitialized in this function
objectInfoClass.cpp:722: warning: `DLImage*outImage' might be used
uninitialized in this function
objectInfoClass.cpp: In member function `void
objectInfoClass::writeG4Tiff(char*)':
objectInfoClass.cpp:762: warning: `DLImage*outImage' might be used
uninitialized in this function
../../../doclib/include/DLConnectedComponents.h: At top level:
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
../../../JargonDOCLIB/src/JargonScriptIDLib/JMorphology.h:6: warning: `char
JARGONVERSION[33]' defined but not used
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I. -I../../../doclib/include -I../../../JargonDOCLIB/src/JargonScriptIDLib -I../../../getLinesDOCLIB/src/getLinesLib -I/home/amsakak/DOCLIB/sandbox/doclib/resource/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/zlib -I/usr/local/include objectPairClass.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../../../JargonDOCLIB/src/JargonScriptIDLib/JScript.h:7,
from objectInfoClass.h:6,
from objectPairClass.h:5,
from objectPairClass.cpp:2:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
In file included from objectPairClass.cpp:2:
objectPairClass.h:9:34: ..\utility_hm\Tarray.h: No such file or directory
In file included from objectPairClass.cpp:2:
objectPairClass.h:61: 'CTArray' is used as a type, but is not defined as a
type.
objectPairClass.h: In destructor `objectPairInfo::~objectPairInfo()':
objectPairClass.h:65: `doc_array' undeclared (first use this function)
objectPairClass.h:65: (Each undeclared identifier is reported only once for
each function it appears in.)
objectPairClass.h: In member function `objectPairInfo&
objectPairInfo::operator=(objectPairInfo)':
objectPairClass.h:94: `struct objectPairInfo' has no member named `doc_array'
objectPairClass.h: At global scope:
objectPairClass.h:107: 'CTArray' is used as a type, but is not defined as a
type.
objectPairClass.h: In member function `void pairCluster::Add(int)':
objectPairClass.h:116: `memberlist' undeclared (first use this function)
objectPairClass.h:118: `CTArray' undeclared (first use this function)
objectPairClass.h:118: parse error before `;' token
objectPairClass.h:121: `tmp' undeclared (first use this function)
objectPairClass.h:209:7: warning: no newline at end of file
objectPairClass.cpp:3:23: polyclass.h: No such file or directory
objectPairClass.cpp: In member function `void
objectPairClass::readDataWithScores(FILE*)':
objectPairClass.cpp:236: warning: int format, objectType arg (arg 3)
objectPairClass.cpp:236: warning: int format, objectType arg (arg 4)
objectPairClass.cpp:236: warning: int format, float arg (arg 7)
objectPairClass.cpp:236: warning: char format, different type arg (arg 19)
objectPairClass.cpp:236: warning: char format, different type arg (arg 20)
objectPairClass.cpp:236: warning: too few arguments for format
objectPairClass.cpp: In constructor `objectPairClass::objectPairClass(const
char*, FILE*)':
objectPairClass.cpp:305: warning: int format, objectType arg (arg 3)
objectPairClass.cpp:305: warning: int format, objectType arg (arg 4)
objectPairClass.cpp:305: warning: int format, float arg (arg 7)
objectPairClass.cpp: In constructor
`objectPairClass::objectPairClass(objectInfo*, int, int, FILE*)':
objectPairClass.cpp:353: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:345: using obsolete binding at `i'
objectPairClass.cpp: In member function `void
objectPairClass::printScoreInfo(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >)':
objectPairClass.cpp:453: warning: int format, double arg (arg 8)
objectPairClass.cpp: In member function `void
objectPairClass::printInfo(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >)':
objectPairClass.cpp:494: warning: int format, double arg (arg 8)
objectPairClass.cpp: In member function `void
objectPairClass::merge(objectPairClass*, int)':
objectPairClass.cpp:728: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:726: using obsolete binding at `i'
objectPairClass.cpp:743: warning: assignment to `int' from `float'
objectPairClass.cpp:743: warning: argument to `int' from `float'
objectPairClass.cpp:764: name lookup of `merged' changed for new ISO `for'
scoping
objectPairClass.cpp:731: using obsolete binding at `merged'
objectPairClass.cpp: In member function `void
objectPairClass::frequencyBasedPrune(int, FILE*)':
objectPairClass.cpp:822: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:810: using obsolete binding at `i'
objectPairClass.cpp: In member function `void
objectPairClass::frequencyBasedPruneForScoring(int)':
objectPairClass.cpp:882: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:870: using obsolete binding at `i'
objectPairClass.cpp: In member function `void
objectPairClass::scoreBasedPrune(float)':
objectPairClass.cpp:914: warning: unused variable `int pruned_count'
objectPairClass.cpp: In member function `void objectPairClass::prune()':
objectPairClass.cpp:976: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:952: using obsolete binding at `i'
objectPairClass.cpp:994: warning: assignment to `int' from `float'
objectPairClass.cpp:994: warning: argument to `int' from `float'
objectPairClass.cpp: In member function `void objectPairClass::prune2(bool,
bool)':
objectPairClass.cpp:1015: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1046: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1059: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1069: name lookup of `i' changed for new ISO `for' scoping
objectPairClass.cpp:1020: using obsolete binding at `i'
objectPairClass.cpp:1071: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1099: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1122: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1125: `struct objectPairInfo' has no member named `
doc_array'
objectPairClass.cpp:1126: `struct objectPairInfo' has no member named `
doc_array'
objectPairClass.cpp:1129: `struct pairCluster' has no member named `memberlist'
objectPairClass.cpp:1130: `struct objectPairInfo' has no member named `
doc_array'
objectPairClass.cpp:1346:2: warning: no newline at end of file
/usr/include/c++/3.2.2/bits/locale_facets.h: At top level:
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
../../../JargonDOCLIB/src/JargonScriptIDLib/JMorphology.h:6: warning: `char
JARGONVERSION[33]' defined but not used
make[1]: *** [objectPairClass.o] Error 1
make[1]: Leaving directory `/home/amsakak/DOCLIB/sandbox/PageLayoutDOCLIB/src/PageLayoutLib'
make: *** [all-recursive] Error 1
jjbran2   
07-06-05 12:47   
2 possible problems:

- on Windows the file system is case insensitive, so the author was not careful about the case of the #include files

- some MFC classes are used in this code which aren't available in gcc.




Viewing Bug Advanced Details
543 Doclib Addons text always 10-12-05 10:24 12-19-05 10:22
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
LogoRecognition
In some version of the LogoTokenMatch code, the score/distance reported was a value between 0 and 1. It now appears that the score is between 0 and 99??????

The documentation does not provide any information about the interpretation of the score.........

What is consider a good match? what is not a good match and waht is in between???????

Bug Notes
meyers_tim   
12-19-05 10:22   
LogoTokenMatch scores approach 0 as the logo candidates get better. I will add some documentation for the next release stating so.

I have not been able to track down the reason for the switch from 0 to 100, but I will to revert back to 0 to 1 for the next release to clear up any confusion.




Viewing Bug Advanced Details
552 DLImage major always 10-21-05 17:44 12-19-05 10:07
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DLImage cannot open image
Cannot open a JPG image if it is memory resident. Works on the same image if file based. A message is printed:

Exception: DLJPGIMage.cpp: 477 <DLJPGImage::dlLoadImage()> Decompression Error!

See reporter for sample files and test code.

Bug Notes
meyers_tim   
12-19-05 10:07   
This problem has been fixed internally and exported to the unclassified side. I have also reinstalled Doclib on both Linux and Sun with the changes.

The sample files provided all work fine now.




Viewing Bug Advanced Details
559 DLComponent feature always 12-07-05 11:29 12-07-05 11:30
mirekg  
mirekg  
normal  
resolved  
fixed  
none  
none  
test
test
test
There are no notes attached to this bug.




Viewing Bug Advanced Details
551 Doclib Addons minor always 10-21-05 11:14 11-29-05 12:40
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
Exception Error Message corrupted
Using docid library, I get a corrupt error message after executing the following code when I accidentally sent the algorithm a PDF file:

try {
image = new ImageFeatures();
image->IFLoadImage(filename, desired_colors); // throws exception because of PDF file
} catch(DLException e)
cerr << e.dlGetErrorMsg() << endl; // prints garbled stuff
}
Bug Notes
meyers_tim   
11-29-05 12:40   
Internal Email sent with fix




Viewing Bug Advanced Details
553 DLImage major always 10-24-05 14:49 10-27-05 11:21
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none 0000539  
none  
File loads with DLImage, but is corrupt
A corrupt file that appears to be a GIF loads under DLImage and a call to dlIsCorrupt indicates the tile is not corrupt.

See reporter for more information and the file in question at the government site.
There are no notes attached to this bug.




Viewing Bug Advanced Details
547 DLComponent crash always 10-20-05 14:44 10-26-05 10:40
gawarho  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DOCLIB Crashes when opening file
When opening a specific GIF file, DOCLIB crashes.

Please see customer/reporter for information about the file and specifics at government site.


Bug Notes
meyers_tim   
10-26-05 10:40   
This has been fixed and installed on the customer site as well as exported to unclassified version.




Viewing Bug Advanced Details
539 DLConnectedComponent crash always 10-05-05 08:52 10-25-05 10:39
mirekg  
meyers_tim  
high  
resolved  
fixed  
none  
none  
gif image causing doclib crash
I have an image on the Govt. network causing doclib to crash. It is in ~lmgoleb/doclib_problem_images. The readme file in that directory points to the specific image
Bug Notes
meyers_tim   
10-25-05 10:39   
This bug is actually related to a false positive, Doclib was loading an image that it really shouldn't have. The GIF provided lacked a true GIF data segment, thus the DLImage data segment was filled with garbage. I believe a call to DLConnectedComponents highlighted this error. It has been resolved and exported.




Viewing Bug Advanced Details
177 feature N/A 05-19-04 14:00 10-25-05 10:22
rziemer  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Need Option for alternative Linking Methods
In order to compile using DocLib in alternative environements (i.e. Multi-Threaded MFC) DocLib should have alternate configurations setup in the Visual Studio project that link to the standard C library through Static Multi-Threading, Multi-Threaded DLL, Static Single-Threaded, Single-Threaded DLL, in both Debug and Release modes. This linking can be changed in:

Properties->C/C++->Code Generation->Runtime Library
There are no notes attached to this bug.




Viewing Bug Advanced Details
431 Other feature N/A 05-09-05 08:55 10-25-05 10:11
chen_kevin  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
DOCLIB libs compiled using Visual C++ 7.1 can not be linked in with Visual c++ 7.0
Libs produced using Visual C++ compilers can not be linked in using a different version of Visual c++. This is an issue when distributing DOCLIB libs and the user doesn't have the right version of the compiler.
Bug Notes
chen_kevin   
05-09-05 08:57   
Reminder sent to jjbran2

jjbran2   
05-09-05 10:43   
My experience was with .NET 2003 vs. .NET 2001.

The .NET 2001 driver program could link to the .NET 2003 libDoclib but the program would crash immediately.
chen_kevin   
05-19-05 13:30   
Discovered .NET 2003 (V7.1) is not backward compatible with .NET 2002 (V7.0).

Build DOCLIB with .NET 2002. Build Jargon with .NET 2003 liking in DOCLIB (build with 2002) and Sigfault immediately when executed.


What we have tried :

1. Build DOCLIB with .NET 2002 V7.0. Link DOCLIB to a driver using .NET 2003 V7.1. Program crushes

2. Build DOCLIB with .NET 2003 V7.1. Link DOCLIB to a driver using .NET 2002 V7.0. Program crushes

3. Build DOCLIB with MSVC 6.0 . Link DOCLIB to a driver using .NET 2002 V7.1. Will not link.

edited on: 05-19-05 15:11
chen_kevin   
10-25-05 10:07   
DOCLIB is working with MSVC 7.1 and tot concerned with MSVC 7.0 and below.
chen_kevin   
10-25-05 10:11   
Please look at bug note




Viewing Bug Advanced Details
130 DLComponent feature always 03-16-04 17:48 10-25-05 10:09
admin  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
add documentation
In general our documentation is a bit too sparse, about one sentence per function.
have provided in-depth documentation for DLIMage and DLBitsPerPixelConverter. Will pass off to Kevin to adapt same documentation standards to all CC-related functions.
Bug Notes
chen_kevin   
10-25-05 10:09   
added




Viewing Bug Advanced Details
278 DLComponent feature always 10-18-04 17:26 10-25-05 10:08
mirekg  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Text Line detection needs to be modified to output DLZones
Text Line detection needs to be modified to output DLZones
Bug Notes
sdsampa   
11-19-04 09:53   
DLZone is currently not stable. Recommend waiting to make mods to this until UMCP becomes more adapt to the DOCLIB development process.
chen_kevin   
12-08-04 12:52   
DLZone is a very complex object and should not use DLZone as the return type.
chen_kevin   
10-25-05 10:08   
Don't think we will be using DLZones




Viewing Bug Advanced Details
510 Other minor always 08-02-05 10:28 10-25-05 10:05
jjbran2  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Destruction of singleton objects
Earlier in Bug 0000426, Saki brought attention to the problem of the several singleton objects in Doclib not getting properly destroyed, which shows up in valgrind reports. To continue discussion on this issue, please see the following link:

http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt

this article is also reproduced and updated in the book Pattern Hatching by John Vlissides (Addison-Wesley, 1998)

To do a thorough job of cleaning up after ourselves, we should consider implementing one of these suggestions.
Bug Notes
meyers_tim   
10-03-05 15:58   
Kevin, this was implemented, no?
chen_kevin   
10-25-05 10:05   
Added DLSingletonDestroyer to destruct singleton objects. All singleton objects are modified to include DLSingletonDestroyer.




Viewing Bug Advanced Details
364 Other feature always 02-21-05 14:03 10-25-05 10:01
chen_kevin  
chen_kevin  
normal  
resolved  
fixed  
none  
none  
Need to resolve compilation warnings in Doclib
A number of the Doclib .cpp files ahve the
"Warning: String literal converted to char*"
Put (char *) in front of all the string literals in order to set up the proper casting.

Also other warning messages.
Bug Notes
admin   
03-22-05 09:20   
A step will be added for the next release. Please confirm the non-existence of warnings and resolve appropriately.
chen_kevin   
05-26-05 09:37   
Numerous compilation warnings has been resolved. This an on going process since new warnings will be introduced.
meyers_tim   
10-03-05 16:53   
I believe the only warnings we are getting now are

../../include/DLConst.h:67: warning: `const char*DL_DIR_SEPARATOR' defined but
not used
../../include/DLColor.h:8: warning: `unsigned char DLColorMap[744]' defined but
not used

These really need to be resolved as nearly every file throws them. Perhaps they need their own bug.

Ready to close this bug?
chen_kevin   
10-25-05 10:01   
resolved




Viewing Bug Advanced Details
486 Other major always 07-01-05 10:32 10-07-05 14:52
amsakak  
chen_kevin  
high  
resolved  
fixed  
none  
none  
logoTokenMatchDOCLIB unable to compile
This error has been verified on both Mediaproc and the Dell team laptop.

Making all in token_match_lib
make[1]: Entering directory `/home/amsakak/sandbox/logoTokenMatchDOCLIB/src/token_match_lib'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I./ -I../../../doclib/include -I/home/amsakak/sandbox/doclib/resource/include -I/home/amsakak/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/sandbox/doclib/resource/linux/include/zlib -I/home/amsakak/INSTALL/linux24/include DLLogoTokenMatch.cpp
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
ar cru libLogoTokenMatchLib.a DLLogoTokenMatch.o
ranlib libLogoTokenMatchLib.a
../../linux24/lib/libLogoTokenMatchLib.a successfully created.
make[1]: Leaving directory `/home/amsakak/sandbox/logoTokenMatchDOCLIB/src/token_match_lib'
Making all in driver
make[1]: Entering directory `/home/amsakak/sandbox/logoTokenMatchDOCLIB/src/driver'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I../token_match_lib -I../../../LogoDetectDOCLIB/src/LogoDetectLib/ -I../../../doclib/include -I/home/amsakak/sandbox/doclib/resource/include -I/home/amsakak/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/sandbox/doclib/resource/linux/include/zlib -I/home/amsakak/INSTALL/linux24/include DLTestLogoMatch.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../../../LogoDetectDOCLIB/src/LogoDetectLib/DLLogoDetect.h:6,
from DLTestLogoMatch.cpp:2:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
g++ -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -o LogoTokenMatch_commandLine DLTestLogoMatch.o -L../../linux24/lib -L../../../doclib/linux24/lib -L../../../LogoDetectDOCLIB/linux24/lib -L/home/amsakak/sandbox/doclib/resource/linux -L/home/amsakak/INSTALL/linux24/lib -lLogoTokenMatchLib -lLogoDetectLib -lDoclib -ltiff -ljpeg -lpng -lz -lm
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x1049): In function `DLZone::dlSetZoneWidth(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x11c5): In function `DLZone::dlSetZoneHeight(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
collect2: ld returned 1 exit status
make[1]: *** [LogoTokenMatch_commandLine] Error 1
make[1]: Leaving directory `/home/amsakak/sandbox/logoTokenMatchDOCLIB/src/driver'
make: *** [all-recursive] Error 1
Bug Notes
amsakak   
07-06-05 09:17   
I just downloaded the latest doclib and add-ons as of July 6, 2005. logoTokenMatchDOCLIB still does not compile.

Making all in token_match_lib
make[1]: Entering directory `/home/amsakak/DOCLIB/sandbox/logoTokenMatchDOCLIB/src/token_match_lib'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I./ -I../../../doclib/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/zlib -I/usr/local/include DLLogoTokenMatch.cpp
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
ar cru libLogoTokenMatchLib.a DLLogoTokenMatch.o
ranlib libLogoTokenMatchLib.a
../../linux24/lib/libLogoTokenMatchLib.a successfully created.
make[1]: Leaving directory `/home/amsakak/DOCLIB/sandbox/logoTokenMatchDOCLIB/src/token_match_lib'
Making all in driver
make[1]: Entering directory `/home/amsakak/DOCLIB/sandbox/logoTokenMatchDOCLIB/src/driver'
g++ -c -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -I../token_match_lib -I../../../LogoDetectDOCLIB/src/LogoDetectLib/ -I../../../doclib/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/include -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libjpeg -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libpng -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/libtiff -I/home/amsakak/DOCLIB/sandbox/doclib/resource/linux/include/zlib -I/usr/local/include DLTestLogoMatch.cpp
In file included from ../../../doclib/include/DLConnectedComponents.h:8,
from ../../../LogoDetectDOCLIB/src/LogoDetectLib/DLLogoDetect.h:6,
from DLTestLogoMatch.cpp:2:
../../../doclib/include/DLCompIterator.h:459:27: warning: no newline at end of file
../../../doclib/include/DLConst.h:62: warning: `const char*DIR_SEPARATOR'
defined but not used
../../../doclib/include/DLColor.h:7: warning: `unsigned char DLColorMap[744]'
defined but not used
g++ -O3 -fexpensive-optimizations -Wall -DDL_DBG=DL_CRITICAL -o LogoTokenMatch_commandLine DLTestLogoMatch.o -L../../linux24/lib -L../../../doclib/linux24/lib -L../../../LogoDetectDOCLIB/linux24/lib -L/home/amsakak/DOCLIB/sandbox/doclib/resource/linux -L/usr/local/lib -lLogoTokenMatchLib -lLogoDetectLib -lDoclib -ltiff -ljpeg -lpng -lz -lm
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x1049): In function `DLZone::dlSetZoneWidth(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
../../../doclib/linux24/lib/libDoclib.a(DLZone.o)(.text+0x11c5): In function `DLZone::dlSetZoneHeight(int)':
: undefined reference to `DLPage::dlCheckPageImageData()'
collect2: ld returned 1 exit status
make[1]: *** [LogoTokenMatch_commandLine] Error 1
make[1]: Leaving directory `/home/amsakak/DOCLIB/sandbox/logoTokenMatchDOCLIB/src/driver'
make: *** [all-recursive] Error 1
meyers_tim   
10-03-05 17:01   
Saki, I believe this issue, along with the other add-ons, is resolved. Confirm?
chen_kevin   
10-07-05 14:52   
Resolved




Viewing Bug Advanced Details
450 Other feature always 06-01-05 10:05 10-03-05 16:29
chen_kevin  
meyers_tim  
low  
resolved  
fixed  
none  
none  
DoclibProtypeCommandLine is not supposed to be installed
DoclibProtypeCommandLine is for code example or unit testing purposes only and not to be released. Need to modify make/install script to take out the installation of DoclibProtypeCommandLine.
Bug Notes
chen_kevin   
06-03-05 14:14   
Tim, can you verify this when you are over client site? Also, the makefile might need to be modified so this will not happen when we try to do an install. Verify with next import of doclib.
meyers_tim   
10-03-05 16:29   
I have modified the Makefile.am files on both the class/unclass networks so that DLPrototypeCommandLine will no longer install.




Viewing Bug Advanced Details
434 Other feature always 05-10-05 12:40 10-03-05 16:07
amsakak  
meyers_tim  
normal  
resolved  
fixed  
none  
none  
DOCLIB Beta Release Procedures.doc
Please note that many of us do not have access to Windows machines. Hence, Microsoft Word documents cannot be read. It might be better to use something neutral such as ASCII text or HTML. Also, file names can be more easily managed if they do not contain spaces.
Bug Notes
meyers_tim   
10-03-05 16:07   
An HTML version is now included, sans spaces in the filename.




Viewing Bug Advanced Details
537 Other feature always 09-30-05 14:14 09-30-05 14:20
meyers_tim  
meyers_tim  
low  
resolved  
fixed  
none  
none  
Create Customer Development Instructions Website
We need an instructional document for doing internal doclib development.
Bug Notes
meyers_tim   
09-30-05 14:20   
Can be found in the doclib/ReleaseDocs directory




Viewing Bug Advanced Details
493 Other feature always 07-19-05 09:50 09-30-05 10:45
amsakak  
jjbran2  
normal  
resolved  
fixed  
none  
none  
DOCLIB core documentation needs work
Documentation is weak. Incomprehensible at times. Consider the following example taken from classDLConnectedComponents.html:

int DLConnectedComponents::dlFilterCCMassGreater ( float blobpct )

Filter connected components for Mass Greater Exclude low-densiy components

Parameters:
blobpct float


Bug Notes
jjbran2   
07-29-05 15:46   
well, I shouldn't have made it resolved, since we are still working on the overall docs. Should be done by the time of the next release...
jjbran2   
09-30-05 10:45   
done for now...