/*
* Ordering of RGB data in scanlines passed to or from the application.
* If your application wants to deal with data in the order B,G,R, just
* change these macros. You can also deal with formats such as R,G,B,X
* (one extra byte per pixel) by changing RGB_PIXELSIZE. Note that changing
* the offsets will also change the order in which colormap data is organized.
* RESTRICTIONS:
* 1. The sample applications cjpeg,djpeg do NOT support modified RGB formats.
* 2. These macros only affect RGB<=>YCbCr color conversion, so they are not
* useful if you are using JPEG color spaces other than YCbCr or grayscale.
* 3. The color quantizer modules will not behave desirably if RGB_PIXELSIZE
* is not 3 (they don't understand about dummy color components!). So you
* can't use color quantization if you change that value.
*/
#define RGB_RED 0 /* Offset of Red in an RGB scanline element */
#define RGB_GREEN 1 /* Offset of Green */
#define RGB_BLUE 2 /* Offset of Blue */
#define RGB_PIXELSIZE 3 /* JSAMPLEs per RGB scanline element */
libjpeg를 일반적인 표준 Bitmap 파일에 적용하기 위해서는 (혹은 Blit 함수에) RGBQUAD나 RGBTRIPLE과 동일한 구조로 나오는 것이 좋다.
unsigned int scale_num, scale_denom
scale_num/scale_denom 의 분수비로 영상 비율을 조절합니다.
기본값은 1/1 혹은 조절하지 않음입니다.
현재, 지원되는 조정 비율은 1/1, 1/2, 1/4, 1/8 입니다.
(라이브러리 설계는 무제한의 비율이 가능하도록 되어있지만,
빠른시일내로 적용되기는 힘들것으로 보입니다.)
작은 조절 비율은 적은 수의 픽셀 연산과 단순화된 IDCT 방법을
사용 할 수 있기 때문에, 매우 빠른 속도의 변환을 합니다
(scale_num은 분자, scale_denom은 분모입니다. 만약에 1/4로 하려고 한다면 scale_num = 1; scale_denom = 4; 로 하면 될 듯 합니다
- 확인요망)
unsigned int scale_num, scale_denom
Scale the image by the fraction scale_num/scale_denom. Default is
1/1, or no scaling. Currently, the only supported scaling ratios
are 1/1, 1/2, 1/4, and 1/8. (The library design allows for arbitrary
scaling ratios but this is not likely to be implemented any time soon.)
Smaller scaling ratios permit significantly faster decoding since
fewer pixels need be processed and a simpler IDCT method can be used.
6. while (scan lines remain to be read)
jpeg_read_scanlines(...);
jpeg_read_scanlines()을 한번 혹은 여러번 호출함으로서 압축해제 된 영상정보를 읽을 수 있습니다.
각각의 호출시에, 읽을 최대 scanline을 넘겨줍니다
(예를들어, working buffer의 높이); jpeg_read_scanlines() 은
많은 줄들의 값을 돌려줄 것 입니다. 돌려준 값은 실제로 읽은 줄의 갯수입니다.
돌려받은 영상정보의 형태(format)는 위의 "Data formats"에 기술되어 있습니다.
흑백과 색상이 있는 JPEG는 서로 다른 데이터 형태라는 것을 잊지마십시오!
영상정보는 상-하 순서로 주어집니다. 만약에 하-상 순서로 영상정보를 저장해야 한다면,
효과적으로 JPEG 라이브러리의 가상 배열 방식을 사용하여 뒤집을 수 있습니다.
예제 프로그램인 djpeg에서 이러한 사용예를 찾으실 수 있습니다.
6. while (scan lines remain to be read)
jpeg_read_scanlines(...);
Now you can read the decompressed image data by calling jpeg_read_scanlines()
one or more times. At each call, you pass in the maximum number of scanlines
to be read (ie, the height of your working buffer); jpeg_read_scanlines()
will return up to that many lines. The return value is the number of lines
actually read. The format of the returned data is discussed under "Data
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
jpeg_read_scanlines() fills it. (The current implementation returns only a
few scanlines per call, no matter how large a buffer you pass.) So you must
always provide a loop that calls jpeg_read_scanlines() repeatedly until the
whole image has been read.
Data formats
픽셀들은 scanline 단위로 왼쪽에서 오른쪽 방향으로 저장됩니다
각각의 픽셀을 위한 값들은 열단위로 나란히 있습니다;
24-bit RGB 를 예를 들자면, R,G,B,R,G,B,R,G,B 순서로 되어있습니다. 각각의 scanline은
JSAMPLE 데이터 형의 배열로 되어있습니다 --- jmorecfg.h를 수정하지 않았다면,
일반적으로 "unsigned char" 입니다. (또한 jmorecfg.h를 수정함으로서
RGB 픽셀의 순서를 B,G,R 순서로 변경할수도 있습니다. 하지만 수정전에 제약사항을
먼저 읽어 보시기 바랍니다.)
Data formats
------------
Before diving into procedural details, it is helpful to understand the
image data format that the JPEG library expects or returns.
The standard input image format is a rectangular array of pixels, with each
pixel having the same number of "component" or "sample" values (color
channels). You must specify how many components there are and the colorspace
interpretation of the components. Most applications will use RGB data
(three components per pixel) or grayscale data (one component per pixel).
PLEASE NOTE THAT RGB DATA IS THREE SAMPLES PER PIXEL, GRAYSCALE ONLY ONE.
A remarkable number of people manage to miss this, only to find that their
programs don't work with grayscale JPEG files.
There is no provision for colormapped input. JPEG files are always full-color
or full grayscale (or sometimes another colorspace such as CMYK). You can
feed in a colormapped image by expanding it to full-color format. However
JPEG often doesn't work very well with source data that has been colormapped,
because of dithering noise. This is discussed in more detail in the JPEG FAQ
and the other references mentioned in the README file.
Pixels are stored by scanlines, with each scanline running from left to
right. The component values for each pixel are adjacent in the row; for
example, R,G,B,R,G,B,R,G,B,... for 24-bit RGB color. Each scanline is an
array of data type JSAMPLE --- which is typically "unsigned char", unless you've changed jmorecfg.h. (You can also change the RGB pixel layout, say
to B,G,R order, by modifying jmorecfg.h. But see the restrictions listed in
that file before doing so.)
int w = cinfo.image_width;
int h = cinfo.image_height;
int d = cinfo.jpeg_color_space;
int out_h = cinfo.output_height;
printf("width:%d height:%d depth:%d out_height:%d\n", w, h ,d, out_h);
unsigned char *data = new unsigned char[w * h * d];
while (cinfo.output_scanline < cinfo.output_height)
{
jpeg_read_scanlines(&cinfo, &data, 1);
data += d * cinfo.output_width;
}
jpeg_read_header() 한뒤
jpeg_read_scanline()까지는 알았지만, 문서를 대충 읽다 보니..
도무니 어떻게 메모리를 할당해야 할지 감이 안 잡혔는데..
이 문서를 보니 어떻게 하면 될꺼 같다라는 감이 조금은 온다.. 내일 해보고 결과를 적도록 해야겠다.
위에서 대로 전체 할당하고 jpeg_read_scanlines로 읽어 오니 잘된다!
Subject: [21] What if I need more than 8-bit precision?
Baseline JPEG stores images with 8 bits per color sample, in other words
24 bits per pixel for RGB images, 8 bits/pixel for grayscale, 32 bits/pixelfor CMYK, etc.
There is an extension that stores 12 bits/sample for applications that need higher accuracy.
Medical images, for example, are often 12-bit grayscale. The 12-bit extension is not very widely supported,
however. One package that does support it is the free IJG source code (see part 2, item 15).
For lossless JPEG, the standard permits any data precision between 2 and 16 bits per sample,
but high-precision lossless JPEG is even less widely supported than high-precision lossy JPEG.
The Stanford PVRG codec (see part 2, item 15) reportedly supports up to 16 bits/sample for lossless JPEG.
struct jpeg_decompress_struct {
jpeg_common_fields; /* Fields shared with jpeg_compress_struct */
/* Source of compressed data */
struct jpeg_source_mgr * src;
/* Basic description of image --- filled in by jpeg_read_header(). */
/* Application may inspect these values to decide how to process image. */
JDIMENSION image_width; /* nominal image width (from SOF marker) */
JDIMENSION image_height; /* nominal image height */
int num_components; /* # of color components in JPEG image */
J_COLOR_SPACE jpeg_color_space; /* colorspace of JPEG image */
/* image_width는 폭 image_height는 높이 그리고 num_components는 몇개의 색상이 있는지를 알려준다. * jpeg는 각 element당 8bit씩을 사용하고, RGB는 각 8bit * 3 = 24bits * Grayscale은 8bit * 1(단일색상) = 8bits 이런식으로 color depth를 계산하면 된다. */
/* Decompression processing parameters --- these fields must be set before
* calling jpeg_start_decompress(). Note that jpeg_read_header() initializes
* them to default values.
*/
J_COLOR_SPACE out_color_space; /* colorspace for output */ /* 윈도우에서 색대표라고 나오는 것이다. 출력시의 색상계를 의미함 */
unsigned int scale_num, scale_denom; /* fraction by which to scale image */
double output_gamma; /* image gamma wanted in output */
boolean quantize_colors; /* TRUE=colormapped output wanted */
/* the following are ignored if not quantize_colors: */
J_DITHER_MODE dither_mode; /* type of color dithering to use */
boolean two_pass_quantize; /* TRUE=use two-pass color quantization */
int desired_number_of_colors; /* max # colors to use in created colormap */
/* these are significant only in buffered-image mode: */
boolean enable_1pass_quant; /* enable future use of 1-pass quantizer */
boolean enable_external_quant;/* enable future use of external colormap */
boolean enable_2pass_quant; /* enable future use of 2-pass quantizer */
/* Description of actual output image that will be returned to application.
* These fields are computed by jpeg_start_decompress().
* You can also use jpeg_calc_output_dimensions() to determine these values
* in advance of calling jpeg_start_decompress().
*/
JDIMENSION output_width; /* scaled image width */
JDIMENSION output_height; /* scaled image height */
int out_color_components; /* # of color components in out_color_space */
int output_components; /* # of color components returned */
/* output_components is 1 (a colormap index) when quantizing colors;
* otherwise it equals out_color_components.
*/
int rec_outbuf_height; /* min recommended height of scanline buffer */
/* If the buffer passed to jpeg_read_scanlines() is less than this many rows
* high, space and time will be wasted due to unnecessary data copying.
* Usually rec_outbuf_height will be 1 or 2, at most 4.
*/
/* When quantizing colors, the output colormap is described by these fields.
* The application can supply a colormap by setting colormap non-NULL before
* calling jpeg_start_decompress; otherwise a colormap is created during
* jpeg_start_decompress or jpeg_start_output.
* The map has out_color_components rows and actual_number_of_colors columns.
*/
int actual_number_of_colors; /* number of entries in use */
JSAMPARRAY colormap; /* The color map as a 2-D pixel array */
/* State variables: these variables indicate the progress of decompression.
* The application may examine these but must not modify them.
*/
/* Row index of next scanline to be read from jpeg_read_scanlines().
* Application may use this to control its processing loop, e.g.,
* "while (output_scanline < output_height)".
*/
JDIMENSION output_scanline; /* 0 .. output_height-1 */
/* Current input scan number and number of iMCU rows completed in scan.
* These indicate the progress of the decompressor input side.
*/
int input_scan_number; /* Number of SOS markers seen so far */
JDIMENSION input_iMCU_row; /* Number of iMCU rows completed */
/* The "output scan number" is the notional scan being displayed by the
* output side. The decompressor will not allow output scan/row number
* to get ahead of input scan/row, but it can fall arbitrarily far behind.
*/
int output_scan_number; /* Nominal scan number being displayed */
JDIMENSION output_iMCU_row; /* Number of iMCU rows read */
/* Current progression status. coef_bits[c][i] indicates the precision
* with which component c's DCT coefficient i (in zigzag order) is known.
* It is -1 when no data has yet been received, otherwise it is the point
* transform (shift) value for the most recent scan of the coefficient
* (thus, 0 at completion of the progression).
* This pointer is NULL when reading a non-progressive file.
*/
int (*coef_bits)[DCTSIZE2]; /* -1 or current Al value for each coef */
/* Internal JPEG parameters --- the application usually need not look at
* these fields. Note that the decompressor output side may not use
* any parameters that can change between scans.
*/
/* Quantization and Huffman tables are carried forward across input
* datastreams when processing abbreviated JPEG datastreams.
*/
JQUANT_TBL * quant_tbl_ptrs[NUM_QUANT_TBLS];
/* ptrs to coefficient quantization tables, or NULL if not defined */
JHUFF_TBL * dc_huff_tbl_ptrs[NUM_HUFF_TBLS];
JHUFF_TBL * ac_huff_tbl_ptrs[NUM_HUFF_TBLS];
/* ptrs to Huffman coding tables, or NULL if not defined */
/* These parameters are never carried across datastreams, since they
* are given in SOF/SOS markers or defined to be reset by SOI.
*/
int data_precision; /* bits of precision in image data */
jpeg_component_info * comp_info;
/* comp_info[i] describes component that appears i'th in SOF */
UINT8 arith_dc_L[NUM_ARITH_TBLS]; /* L values for DC arith-coding tables */
UINT8 arith_dc_U[NUM_ARITH_TBLS]; /* U values for DC arith-coding tables */
UINT8 arith_ac_K[NUM_ARITH_TBLS]; /* Kx values for AC arith-coding tables */
unsigned int restart_interval; /* MCUs per restart interval, or 0 for no restart */
/* These fields record data obtained from optional markers recognized by
* the JPEG library.
*/
boolean saw_JFIF_marker; /* TRUE iff a JFIF APP0 marker was found */
/* Data copied from JFIF marker; only valid if saw_JFIF_marker is TRUE: */
UINT8 JFIF_major_version; /* JFIF version number */
UINT8 JFIF_minor_version;
UINT8 density_unit; /* JFIF code for pixel size units */
UINT16 X_density; /* Horizontal pixel density */
UINT16 Y_density; /* Vertical pixel density */
boolean saw_Adobe_marker; /* TRUE iff an Adobe APP14 marker was found */
UINT8 Adobe_transform; /* Color transform code from Adobe marker */ /* X_density, Y_density는 DPI 단위의 수평,수직 해상도를 나타낸다. */
boolean CCIR601_sampling; /* TRUE=first samples are cosited */
/* Aside from the specific data retained from APPn markers known to the
* library, the uninterpreted contents of any or all APPn and COM markers
* can be saved in a list for examination by the application.
*/
jpeg_saved_marker_ptr marker_list; /* Head of list of saved markers */
/* Remaining fields are known throughout decompressor, but generally
* should not be touched by a surrounding application.
*/
/*
* These fields are computed during decompression startup
*/
int max_h_samp_factor; /* largest h_samp_factor */
int max_v_samp_factor; /* largest v_samp_factor */
int min_DCT_scaled_size; /* smallest DCT_scaled_size of any component */
JDIMENSION total_iMCU_rows; /* # of iMCU rows in image */
/* The coefficient controller's input and output progress is measured in
* units of "iMCU" (interleaved MCU) rows. These are the same as MCU rows
* in fully interleaved JPEG scans, but are used whether the scan is
* interleaved or not. We define an iMCU row as v_samp_factor DCT block
* rows of each component. Therefore, the IDCT output contains
* v_samp_factor*DCT_scaled_size sample rows of a component per iMCU row.
*/
JSAMPLE * sample_range_limit; /* table for fast range-limiting */
/*
* These fields are valid during any one scan.
* They describe the components and MCUs actually appearing in the scan.
* Note that the decompressor output side must not use these fields.
*/
int comps_in_scan; /* # of JPEG components in this scan */
jpeg_component_info * cur_comp_info[MAX_COMPS_IN_SCAN];
/* *cur_comp_info[i] describes component that appears i'th in SOS */
JDIMENSION MCUs_per_row; /* # of MCUs across the image */
JDIMENSION MCU_rows_in_scan; /* # of MCU rows in the image */
int blocks_in_MCU; /* # of DCT blocks per MCU */
int MCU_membership[D_MAX_BLOCKS_IN_MCU];
/* MCU_membership[i] is index in cur_comp_info of component owning */
/* i'th block in an MCU */
int Ss, Se, Ah, Al; /* progressive JPEG parameters for scan */
/* This field is shared between entropy decoder and marker parser.
* It is either zero or the code of a JPEG marker that has been
* read from the data source, but has not yet been processed.
*/
int unread_marker;
u-boot에서 리눅스 커널로 bootargs를 넘겨주어 nfs를 연결할 경우, 기본값이면 UDP로 연결되게 된다.
mount로 확인해보면
# mount
rootfs on / type rootfs (rw)
/dev/root on / type nfs (rw,noatime,vers=2,rsize=4096,wsize=4096,hard,nolock,proto=tcp,timeo=600,retrans=2,addr=192.168.10.10)
proc on /proc type proc (rw)
/dev/sda1 on /root/sda1 type vfat (rw,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1)
Recommended Repository Layout
While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies,
and a tags directory to contain tag copies. For example:
$ svn list file:///var/svn/repos
/trunk
/branches
/tags
You'll learn more about tags and branches in Chapter 4, Branching and Merging. For details and how to set up multiple projects, see the section called “Repository Layout” and the section called “Planning Your Repository Organization” to read more about project roots.
You'll need the following build tools to compile Subversion:
* autoconf 2.58 or later (Unix only)
* libtool 1.4 or later (Unix only)
* a reasonable C compiler (gcc, Visual Studio, etc.)
Subversion also depends on the following third-party libraries:
* libapr and libapr-util (REQUIRED for client and server)
The Apache Portable Runtime (APR) library provides an
abstraction of operating-system level services such as file
and network I/O, memory management, and so on. It also
provides convenience routines for things like hashtables,
checksums, and argument processing. While it was originally
developed for the Apache HTTP server, APR is a standalone
library used by Subversion and other products. It is a
critical dependency for all of Subversion; it's the layer
that allows Subversion clients and servers to run on
different operating systems.
* SQLite (REQUIRED for client and server)
Subversion uses SQLite to manage some internal databases.
* libz (REQUIRED for client and server)
Subversion uses zlib for compressing binary differences.
These diff streams are used everywhere -- over the network,
in the repository, and in the client's working copy.
* libserf (OPTIONAL for client)
The Serf libraries both allow the Subversion client
to send HTTP requests. This is necessary if you want your
client to access a repository served by the Apache HTTP
server. There is an alternate 'svnserve' server as well,
though, and clients automatically know how to speak the
svnserve protocol. Thus it's not strictly necessary for your
client to be able to speak HTTP... though we still recommend
that your client be built to speak both HTTP and svnserve
protocols.
* OpenSSL (OPTIONAL for client and server)
OpenSSL enables your client to access SSL-encrypted https://
URLs (using libserf) in addition to unencrypted http:// URLs.
To use SSL with Subversion's WebDAV server, Apache needs to
be compiled with OpenSSL as well.
* Berkeley DB (OPTIONAL for client and server)
There are two different repository 'back-end'
implementations. One implementation stores data in a flat
filesystem (known as FSFS); the other implementation stores
data in a Berkeley DB database (known as BDB). When you
create a repository, you have the option of specifying a
storage back-end. The Berkeley DB back-end will only be
available if the BDB libraries are discovered at compile
time.
* libsasl (OPTIONAL for client and server)
If the Cyrus SASL library is detected at compile time, then
the svn client (and svnserve server) will be able to utilize
SASL to do various forms of authentication when speaking the
svnserve protocol.
* Python, Perl, Java, Ruby (OPTIONAL)
Subversion is mostly a collection of C libraries with
well-defined APIs, with a small collection of programs that
use the APIs. If you want to build Subversion API bindings
for other languages, you need to have those languages
available at build time.
* KDELibs, GNOME Keyring (OPTIONAL for client)
Subversion contains optional support for storing passwords in
KWallet (KDE 4) or GNOME Keyring.
To create a new Subversion repository by converting an existing CVS repository, run the script like this: $ cvs2svn --svnrepos NEW_SVNREPOS CVSREPOS
To create a new Subversion repository containing only trunk commits,
and omitting all branches and tags from the CVS repository, do
$ cvs2svn --trunk-only --svnrepos NEW_SVNREPOS CVSREPOS
To create a Subversion dumpfile (suitable for 'svnadmin load') from a CVS repository, run it like this:
$ cvs2svn --dumpfile DUMPFILE CVSREPOS
To use an options file to define all of the conversion parameters, specify --options:
$ cvs2svn --options OPTIONSFILE
As it works, cvs2svn will create many temporary files in a temporary
directory called "cvs2svn-tmp" (or the directory specified with
--tmpdir). This is normal. If the entire conversion is successful,
however, those tempfiles will be automatically removed. If the
conversion is not successful, or if you specify the '--skip-cleanup'
option, cvs2svn will leave the temporary files behind for possible
debugging.
cvs2svn은 cvs 리파지터리를 svn으로 변환해주는 툴이다.
변환과정중에 하나라도 잘못된 ,v 파일(cvs의 history 파일)이 있으면 중지되고,
한글을 사용했을 경우, encoding 문제로 인해서 pass 2에서 문제가 발생한다.
ERROR: There were warnings converting author names and/or log messages
to unicode (see messages above). Please restart this pass
with one or more '--encoding' parameters or with '--fallback-encoding'.
$ man cvs2svn --encoding=encoding
Use encoding as the encoding for filenames, log messages, and
author names in the CVS repos. This option may be specified mul-
tiple times, in which case the encodings are tried in order until
one succeeds. Default: ascii. See
http://docs.python.org/lib/standard-encodings.html for a list of
other standard encodings.
--fallback-encoding=encoding
If none of the encodings specified with --encoding succeed in
decoding an author name or log message, then fall back to using
encoding in lossy 'replace' mode. Use of this option may cause
information to be lost, but at least it allows the conversion to
run to completion. This option only affects the encoding of log
messages and author names; there is no fallback encoding for
filenames. (By using an --options file, it is possible to spec-
ify a fallback encoding for filenames.) Default: disabled.
