POV-Ray : Newsgroups : povray.unofficial.patches : JPEG input/output for Pov 3.1e Server Time
3 Sep 2024 00:14:37 EDT (-0400)
  JPEG input/output for Pov 3.1e (Message 11 to 20 of 43)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: TonyB
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 07:38:00
Message: <3778A22F.DBA0C59F@panama.phoenix.net>
>   If povteam ever introduces JPG output into povray (let's hope not!)...

Please don't jinx it. I really want it. (At least the input, anyway).

--
Anthony L. Bennett
http://welcome.to/TonyB

Graphics rendered
by the Dreamachine.


Post a reply to this message

From: TonyB
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 07:39:34
Message: <3778A28D.CB93EAA6@panama.phoenix.net>
I personally use PGM for heightfields.

--
Anthony L. Bennett
http://welcome.to/TonyB

Graphics rendered
by the Dreamachine.


Post a reply to this message

From: Ken
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 10:28:58
Message: <3778D793.78B45C64@pacbell.net>
TonyB wrote:

> BTW, did you visit the site, and check out the other features? I really
> like the compressed file idea. For the distribution of scenes, it is very
> good. I would prefer ZIP or RAR compression, though, but that's just my
> two cents.

  I believe the compression method they are using was chosen so that
it would not have to rely on proprietary compression methods which would
require expensive licensing fees.

-- 
Ken Tyler

mailto://tylereng@pacbell.net


Post a reply to this message

From: PoD
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 13:26:36
Message: <3779032B.ADDE1EC3@merlin.net.au>
Ron Parker wrote:
> 
> On Mon, 28 Jun 1999 17:28:59 -0500, Mike <Ama### [at] aolcom> wrote:
> 
> >The long and short of it for me is that you will never get the
> >compression of JPEG out of PNG.  While LWZ compression can cut a file in
> >half, a JPEG file can reduce it by a factor of 10 or more without too
> >much artifacting.  If more projects like the IMP start to show up, some
> >kind of compression scheme is going to be essential.
> 
> PNG doesn't use LZW compression (no sane person would, these days).
> It uses Huffman compression, after performing a DCT to get the data
> into the frequency domain.

I thought that was what JPEG does and that PNG uses deflate without DCT.

PoD.


Post a reply to this message

From: Ron Parker
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 15:21:40
Message: <37791cc4@news.povray.org>
On Wed, 30 Jun 1999 03:02:27 +0930, PoD wrote:
>I thought that was what JPEG does and that PNG uses deflate without DCT.

Hm... you're right.  PNG can use filters before compression, but none of
them is a DCT.  I was sure I had read an article on PNG long ago in Dr. 
Dobbs' Journal that went into great detail about DCT.  I wish I still 
had the magazine.


Post a reply to this message

From: Jerry
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 18:36:10
Message: <jerry-2906991536100001@cerebus.acusd.edu>
In article <37791cc4@news.povray.org>, par### [at] fwicom wrote:
>Hm... you're right.  PNG can use filters before compression, but none of
>them is a DCT.  I was sure I had read an article on PNG long ago in Dr. 
>Dobbs' Journal that went into great detail about DCT.  I wish I still 
>had the magazine.

There are bunches of articles I wish I still had from DDJ. I've been
thinking about getting their CD-ROM. It goes back to 1998.
(http://www.ddj.com/)

Jerry


Post a reply to this message

From: Glen Berry
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 19:57:41
Message: <37792f9f.45060250@news.povray.org>
On 28 Jun 1999 17:08:09 -0400, par### [at] fwicom (Ron Parker) wrote:

>On Mon, 28 Jun 1999 15:40:10 -0400, TonyB wrote:
>>This is extremely cool. This MUST be included into POV-Ray 3.5 or 4.0
>>(or at least the SuperPatch). =)
>
>I'm generally opposed to JPEG output, because it's lossy.  Imagine
>if you just finished a 3-day render only to discover that the
>quality level on the output wasn't sufficient.  Who would you
>blame, yourself or the guy who chose the default quality level?

Anyone who used JPEG output for an important 3-day final render should
re-examine their motives for doing so. I wouldn't use JPEG output for
a situation like this. Anything that I devote 3 days of machine time
to, will be something that I place a high value on. Anything that I
place a high value on would usually be rendered in PNG, unless there
is some good reason not to use PNG in that particular case.

>I know *I* don't want that kind of support headache. 

One easy way to cut out almost all of the potential "uninformed user
support headache" is to have POV issue a warning statement something
like this: 

"Warning: This scene is being rendered to the JPEG image format to
reduce the image file size. Some noticeable image degradation might
occur. To avoid noticeable quality loss, either us a higher JPEG
Quality setting, or use an output image format other than JPEG."

> Besides, what does JPEG gain you that you can't get with PNG?


(1)
Smaller-than-PNG file sizes.  In many cases, MUCH smaller file sizes
can be attained using JPEG, instead of PNG. The smaller file size has
many possible advantages and potential applications.

This can be most helpful to someone with a large collection of
raytraced images. For critical archival storage of works with possible
commercial or historic value, PNG would be the better option. To be
realistic about the matter, most of us have several images which don't
fall into that category. I dare to say that most of us could place ALL
of our personal creations in the "non-critical" category, if our egos
would allow us to be honest about the issue.

I personally create a LOT of images that I consider "tests". Maybe I'm
refining a scene I'm working on, and would like to keep copies of the
different versions of the image I create during the creative process.
Sometimes I like to create reference images of objects or textures for
future reference. Many of my final scenes are not rendered in a
resolution adequate for quality printing to paper or film. They are
only fit for viewing on a computer screen. If I kept all these images
in PNG format, I would run out of hard disk space much faster. I seem
to always be running out of disk space as it is. Keeping everything in
PNG format would only make matters worse.

I personally reserve PNG for my favorite final renderings. All my
other pov images are archived in JPEG.


(2)
Much broader compatibility with other graphics programs. I know
several people who don't have graphics software that will open a PNG
file, but they do have graphics software that opens JPEG files. JPEG
is the most widely supported compressed image format.

(3)
JPEG is the preferred format of most people for webpage usage (for
photo realistic images.) If rendering images for the web, most people
will want to use JPEG instead of PNG. Even IRTC entries are
distributed in JPEG format. The vast majority of images on the
new.povray.org server are in JPEG format. People chatting on IRC who
want to share their latest POV-Ray creations with their friends will
usually transmit the file in JPEG format. Why not have the *option* of
rendering some of these images directly and not have to create them
with a separate image conversion program?



>On the other hand, using JPEG images as imagemaps, bumpmaps,
>and so on is a pretty good idea.

We certainly agree on this.

********************************************************************

Lastly, I want to say that all the opponents of JPEG output are acting
as if it were a proposed *replacement* for one of their favorite
image formats currently supported. Nothing is further from the truth.
JPEG output would be an *option* available to those users who desired
to use it. No one will make anyone render in JPEG. And quite frankly,
why should anyone care what format *someone else* renders their file
in? If it isn't your file, why on earth would you care? It will never
be the default output format. If someone uses it, it will be because
they *wanted* to do so. Who are we to tell them they shouldn't?

Later,
Glen Berry

IMP Vice Coordinator, and Communications Director
IMP Website: www.imp.org
My Website:  www.ezwv.com/~mclilith/index.html

Email:  7no### [at] ezwvcom
(remove the "7" to reply via personal email)


Post a reply to this message

From: Ken
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 20:09:17
Message: <37795FE8.C52537B7@pacbell.net>
Glen Berry wrote:

> Lastly, I want to say that all the opponents of JPEG output are acting
> as if it were a proposed *replacement* for one of their favorite
> image formats currently supported. Nothing is further from the truth.
> JPEG output would be an *option* available to those users who desired
> to use it. No one will make anyone render in JPEG. And quite frankly,
> why should anyone care what format *someone else* renders their file
> in? If it isn't your file, why on earth would you care? It will never
> be the default output format. If someone uses it, it will be because
> they *wanted* to do so. Who are we to tell them they shouldn't?
> 
> Later,
> Glen Berry

   If one is enthusiastic about using such a format one should also hear
what the possible disadvantages are in doing so. The voice of pro vs. con
is a powerful teacher and should not be ignored simply because it does
not support your own view. A discussion would not exist without more
than one participant. I don't think therefore I'm not ! A tree falls in
a forest but no one is there to hear it...


-- 
Ken Tyler

mailto://tylereng@pacbell.net


Post a reply to this message

From: TonyB
Subject: Re: JPEG input/output for Pov 3.1e
Date: 29 Jun 1999 20:18:55
Message: <37795481.FEE5A370@panama.phoenix.net>
I was not aware of that. Thank you for illuminating me. =)

--
Anthony L. Bennett
http://welcome.to/TonyB

Graphics rendered
by the Dreamachine.


Post a reply to this message

From: Glen Berry
Subject: Re: JPEG input/output for Pov 3.1e
Date: 30 Jun 1999 18:11:52
Message: <377c8e56.48790494@news.povray.org>
On Tue, 29 Jun 1999 17:08:08 -0700, Ken <tyl### [at] pacbellnet> wrote:

>   If one is enthusiastic about using such a format one should also hear
>what the possible disadvantages are in doing so. 

Fair enough. I have no problem with that. Since I can see value in the
patch, it's my place to enunciate the benefits of it for those that
might not have thought of them already. Those people that see
potential pitfalls in using the patch have the full right, and dare I
say, the social responsibility for speaking out about that as well.
Since I am doing my part, and the opponents of the patch are doing
their part by posting negative comments, you should be a happy man.

> The voice of pro vs. con is a powerful teacher and should not be ignored 
>simply because it does not support your own view.

Trust me, I wouldn't make that mistake. I have read all the negative
comments about the JPEG patch. I understand them. I also knew about
those issues before I read the posts here. I am not ignoring them.

> A discussion would not exist without more than one participant. 

That's another fairly obvious conclusion. That's why I am rallying
around having JPEG support in POV-Ray. It seemed that most of the
people were making negative comments about the idea. I was merely
attempting to "bring balance to the force" by showing the benefits of
the patch, and demonstrate that Nigel was not alone in his support of
JPEG.  Again, I would think that such balance would make you happy.

>I don't think therefore I'm not !

Well, that's you.   :)                             <just kidding>

> A tree falls in a forest but no one is there to hear it...

Except for these last two enigmatic, pseudo-psychological statements,
I don't see where we disagree at all. As for those last two lines,
these are rhetorical in nature anyway and don't expect to be answered.

It's nice to know that we agree on so many things.   :)

Later,
Glen Berry


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.