POV-Ray : Newsgroups : povray.unofficial.patches : JPEG input/output for Pov 3.1e Server Time
3 Sep 2024 06:17:50 EDT (-0400)
  JPEG input/output for Pov 3.1e (Message 41 to 43 of 43)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Bob Hughes
Subject: Re: JPEG input/output for Pov 3.1e
Date: 8 Jul 1999 12:24:47
Message: <3784D0B2.44F61867@aol.com>
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

From: Loial Raven (Stuart MeerKat)
Subject: Re: JPEG input/output for Pov 3.1e
Date: 8 Jul 1999 15:14:22
Message: <3784F9E1.A0270274@yahoo.com>
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

From: Alain CULOS
Subject: Re: JPEG input/output for Pov 3.1e
Date: 10 Jul 1999 15:09:54
Message: <37866CD8.D2802CA1@bigfoot.com>
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

<<< Previous 10 Messages Goto Initial 10 Messages

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