Alien-FreeImage
view release on metacpan or search on metacpan
src/Source/LibJPEG/jdinput.c view on Meta::CPAN
* currently capable of doing this, but other encoders might.) Since we want
* to be able to dequantize all the components at the end of the file, this
* means that we have to save away the table actually used for each component.
* We do this by copying the table at the start of the first scan containing
* the component.
* The JPEG spec prohibits the encoder from changing the contents of a Q-table
* slot between scans of a component using that slot. If the encoder does so
* anyway, this decoder will simply use the Q-table values that were current
* at the start of the first scan for the component.
*
* The decompressor output side looks only at the saved quant tables,
* not at the current Q-table slots.
*/
LOCAL(void)
latch_quant_tables (j_decompress_ptr cinfo)
{
int ci, qtblno;
jpeg_component_info *compptr;
JQUANT_TBL * qtbl;
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
2. Specify the destination for the compressed data (eg, a file).
As previously mentioned, the JPEG library delivers compressed data to a
"data destination" module. The library includes one data destination
module which knows how to write to a stdio stream. You can use your own
destination module if you want to do something else, as discussed later.
If you use the standard destination module, you must open the target stdio
stream beforehand. Typical code for this step looks like:
FILE * outfile;
...
if ((outfile = fopen(filename, "wb")) == NULL) {
fprintf(stderr, "can't open %s\n", filename);
exit(1);
}
jpeg_stdio_dest(&cinfo, outfile);
where the last line invokes the standard destination module.
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
Image data should be written in top-to-bottom scanline order. The JPEG spec
contains some weasel wording about how top and bottom are application-defined
terms (a curious interpretation of the English language...) but if you want
your files to be compatible with everyone else's, you WILL use top-to-bottom
order. If the source data must be read in bottom-to-top order, you can use
the JPEG library's virtual array mechanism to invert the data efficiently.
Examples of this can be found in the sample application cjpeg.
The library maintains a count of the number of scanlines written so far
in the next_scanline field of the JPEG object. Usually you can just use
this variable as the loop counter, so that the loop test looks like
"while (cinfo.next_scanline < cinfo.image_height)".
Code for this step depends heavily on the way that you store the source data.
example.c shows the following code for the case of a full-size 2-D source
array containing 3-byte RGB pixels:
JSAMPROW row_pointer[1]; /* pointer to a single row */
int row_stride; /* physical row width in buffer */
row_stride = image_width * 3; /* JSAMPLEs per row in image_buffer */
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
2. Specify the source of the compressed data (eg, a file).
As previously mentioned, the JPEG library reads compressed data from a "data
source" module. The library includes one data source module which knows how
to read from a stdio stream. You can use your own source module if you want
to do something else, as discussed later.
If you use the standard source module, you must open the source stdio stream
beforehand. Typical code for this step looks like:
FILE * infile;
...
if ((infile = fopen(filename, "rb")) == NULL) {
fprintf(stderr, "can't open %s\n", filename);
exit(1);
}
jpeg_stdio_src(&cinfo, infile);
where the last line invokes the standard source module.
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
formats", above. Don't forget that grayscale and color JPEGs will return
different data formats!
Image data is returned in top-to-bottom scanline order. If you must write
out the image in bottom-to-top order, you can use the JPEG library's virtual
array mechanism to invert the data efficiently. Examples of this can be
found in the sample application djpeg.
The library maintains a count of the number of scanlines returned so far
in the output_scanline field of the JPEG object. Usually you can just use
this variable as the loop counter, so that the loop test looks like
"while (cinfo.output_scanline < cinfo.output_height)". (Note that the test
should NOT be against image_height, unless you never use scaling. The
image_height field is the height of the original unscaled image.)
The return value always equals the change in the value of output_scanline.
If you don't use a suspending data source, it is safe to assume that
jpeg_read_scanlines() reads at least one scanline per call, until the
bottom of the image has been reached.
If you use a buffer larger than one scanline, it is NOT safe to assume that
src/Source/LibJPEG/libjpeg.txt view on Meta::CPAN
The next three parameters are relevant only if quantize_colors is TRUE.
int desired_number_of_colors
Maximum number of colors to use in generating a library-supplied color
map (the actual number of colors is returned in a different field).
Default 256. Ignored when the application supplies its own color map.
boolean two_pass_quantize
If TRUE, an extra pass over the image is made to select a custom color
map for the image. This usually looks a lot better than the one-size-
fits-all colormap that is used otherwise. Default is TRUE. Ignored
when the application supplies its own color map.
J_DITHER_MODE dither_mode
Selects color dithering method. Supported values are:
JDITHER_NONE no dithering: fast, very low quality
JDITHER_ORDERED ordered dither: moderate speed and quality
JDITHER_FS Floyd-Steinberg dither: slow, high quality
Default is JDITHER_FS. (At present, ordered dither is implemented
only in the single-pass, standard-colormap case. If you ask for
src/Source/LibJPEG/rdswitch.c view on Meta::CPAN
fclose(fp);
return TRUE;
}
#ifdef C_MULTISCAN_FILES_SUPPORTED
LOCAL(boolean)
read_scan_integer (FILE * file, long * result, int * termchar)
/* Variant of read_text_integer that always looks for a non-space termchar;
* this simplifies parsing of punctuation in scan scripts.
*/
{
register int ch;
if (! read_text_integer(file, result, termchar))
return FALSE;
ch = *termchar;
while (ch != EOF && isspace(ch))
ch = text_getc(file);
src/Source/LibJPEG/rdtarga.c view on Meta::CPAN
if (is_bottom_up) {
/* Create a virtual array to buffer the upside-down image. */
source->whole_image = (*cinfo->mem->request_virt_sarray)
((j_common_ptr) cinfo, JPOOL_IMAGE, FALSE,
(JDIMENSION) width * components, (JDIMENSION) height, (JDIMENSION) 1);
if (cinfo->progress != NULL) {
cd_progress_ptr progress = (cd_progress_ptr) cinfo->progress;
progress->total_extra_passes++; /* count file input as separate pass */
}
/* source->pub.buffer will point to the virtual array. */
source->pub.buffer_height = 1; /* in case anyone looks at it */
source->pub.get_pixel_rows = preload_image;
} else {
/* Don't need a virtual array, but do need a one-row input buffer. */
source->whole_image = NULL;
source->pub.buffer = (*cinfo->mem->alloc_sarray)
((j_common_ptr) cinfo, JPOOL_IMAGE,
(JDIMENSION) width * components, (JDIMENSION) 1);
source->pub.buffer_height = 1;
source->pub.get_pixel_rows = source->get_pixel_rows;
}
src/Source/LibJPEG/usage.txt view on Meta::CPAN
the same results everywhere. The fast integer method
is much less accurate than the other two.
-dither fs Use Floyd-Steinberg dithering in color quantization.
-dither ordered Use ordered dithering in color quantization.
-dither none Do not use dithering in color quantization.
By default, Floyd-Steinberg dithering is applied when
quantizing colors; this is slow but usually produces
the best results. Ordered dither is a compromise
between speed and quality; no dithering is fast but
usually looks awful. Note that these switches have
no effect unless color quantization is being done.
Ordered dither is only available in -onepass mode.
-map FILE Quantize to the colors used in the specified image
file. This is useful for producing multiple files
with identical color maps, or for forcing a predefined
set of colors to be used. The FILE must be a GIF
or PPM file. This option overrides -colors and
-onepass.
src/Source/LibJXR/jxrgluelib/JXRGlueJxr.c view on Meta::CPAN
pID->WMP.cLinesDecoded = 0;
pID->WMP.cLinesCropped = 0;
pID->WMP.fFirstNonZeroDecode = FALSE;
FailIf(ICERR_OK != ImageStrDecGetInfo(&pID->WMP.wmiI, &pID->WMP.wmiSCP), WMP_errFail);
assert(Y_ONLY <= pID->WMP.wmiSCP.cfColorFormat && pID->WMP.wmiSCP.cfColorFormat < CFT_MAX);
assert(BD_SHORT == pID->WMP.wmiSCP.bdBitDepth || BD_LONG == pID->WMP.wmiSCP.bdBitDepth);
// If HD Photo container provided an orientation, this should override bitstream orientation
// If container did NOT provide an orientation, force O_NONE. This is to be consistent with
// Vista behaviour, which is to ignore bitstream orientation (only looks at container).
if (pID->WMP.fOrientationFromContainer)
{
pID->WMP.wmiI.oOrientation = pID->WMP.oOrientationFromContainer;
}
else
{
// Force to O_NONE to match Vista decode behaviour
pID->WMP.wmiI.oOrientation = O_NONE;
}
src/Source/LibPNG/libpng-manual.txt view on Meta::CPAN
libpng can fill out those images or it can give them to you "as is".
It is almost always better to have libpng handle the interlacing for you.
If you want the images filled out, there are two ways to do that. The one
mentioned in the PNG specification is to expand each pixel to cover
those pixels that have not been read yet (the "rectangle" method).
This results in a blocky image for the first pass, which gradually
smooths out as more pixels are read. The other method is the "sparkle"
method, where pixels are drawn only in their final locations, with the
rest of the image remaining whatever colors they were initialized to
before the start of the read. The first method usually looks better,
but tends to be slower, as there are more pixels to put in the rows.
If, as is likely, you want libpng to expand the images, call this before
calling png_start_read_image() or png_read_update_info():
if (interlace_type == PNG_INTERLACE_ADAM7)
number_of_passes
= png_set_interlace_handling(png_ptr);
This will return the number of passes needed. Currently, this is seven,
src/Source/LibPNG/libpng.3 view on Meta::CPAN
libpng can fill out those images or it can give them to you "as is".
It is almost always better to have libpng handle the interlacing for you.
If you want the images filled out, there are two ways to do that. The one
mentioned in the PNG specification is to expand each pixel to cover
those pixels that have not been read yet (the "rectangle" method).
This results in a blocky image for the first pass, which gradually
smooths out as more pixels are read. The other method is the "sparkle"
method, where pixels are drawn only in their final locations, with the
rest of the image remaining whatever colors they were initialized to
before the start of the read. The first method usually looks better,
but tends to be slower, as there are more pixels to put in the rows.
If, as is likely, you want libpng to expand the images, call this before
calling png_start_read_image() or png_read_update_info():
if (interlace_type == PNG_INTERLACE_ADAM7)
number_of_passes
= png_set_interlace_handling(png_ptr);
This will return the number of passes needed. Currently, this is seven,
src/Source/LibPNG/pngrtran.c view on Meta::CPAN
if ((png_ptr->transformations & PNG_COMPOSE) != 0)
info_ptr->background = png_ptr->background;
#endif
#ifdef PNG_READ_GAMMA_SUPPORTED
/* The following used to be conditional on PNG_GAMMA (prior to 1.5.4),
* however it seems that the code in png_init_read_transformations, which has
* been called before this from png_read_update_info->png_read_start_row
* sometimes does the gamma transform and cancels the flag.
*
* TODO: this looks wrong; the info_ptr should end up with a gamma equal to
* the screen_gamma value. The following probably results in weirdness if
* the info_ptr is used by the app after the rows have been read.
*/
info_ptr->colorspace.gamma = png_ptr->colorspace.gamma;
#endif
if (info_ptr->bit_depth == 16)
{
# ifdef PNG_READ_16BIT_SUPPORTED
# ifdef PNG_READ_SCALE_16_TO_8_SUPPORTED
src/Source/LibPNG/pngrtran.c view on Meta::CPAN
{
int r, g, b, p;
sp = row;
dp = row;
for (i = 0; i < row_width; i++)
{
r = *sp++;
g = *sp++;
b = *sp++;
/* This looks real messy, but the compiler will reduce
* it down to a reasonable formula. For example, with
* 5 bits per color, we get:
* p = (((r >> 3) & 0x1f) << 10) |
* (((g >> 3) & 0x1f) << 5) |
* ((b >> 3) & 0x1f);
*/
p = (((r >> (8 - PNG_QUANTIZE_RED_BITS)) &
((1 << PNG_QUANTIZE_RED_BITS) - 1)) <<
(PNG_QUANTIZE_GREEN_BITS + PNG_QUANTIZE_BLUE_BITS)) |
(((g >> (8 - PNG_QUANTIZE_GREEN_BITS)) &
src/Source/LibPNG/pngrutil.c view on Meta::CPAN
/* TODO: at present png_decompress_chunk imposes a single application
* level memory limit, this should be split to different values for iCCP
* and text chunks.
*/
if (png_decompress_chunk(png_ptr, length, keyword_length+2,
&uncompressed_length, 1/*terminate*/) == Z_STREAM_END)
{
png_text text;
/* It worked; png_ptr->read_buffer now looks like a tEXt chunk except
* for the extra compression type byte and the fact that it isn't
* necessarily '\0' terminated.
*/
buffer = png_ptr->read_buffer;
buffer[uncompressed_length+(keyword_length+2)] = 0;
text.compression = PNG_TEXT_COMPRESSION_zTXt;
text.key = (png_charp)buffer;
text.text = (png_charp)(buffer + keyword_length+2);
text.text_length = uncompressed_length;
src/Source/LibTIFF4/tif_getimage.c view on Meta::CPAN
if (img->bitspersample == 8)
break;
/* fall thru... */
case PHOTOMETRIC_MINISBLACK:
case PHOTOMETRIC_MINISWHITE:
if (!setupMap(img))
return (0);
break;
case PHOTOMETRIC_PALETTE:
/*
* Convert 16-bit colormap to 8-bit (unless it looks
* like an old-style 8-bit colormap).
*/
if (checkcmap(img) == 16)
cvtcmap(img);
else
TIFFWarningExt(img->tif->tif_clientdata, TIFFFileName(img->tif), "Assuming 8-bit colormap");
/*
* Use mapping table and colormap to construct
* unpacking tables for samples < 8 bits.
*/
src/Source/LibWebP/README view on Meta::CPAN
Advanced encoding API:
----------------------
A more advanced API is based on the WebPConfig and WebPPicture structures.
WebPConfig contains the encoding settings and is not tied to a particular
picture.
WebPPicture contains input data, on which some WebPConfig will be used for
compression.
The encoding flow looks like:
-------------------------------------- BEGIN PSEUDO EXAMPLE
#include <webp/encode.h>
// Setup a config, starting form a preset and tuning some additional
// parameters
WebPConfig config;
if (!WebPConfigPreset(&config, WEBP_PRESET_PHOTO, quality_factor))
return 0; // version error
src/Source/OpenEXR/Copyrights/ilmbase/README.win32 view on Meta::CPAN
The source will build under both Visual Studio versions 7 and 8, and
there are separate directories for the corresponding build files. The
tag <vc7|8> is used in this document to describe the appropriate folder
in the path that corresponds to your the version of Visual Studio.
The Visual Studio project files assume, and help build out, a directory
called "Deploy". In the end, this directory will contain the objects
that might then be moved away from the source for general running of the
compiled programs. The directory structure at the end of compiling all
the related tools looks like this:
Deploy
include
lib
Debug
Release
bin
Debug
Release
openexr-cvs (name as desired)
src/Source/OpenEXR/Copyrights/openexr/ChangeLog view on Meta::CPAN
(chromaticities, luminance, comments, etc.).
(Florian Kainz, Greg Ward, Joseph Goldstone)
* Fixed a buffer overrun in ImfOpaqueAttribute. (Paul Schneider)
* Added new function, isImfMagic (). (Florian Kainz)
Version 1.0.6:
* Added README.win32 to disted files.
* Fixed OpenEXR.pc.in pkg-config file, OpenEXR now works
with pkg-config.
* Random fixes to readme files for new release.
* Fixed openexr.m4, now looks in /usr by default.
* Added Visual Studio .NET 2003 "solution."
* Fixes for Visual Studio .NET 2003 w/ Microsoft C++ compiler.
(Various)
* Random Imath fixes and enhancements. Note that
extractSHRT now takes an additional optional
argument, see ImathMatrixAlgo.h for details. (Various)
* Added Wojciech Jarosz to AUTHORS file.
* Added test cases for uncompressed case, preview images,
frame buffer type conversion. (Wojciech Jarosz,
Florian Kainz)
src/Source/OpenEXR/IlmImf/ImfDwaCompressor.cpp view on Meta::CPAN
(block[dctComp+runLen].bits() == rleSymbol))
{
runLen++;
}
//
// If the run len is too small, just output verbatim
// otherwise output our run token
//
// Originally, we wouldn't have a separate symbol for
// "end of block". But in some experimentation, it looks
// like using 0xff00 for "end of block" can save a bit
// of space.
//
if (runLen == 1)
{
runLen = 1;
*acPtr++ = block[dctComp].bits();
_numAcComp++;
src/Source/OpenEXR/IlmImf/ImfDwaCompressorSimd.h view on Meta::CPAN
//
// 0 1 2 3 4 5 6 7 0 1 5 6 14 15 27 28
// 8 9 10 11 12 13 14 15 2 4 7 13 16 26 29 42
// 16 17 18 19 20 21 22 23 3 8 12 17 25 30 41 43
// 24 25 26 27 28 29 30 31 9 11 18 24 31 40 44 53 (A)
// 32 33 34 35 36 37 38 39 --> 10 19 23 32 39 45 52 54
// 40 41 42 43 44 45 46 47 20 22 33 38 46 51 55 60
// 48 49 50 51 52 53 54 55 21 34 37 47 50 56 59 61
// 56 57 58 59 60 61 62 63 35 36 48 49 57 58 62 63
//
// Which looks like a mess, right?
//
// Now, check out the NE/SW diagonals of (A). Along those lines,
// we have runs of contiguous values! If we rewrite (A) a bit, we get:
//
// 0
// 1 2
// 5 4 3
// 6 7 8 9
// 14 13 12 11 10
// 15 16 17 18 19 20
src/Source/OpenEXR/IlmImf/ImfDwaCompressorSimd.h view on Meta::CPAN
const float f = .5f * cosf (3.f*3.14159f / 8.0f);
const float g = .5f * cosf (7.f*3.14159f / 16.0f);
float alpha[4], beta[4], theta[4], gamma[4];
float *rowPtr = NULL;
//
// First pass - row wise.
//
// This looks less-compact than the description above in
// an attempt to fold together common sub-expressions.
//
for (int row = 0; row < 8 - zeroedRows; ++row)
{
rowPtr = data + row * 8;
alpha[0] = c * rowPtr[2];
alpha[1] = f * rowPtr[2];
alpha[2] = c * rowPtr[6];
src/Source/OpenEXR/Imath/ImathFrustum.h view on Meta::CPAN
#include "IexMathExc.h"
IMATH_INTERNAL_NAMESPACE_HEADER_ENTER
//
// template class Frustum<T>
//
// The frustum is always located with the eye point at the
// origin facing down -Z. This makes the Frustum class
// compatable with OpenGL (or anything that assumes a camera
// looks down -Z, hence with a right-handed coordinate system)
// but not with RenderMan which assumes the camera looks down
// +Z. Additional functions are provided for conversion from
// and from various camera coordinate spaces.
//
// nearPlane/farPlane: near/far are keywords used by Microsoft's
// compiler, so we use nearPlane/farPlane instead to avoid
// issues.
template<class T>
class Frustum
( run in 0.552 second using v1.01-cache-2.11-cpan-64827b87656 )