 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nicolas Calimet" <pov### [at] free fr> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> 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.
Actually, the JPEG specification also allows a lossless compression, but
hardly anybody supports it. Of course, there would be no gain in compressed
result size over other formats. More to the contrary :-(
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3faef3a6513875ff5cd9832d0@news.povray.org> , "Tony LaVigne"
<ton### [at] xenomechanicscom> wrote:
> a) Default quality of a jpg is 80% (100% would be our bmp formated file)
The "percentage" most programs allows you to set says nothing. It is just
there for users. In any case, anything based on the Independent JPEP
Group's library (nearly all non-commercial programs, and many commercial
ones), the actually "default" giving you the quality JPEG was designed for
will be 75% iirc (it is documented in the source code docs of the library).
> b) each pixel of a jpg indexes a rgb color map (assuming multi toned)
By default JPEGs are not stored in RGB format but in YUV 4:2:0 format. I am
not aware of any program that allows you to write RGB, and there aren't many
which allow you to switch to 4:1:1, 4:2:2 or 4:4:4 format. Practically JPEG
supports a lot of variations in this regard. At least most programs can
actually read many of these variations.
> c) some pixels will have the same rgb value, so they use the same index to
The JPEG format is not indexed. It uses a lossy compression, which has
nothing to do with indexing.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3fb016bc$1@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Actually, the JPEG specification also allows a lossless compression, but
> hardly anybody supports it. Of course, there would be no gain in compressed
> result size over other formats. More to the contrary :-(
That's interesting...the pages I read about JPEG2000 implied that it was
a completely new addition. Looks like it about halves file sizes...PNG
is probably far better.
This page appears to have some good information:
http://www.faqs.org/faqs/jpeg-faq/part1/
Specifically, #13: "Isn't there a lossless JPEG?"
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
> That's interesting...the pages I read about JPEG2000 implied that it was
> a completely new addition. Looks like it about halves file sizes...PNG
> is probably far better.
> This page appears to have some good information:
> http://www.faqs.org/faqs/jpeg-faq/part1/
>
> Specifically, #13: "Isn't there a lossless JPEG?"
Indeed, this summarises it very well.
And actually, what it doesn't say is that you can actually create a
"lossless" baseline compliant JPEG. You "just" have to use adequate
quantisation tables (ones that don't drop any data). However, the catch is
that this would provide nothing but a very simple Huffman code based
compression...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
