graphics in C to .jpg OR .bmp

[jt]

i think i was not clear in my quesiton.
my question actually was how to store a graphics image generated in C.

Eg.
#include<graphics.h>
void main()
{
int gm,gd=DETECT;
initgraph(&gd,&gm,"");
rectangle(50,50,200,300);
setcolor(1);
circle(150,150,50);
save();
}

now save function should store the image generated into a jpeg file.
i think i was not clear in my last post.
sorry for the inconvinience.
actually i'm doing a project which is similar to paint in windows.
i wanted to give save option in my project.
thank you
with regards JT

 

[Flash Gordon]

jt wrote, On 10/05/08 08:55:

i think i was not clear in my quesiton.
my question actually was how to store a graphics image generated in C.

Eg.
#include<graphics.h>

This is a non-standard header, and apart from making the logical
assumption that it is for some kind of graphics library I have literally
no idea what it does.

void main()

void main() is not standard. You should use
int main(void)

{
int gm,gd=DETECT;
initgraph(&gd,&gm,"");
rectangle(50,50,200,300);
setcolor(1);
circle(150,150,50);

Well, this presumable creates something in some format that the graphics
library you are using understands. However, none of the functions are
standard.

save();
}

now save function should store the image generated into a jpeg file.

People suggested some JPEG libraries, I suggest you look at them.
Someone also offered to email you some code.

i think i was not clear in my last post.
sorry for the inconvinience.
actually i'm doing a project which is similar to paint in windows.
i wanted to give save option in my project.

Nothing you have said here changes any of the earlier advice as far as I
can see.

Standard C does not provide for graphics or JPEG, so you need to either
roll your own or use a suitable third party library.

 

[Antoninus Twink]

#include<graphics.h> [snip]
save();

now save function should store the image generated into a jpeg file.

It seems extremely improbable that a save() function provided by a
graphics library a) would be called save() and b) would take no
arguments (path-name, overwrite?, format, format options, etc. probably
need to be supplied - not to mention a pointer to the image to be
saved!).

Checking the documentation for the library would be a good idea.

 

[Bart]

i think i was not clear in my quesiton.
my question actually was how to store a graphics image generated in C.

Eg.
#include<graphics.h>
void main()
{
int gm,gd=DETECT;
initgraph(&gd,&gm,"");
rectangle(50,50,200,300);
setcolor(1);
circle(150,150,50);
save();

}

now save function should store the image generated into a jpeg file.
i think i was not clear in my last post.
sorry for the inconvinience.
actually i'm doing a project which is similar to paint in windows.
i wanted to give save option in my project.
thank you
with regards JT

Perhaps jpeg is not the best choice. It's hellishly complicated, and
even if you use a library, doesn't work well with computer generated
images.

You mentioned BMP, which is reasonably straightforward, and there are
a few others.

First you need the image data is some memory-accessible format. And
you need to know exactly how the pixel data is arranged, before
converting to the file format.

Look for graphics or image file formats.

If you only need to reload the file into your own program, then it's
possible all you need to do is save the binary data directly to a
file, with some way of storing/deriving the image and pixel
dimensions.

 

[cr88192]

Firstly you need to grab the drawing area as an array of rgb values. This
can be done by iteratively calling a function with a name like getpixel()
or similar - I am not familiar with your particular graphics package.

I think I recognize it...

I think it is some Borland specific graphics interface (I think I remember
it being available with their older DOS-based compilers, don't know if it is
still maintained, or has been cloned...).


my opinion:
this is not likely the way I would do graphics;
usually, if I am doing any kind of raster graphics, I usually use a big flat
array which I can draw into directly;
as needed, this framebuffer can be drawn in whatever way is useful, or can
be saved to a file or whatever (explicit framebuffers are far more general
and flexible than some special-purpose graphics library).

in my case, I usually use OpenGL, so glWritePixels is good for raw display,
or the image can be loaded into a texture (much more common IME), or
compressed and saved out (very often if I am drawing into images directly,
they are for some special task, such as serving as lightmaps, ... so, they
are usually created and stored out).

Once you've done that, grap my savejpeg.c program from my website and
simply call with the raster, the name of the file you wish to create, and
the image dimensions. You'll proably want to fiddle with the code to give
control over the compression ratio.

yeah.


in my case, I had used a floating point value for controlling the quality
level, and a special set of algos for analyzing the DCT blocks and comming
up with a good set of quantizer values (at the time, I beat them together
experimentally, and this worked acceptably).


for my higher-speed compressor, I think I had an algo that came up with
quantizers for a particular quality level, which was based on more or less a
hand-tuned set of exponential equations (linear, square, and cubic factors).

this was faster in that it did not involve scanning over the blocks, but had
a worse quality/ratio tradeoff as a reult of it being that the quantizers
were not really tuned to the image.

I think scaling a fixed table of quantizer values is also possible, but IME
does not really produce as good of results (the ideal relation between the
components at various quality levels does not seem to be strictly linear).


also possible would be to add a function to search for the best quality
setting to produce a given sized output (would be useful in allowing setting
particular bitrates for MJPEG files, ...).


or such...

 

[cr88192]

Perhaps jpeg is not the best choice. It's hellishly complicated, and
even if you use a library, doesn't work well with computer generated
images.

this is always a little of an ammusing misnomer IMO...

what jpeg does bad with, is not "computer generated images", per se, but
images with lots of harsh points or edges...

for example, if you have the output of scene rendered in a raytracer (or for
that matter, a game screenshot), usually these compress fairly effectively
with JPEG, despite their being "computer generated".


PNG is another format, which is technically, a lot simpler to implement than
JPEG, and still compresses fairly effectively. it is lossless, however, so
files will tend to be a little larger than JPEG (this depends heavily on the
particular image though, for example, PNG handles things like monochromatic
regions, harsh edges, and patterns very well).

libpng exists and may also be a reasonable option here.

You mentioned BMP, which is reasonably straightforward, and there are
a few others.

TGA is also fairly common, and is actually a simpler format than BMP.
both TGA and BMP are fairly simple formats though...

TGA can also optionally use RLE compression...

First you need the image data is some memory-accessible format. And
you need to know exactly how the pixel data is arranged, before
converting to the file format.

Look for graphics or image file formats.

seconded, BMP and TGA can be looked into as simple examples (code for
loading and saving them can also be beaten together fairly easily).

if one is dealing with 8 bit graphics, PCX may also be an option.

If you only need to reload the file into your own program, then it's
possible all you need to do is save the binary data directly to a
file, with some way of storing/deriving the image and pixel
dimensions.

could be a reasonable option, but if one is going to use any header, may as
well be something like a TGA header, at least so that the files can be
opened in existing apps...