>  However, if one chooses the wrong JPEG quality
> setting for (unofficial) POV-Ray output, there's not much they can do. You
> can't take an inferior image and make it better. For some people, we are
> talking anywhere from a few hours to a few days of rendering time that would
> be wasted.

The same could be said of choosing the wrong anti-aliasing, quality, or
radiosity settings.  As it is, you can set the output to 15-bit PNG.  That's
going to look bad too.

-Mike

Post a reply to this message

Mike wrote:
> 
> >  However, if one chooses the wrong JPEG quality
> > setting for (unofficial) POV-Ray output, there's not much they can do. You
> > can't take an inferior image and make it better. For some people, we are
> > talking anywhere from a few hours to a few days of rendering time that would
> > be wasted.
> 
> The same could be said of choosing the wrong anti-aliasing, quality, or
> radiosity settings.  As it is, you can set the output to 15-bit PNG.  That's
> going to look bad too.
> 
> -Mike

  At least it won't possibly maybe be compounded by the use of a more
worser badly image format type problem thing. There's that there stuff
to consider also too you know kind of.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Sat, 03 Jul 1999 00:45:54 -0500, Mike <Ama### [at] aolcom> wrote:

>The same could be said of choosing the wrong anti-aliasing, quality, or
>radiosity settings.  As it is, you can set the output to 15-bit PNG.  That's
>going to look bad too.

  Hi, Mike. Yes, there are a lot of ways to trash a perfectly good scene.
This is why I wouldn't introduce the JPEG quality setting 'guessing game' to
POV-Ray output when third-party JPEG conversion software is the fast,
simple, and painless solution to use *after* the render is done. And, I
would still have the original lossless 24-bit image in case I changed my
mind later.

-- 
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------

Post a reply to this message

Dear Alan,

<snip>
 I had written :

> >JPEG has positive points as well as negative points, why ignore
> >the positive ?

You (Alan Kong) replied :

>   I like JPEG. I use JPEG. A lot. But, for me personally, I prefer to output
> .png (PiNG) and then use my third-party software to convert the image to
> JPEG. I am free to experiment with the quality settings, as well as compare
> the JPEG output of Paint Shop Pro to CompuPic, in the search for the best
> result. It takes a matter of seconds (not hours or days) to convert a 1024w
> by 768h .png to JPEG of any quality, so I can check out a dozen image
> conversions very fast. However, if one chooses the wrong JPEG quality
> setting for (unofficial) POV-Ray output, there's not much they can do. You
> can't take an inferior image and make it better. For some people, we are
> talking anywhere from a few hours to a few days of rendering time that would
> be wasted.

<snip>

I do use PNG almost exclusively myself, then use third party tools to
convert/crop/rescale/... But there is a specific case where jpeg output might be
desirable :

Project :
The IMP (Internet Movie Project)

Characteristics :
- This project is distributed amongst many persons / many platforms.
- Output files are going to count in many thousands, maybe millions if you count
pre-renders, trashing some of it, error-correction game.

Business case :
Given the above characteristics integrating jpeg output to pov will bring the
following safeguards to our project (and possibly similar projects in the
future) :
- All platforms will get the exact same version of JPEG libraries, thus making
it for consistent output. If bad luck struck and a minor bug showed, it would
show everywhere, therefore it might not be as noticeable in the sequence of
images rendered by different platforms.
- JPEG settings will be chosen at POV level, thus reducing the risk of people
tweaking with them in external utilities - this will ensure better consistency
through out.
- When going for a render, it is not just a few images we are talking about, but
possibly hundreds in the one go. PNG could clog up disk space quickly, JPEG
would save the burden of disk space for much bigger renders.
- Implementing post scene commands could be an answer to the problem provided
such commands could be written in the same manner, which I believe is not the
case, for all platforms. Or maybe that is the way to go and implement different
ini files for different platforms, but we'd rather avoid that since JPEG can be
and has been integrated in some custom compile.
- On the large amount of files that will be generated, this will certainly save
us a bit of time, not much I would agree, but certainly some and everything
counts.

That's my own point of view and I appreciate others might not agree.
Cheers,
Al.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :

To answer me, please take out the Z from my address.

Post a reply to this message

I envision a scene: Somebody gets a couple of thousands of frames to
calculate in his computer and spends the next few weeks doing that just to
discover that the JPG's are too poor quality (perhaps caused by that big
red object over a light background...).
  A quality setting may be good for most frames, but I'm completely sure
that you can't use the same settings for all frames. There are pathologic
cases where you get artifacts no matter how much quality you set.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Wed, 07 Jul 1999 21:16:54 +0100, Alain CULOS <ZAl### [at] bigfootcom>
wrote:

>I do use PNG almost exclusively myself, then use third party tools to
>convert/crop/rescale/... But there is a specific case where jpeg output might be
>desirable :
>
>Project :
>The IMP (Internet Movie Project)

  For consistency's sake I can see why you would want a standardized output,
since so many individuals would be generating the frames.

>- JPEG settings will be chosen at POV level, thus reducing the risk of people
>tweaking with them in external utilities - this will ensure better consistency
>through out.

  This makes sense for this project. Artifacts from some frames not being
saved at the optimum quality setting will be less noticeable in an MPEG
animation as compared to a single image.

  I'm just not convinced that incorporating JPEG output into the official
POV-Ray is appropriate.

>That's my own point of view and I appreciate others might not agree.

  Respectfully, I must say the same thing :)

-- 
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------

Post a reply to this message

Alan Kong wrote:

> On Wed, 07 Jul 1999 21:16:54 +0100, Alain CULOS <ZAl### [at] bigfootcom>
> wrote:
>
> >I do use PNG almost exclusively myself, then use third party tools to
> >convert/crop/rescale/... But there is a specific case where jpeg output might be
> >desirable :
> >
> >Project :
> >The IMP (Internet Movie Project)
>
>   For consistency's sake I can see why you would want a standardized output,
> since so many individuals would be generating the frames.
>
> >- JPEG settings will be chosen at POV level, thus reducing the risk of people
> >tweaking with them in external utilities - this will ensure better consistency
> >through out.
>
>   This makes sense for this project. Artifacts from some frames not being
> saved at the optimum quality setting will be less noticeable in an MPEG
> animation as compared to a single image.
>

Actually, this is where for the IMP I would like to avoid JPEG. Taking a source
image through one lossy compression before going through another often degrades the
final quality and/or increases the file sizes. In early work producing MPEGs, this
was one of the things that actually did matter. The cleaner the sources, the better
the MPEG, and JPEG was to be avoided.

At some point, one person mentioned that Antz used JPEG compression on their frames
before storage. Probably the main difference is that Antz was going out to film
recorders while the IMP's output is most likely going to go out to MPEG.

Post a reply to this message

This is where Png comes in, I would say. A nearly flawless form of Jpeg
is going to be close to the same file size as the average Png, I would
hazard to guess. Or rather the difference becomes not so great and the
chance of a Jpeg becoming "lossy" is very real.


"Jon A. Cruz" wrote:
> 
> Alan Kong wrote:
> 
> > On Wed, 07 Jul 1999 21:16:54 +0100, Alain CULOS <ZAl### [at] bigfootcom>
> > wrote:
> >
> > >I do use PNG almost exclusively myself, then use third party tools to
> > >convert/crop/rescale/... But there is a specific case where jpeg output might be
> > >desirable :
> > >
> > >Project :
> > >The IMP (Internet Movie Project)
> >
> >   For consistency's sake I can see why you would want a standardized output,
> > since so many individuals would be generating the frames.
> >
> > >- JPEG settings will be chosen at POV level, thus reducing the risk of people
> > >tweaking with them in external utilities - this will ensure better consistency
> > >through out.
> >
> >   This makes sense for this project. Artifacts from some frames not being
> > saved at the optimum quality setting will be less noticeable in an MPEG
> > animation as compared to a single image.
> >
> 
> Actually, this is where for the IMP I would like to avoid JPEG. Taking a source
> image through one lossy compression before going through another often degrades the
> final quality and/or increases the file sizes. In early work producing MPEGs, this
> was one of the things that actually did matter. The cleaner the sources, the better
> the MPEG, and JPEG was to be avoided.
> 
> At some point, one person mentioned that Antz used JPEG compression on their frames
> before storage. Probably the main difference is that Antz was going out to film
> recorders while the IMP's output is most likely going to go out to MPEG.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

I think this is an awsome idea...

    In the way of image formats, png is one of my favorates, but i will
say that i like jpg for my (tiny) archive of images. I usually convert
my images to jpg after they are rendered. I must say though, that i have
had troubles in the past because my Xwindows was down and all my
conversion software is there. Also, zgv, my favorite viewer for the
linux console, doesn't read png format in all of it's color, it displays
it with 256 colors on my computer, jpg displays in 16 bit however,
making some of my test renders much easier to see problems or pitfalls
with. it's realy anoying when you spend a week rendering something, then
can't even view it because A. it's too big to fit on a disk or send by
internet, B. it only is viewable in 8bpp, C. the software on the closest
non-linux computer(my mom's... when i was at home) doesn't support png,
tga, ppm, uh, what other formats... it realy got anoying when this
happened, and it happened alot.
    Heightfields are not all that accurate to begin with, unless you are
using a program dedicated to building them(which i must say, i have not
found for linux(and i'm not sure if i want to, since i have the GIMP and
that does a fine job on them)). Unless you are making a map of a city
with accuracy to 1m, you shouldn't ever need the high accuracy. I've
also found in the past where i have had to erase 20 megs of usful stuff
on my computer to get the heightfield for a large scene to fit(i must
admit to using targa format at that time though)... but even now i've
found my large maps take up a huge chunk of my project-space.
    I do see the problems with newbi povray users selecting bad
values... but most newbi's use small scenes, i don't know any new users
that make scenes that take two weeks to render... it took me about half
a year before i started making things that would take any large amount
of time...
    IMO jpg input/output would be extreamly useful, i certainly would
use it, and i'm not sure why anyone would be bothered if it was added to
povray.

hope it is added myself, but even if it isn't, have fun all
     the Loial Raven

Post a reply to this message

Alan Kong wrote:

>   I'm just not convinced that incorporating JPEG output into the official
> POV-Ray is appropriate.

Well, if that's actually the concern and that is caused by the fact that careless
users might use the feature inadequately, why not implement it and very poorly
document it so only experienced users will have access to the feature (or only the
ones that really read the manual in its whole where proper disclaimers will be read
and understood), thus reducing chances of bad use.

Still trying to convince and find ways to get it through to official stage. The big
advantage of having it in the official version is of course to avoid having to
repatch every time one wants to upgrade to the latest official release + JPEG.

Cheers,
Alain.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :

To answer me, please take out the Z from my address.

Post a reply to this message