Open Hub
Black Duck Open Hub

 Settings |  Report Duplicate

2
I Use This!
Moderate Activity

Commits : Listings

Analyzed 1 day ago. based on code collected 1 day ago.
Apr 29, 2023 — Apr 29, 2024
Commit Message Contributor Files Modified Lines Added Lines Removed Code Location Date
fix MSVC warning C4703: potentially uninitialized local pointer variable 'pixa1' used
Ger Hobbelt
More... 9 months ago
Simplify getFilenamesInDirectory() (thanks to Pierre Benoit) * Call genPathname() before realpath() * Require either POSIX 2008 or use of glibc; this avoids realpath bug
danblooomberg
More... 9 months ago
Fix some regtest issues (thanks to Pierre Benoit) * In fpix1_reg.c, do not generate gplot. This displays the generated plot. * In kernel_reg.c, do not attempt to use the plot data previously made by fpix1_reg.c. Also use more standard pix variable names. * In numa3_reg.c, write data to the correct directory (/tmp/lept/numa3). * also add comment in pdfio1.c on choosing a default encoding.
danblooomberg
More... 9 months ago
fix: MSVC warning about unused variable
Ger Hobbelt
More... 9 months ago
fix: warning C4703: potentially uninitialized local pointer variable 'pixa1' used
Ger Hobbelt
More... 9 months ago
tweak a few comments for better readability of the documentation
Ger Hobbelt
More... 9 months ago
tweak a few comments for better readability of the documentation
Ger Hobbelt
More... 9 months ago
New pdfapp.c and pdfappstub.c. * These have functions compressFilesToPdf() and cleanTo1bppFilesToPdf(), which hold the image processing functionality that was previously in prog/cleanpdf and prog/compresspdf. These no longer write intermediate image files; they store everything in either a pixa (n <= 100 images) or a pixac (n > 100 images). * Input to these functions is an SArray of image file paths. * The programs pull images out of a set of input pdfs, and put them uncompressed in a set of files. The new functions do some image processing and wrap the results up in a single output pdf. * Also, rename concatpdf --> compresspdf, because all these functions, and others to be written, will do concatenation of input pdf files. * Also, minor documentation fix in gplot.c.
danblooomberg
More... 9 months ago
typo fix in documentation comment
Ger Hobbelt
More... 9 months ago
Update README.html
egorpugin
as Egor Pugin
More... 9 months ago
Merge pull request #700 from amitdo/cmake-rm-cxx
zdenop
More... 11 months ago
CMakeLists.txt: Remove remainng 'cxx'
Amit D
More... 11 months ago
Add read/write alpha tests to prog/misctest1.c
danblooomberg
More... 11 months ago
fixing MSVC "possible use of uninitialized variable" warnings fixed.
Ger Hobbelt
More... 11 months ago
Merge pull request #697 from zdenop/cmake_C17
zdenop
More... 11 months ago
Use getPdfRendererResolution() in concatpdf.c * As with cleanpdf.c, this prevents the pdftoppm renderer from making very large ppm files. * Also improve comments in environ.h.
danblooomberg
More... 11 months ago
Make a library function to determine the resolution to use when rendering * This is for rendering pdf pages to raster images. The MediaBox field specifies the size of the rendered image and thus gives indirect information about the image resolution. * Better to have this in the library for use with programs like cleanpdf, that use pdf renderers such as pdftoppm. * Because this library function calls 'system', it can only run under debug conditions. Default behavior is to return an error.
danblooomberg
More... 11 months ago
Figure out resolution of rendered pdf image. * Use in prog/cleanpdf.c to avoid rendering images that are too large. If the mediabox sizes are not available, render one image at a known and low resolution, and figure out the resolution input to the renderer (pdftoppm) so that the result is an 11 inch page at 300 ppi.
danblooomberg
More... 11 months ago
New getPdfMediaBoxSizes(). * Most pdf files have an unencrypted MediaBox variable, which is used by image renderers for scaling the raster output. Some pdf files have this set incorrectly. If it is too big (e.g., by confusing printer points with pixels, thus assuming the resolution is 72 ppi), the renderer will make very large images. This can be prevented by finding the median mediabox sizes and modifying the resolution in the renderer accordingly. * Modify prog/cleanpdf.c to avoid making large intermediate ppm files.
danblooomberg
More... 11 months ago
Merge pull request #695 from amitdo/amitdo-autoconf-269
zdenop
More... 12 months ago
cmake: +include(GNUInstallDirs)
Zdenko Podobný
More... 12 months ago
cmake windows: fix not found gif_lib.h
Zdenko Podobný
More... 12 months ago
cmake: remove CXX from project, fix msvc 2019 build, use C17 standard
Zdenko Podobný
More... 12 months ago
Create cmake-win64.yml
zdenop
More... 12 months ago
configure.ac: Update minimum required autoconf version
Amit D
More... 12 months ago
New getPdfPageSizes(). * This can be useful for determining resolution of page images; for example, if the width is assumed to be 8.5 inches. * Knowing the size of the image allows more efficient modifications where a program such as mutool is used to extract pages or images for cleaning or better compression. These images assume that the media box is correct, and they accept a resolution as input. The media box is the size in printer points. We have seen scanned images where the resolution was incorrectly assumed to be 72 ppi, resulting in a large media box. That large box, combined with an assumed resolution of 300 ppi will cause large upscaling of about 4x in the scanned image by the extractor.
danblooomberg
More... 12 months ago
Modify concatpdf.c to handle very large inputs and do better compression * For many image files (> 100), store them compressed with pixacomp. * By default, all images will be encoded as rgb using jpeg's DCT. * For efficient encoding of monochrome images, call with the one_bit input parameter set to 1. This will encode all images with tiffg4. * For mixed encoding, where images with color are encoded with DCT and those without color are encoded with tiffg4, set both one_bit and save_color input parameters to 1. * For determining color content, we are only using the colorfract output from pixColorFract(), so make both outputs optional.
danblooomberg
More... about 1 year ago
Make pixSetPadBits() a no-op for 24-bit pix * This prevents any problems at the lowest level, no matter how it is used.
danblooomberg
More... about 1 year ago
Fixed png writing 24 bpp pix (see Issue #686) * We were setting the pad bits, which, because the pixel data is no longer aligned with 32-bit word boundaries, could set one or more components of the last pixel in a row to zero.
danblooomberg
More... about 1 year ago
New pixDisplayDiff() function to display difference between images; issue #682 * The display function is tested in misctest1.c * It is used in ioformats_reg.c to investigate a bug found by Ger Hobbelt. This is a problem with png writing 24 bpp: the rightmost column of pixels is wrong. (bmp writing and reading 24 bpp rgb files is correct.) The problem was uncovered when Hobbelt investigated issue #675, which claimed that components were switched when reading RGBA bmp files, but this was determined not to be reproducible on linux or Windows. * Also in ioformats_reg.c, test the 32->24 bit and 24->32 bit conversions.
danblooomberg
More... about 1 year ago