is image output direct to jpg going to be an option in the next release 
of povray?

Post a reply to this message

Marty <1@1.1> wrote:
> is image output direct to jpg going to be an option in the next release 
> of povray?

  Why should it be?

  There are many reasons why it's not and never will be supported as
an output file type.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Marty" <1@1.1> wrote in message news:3fa7946f$1@news.povray.org...
> is image output direct to jpg going to be an option in the next release
> of povray?
>

Jpeg is a lossy format - not only is it not ideal for the original image on
those grounds, but the way the format works probably means that it is impossible
to render to a jpeg (since you would have to now the values of pixels not yet
calculated when writing to the format).

Just out of curiosity, and apart from the colour depth issue, wouldn't gif have
similiar problems?

Post a reply to this message

> but the way the format works probably means that it is impossible
> to render to a jpeg (since you would have to now the values of pixels not yet
> calculated when writing to the format).

	Not "impossible" -> buffers.

	Most other image formats are compressed, which means to know also
"in advance" some amount of pixels before encoding them efficiently into
a compressed form (but it's probably simplier than in the case of JPEG
which uses macroblocks, i.e. image area).

	Anyway, I completely agree that outputing a CG image to JPEG
is completely non-sense (for backup purpose I mean). Moreover, the
JPEG compression algorithms are designed for real-life photographs
(for which loosing colors and precision in details can be acceptable
to a certain extend).

	- NC

Post a reply to this message

"Nicolas Calimet" <pov### [at] freefr> wrote in message
news:3FA### [at] freefr...
> > but the way the format works probably means that it is impossible
> > to render to a jpeg (since you would have to now the values of pixels not
yet
> > calculated when writing to the format).
>
> Not "impossible" -> buffers.
>

Heh - well, it ought to be pretty straightforward to add a post command to run
some image conversion app. on the bitmap as a quick solution.

Good point though - does pov output to PNG require buffering?

Post a reply to this message

On Tue, 4 Nov 2003 15:04:50 -0000, "Tom Melly" <tom### [at] tomandlucouk>
wrote:

>Good point though - does pov output to PNG require buffering?

From what I remember from playing with pnglib, there are two options
of saving a png file -- line-at-once and image-at-once, the latter
offering better overall compression. Since POV-Ray buffers each line
anyway, it's using the first method.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Marty wrote:
>is image output direct to jpg going to be an option in the next release
>of povray?
>

I thought this would be a good idea for a couple of reasons. The first is
that I'm under the impression a jpg can be compressed yet still maintain
the same quality as bmp type file.  This is because I'm assuming;
a) Default quality of a jpg is 80% (100% would be our bmp formated file)
b) each pixel of a jpg indexes a  rgb color map (assuming multi toned)
c) some pixels will have the same rgb value, so they use the same index to
of the color map and that's why the jpg can be compressed, smaller in size
than a bmp file.  Ideally there would be an option  for the quality of a
jpg.

I also thought since it's so widely used it would make POVRAY that much more
user friendly.  For instance I've found bmp's to be much more problematic
for web pages.  Many of us have learned how to convert file formats but I
remember starting out that it was one more hurdle that I had to get around.
  Tony

Post a reply to this message

In article <web.3faef3a6513875ff5cd9832d0@news.povray.org>,
 "Tony LaVigne" <ton### [at] xenomechanicscom> wrote:

> I thought this would be a good idea for a couple of reasons. The first is
> that I'm under the impression a jpg can be compressed yet still maintain
> the same quality as bmp type file.  This is because I'm assuming;
> a) Default quality of a jpg is 80% (100% would be our bmp formated file)

Even a 100% JPEG loses information. JPEG2000 does allow lossless 
compression, however.


> b) each pixel of a jpg indexes a  rgb color map (assuming multi toned)

Incorrect. JPEG is not an indexed format.


> c) some pixels will have the same rgb value, so they use the same index to
> of the color map and that's why the jpg can be compressed, smaller in size
> than a bmp file.  Ideally there would be an option  for the quality of a
> jpg.

Not even close. I suggest you look up some information about the JPEG 
format.


> I also thought since it's so widely used it would make POVRAY that much more
> user friendly.  For instance I've found bmp's to be much more problematic
> for web pages.  Many of us have learned how to convert file formats but I
> remember starting out that it was one more hurdle that I had to get around.

There is simply no reason to put Windows BMP files on the web. There is 
really no reason to use the format at all, IMO. The best formats for 
this purpose would be either PNG for lossless images, or hand-tuned JPEG 
for small file sizes with good quality. POV-Ray has the ability to 
output PNG as well as several other lossless formats, and it is best to 
hand tune the compression of JPEG files.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Wasn't it Tony LaVigne who wrote:
>Marty wrote:
>>is image output direct to jpg going to be an option in the next release
>>of povray?
>>
>
>I thought this would be a good idea for a couple of reasons. The first is
>that I'm under the impression a jpg can be compressed yet still maintain
>the same quality as bmp type file.  This is because I'm assuming;
>a) Default quality of a jpg is 80% (100% would be our bmp formated file)
>b) each pixel of a jpg indexes a  rgb color map (assuming multi toned)
>c) some pixels will have the same rgb value, so they use the same index to
>of the color map and that's why the jpg can be compressed, smaller in size
>than a bmp file.  Ideally there would be an option  for the quality of a
>jpg.
>
>I also thought since it's so widely used it would make POVRAY that much more
>user friendly.  For instance I've found bmp's to be much more problematic
>for web pages.  Many of us have learned how to convert file formats but I
>remember starting out that it was one more hurdle that I had to get around.

There is now support for lossless compression in the JPEG image format,
but there's very little support for it at the moment. In particular
Internet Explorer can't display lossless JPEGs, so don't use them on web
pages.

The concept of "100%" quality in the standard JPEG format is misleading,
it does not mean that the image is lossless. In the tests that I did, a
lossless JPEG tended to have a file size that was twice the size of a
"100% quality" JPEG, and there were differences in the images
particularly at sharp edges.

I'd suggest the use of PNG images. These are supported by all the major
web browsers, are lossless, and POVRay can output them.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

ton### [at] xenomechanicscom news:web.3faef3a6513875ff5cd9832d0@news.povray.org

> a) Default quality of a jpg is 80% (100% would be our bmp formated file)

Not true, since data in jpg are in different format (not color of each 
pixel, but type of wave reasembing collors of current 8x8 pixel block) more 
over - color is not RGB but in YUV format AFAIR

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message