 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
To the programmers,
I was very excited about the inclusion of JPEG image maps since I make
architectural models in a program that uses JPG textures. I have
written a conversion to use this as a 'front end' to POVray by using TGA
clones of my JPG textures.
My question is: Will the final version accept the file extension JPG
and JPEG? This would simplify my conversion and greatly reduce my hard
disk space due to multiple copies of the same texture in various
formats.
I love this new interface, Your efforts are GREATLY appreciated.
Thanks,
Dean
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 25 Sep 2001 21:10:05 -0600, Dean wrote:
>My question is: Will the final version accept the file extension JPG
>and JPEG? This would simplify my conversion and greatly reduce my hard
>disk space due to multiple copies of the same texture in various
>formats.
Are you saying it doesn't? I didn't think POV cared what the file
extension was.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Although, regardless of which *file* extension you use, you still say "jpeg"
in the source itself...
jpeg "mypic.jpeg"
or
jpeg "mypic.jpg"
someone correct me if I'm wrong; I certainly haven't been right the majority
of the time so far!
- Slime
[ http://www.teja.nu/slime/ ]
[ http://www.teja.nu/slime/images/ ]
"Ron Parker" <ron### [at] povray org> wrote in message
news:slr### [at] fwicom...
> On Tue, 25 Sep 2001 21:10:05 -0600, Dean wrote:
> >My question is: Will the final version accept the file extension JPG
> >and JPEG? This would simplify my conversion and greatly reduce my hard
> >disk space due to multiple copies of the same texture in various
> >formats.
>
> Are you saying it doesn't? I didn't think POV cared what the file
> extension was.
>
> --
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z
a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F
T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission
3-T}}}#end
> Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron
You are correct, POV will recognize either extension. The problem is with the
format of the jpg I am using.
Each file that failed would open in all other viewers I have but not in POVray.
Re-saving the JPG from the graphics program seemed to fix the read error but the
textures had errors 'corrupt JPEG data' X extraneous bytes before marker 0xdb.
The JPG textures had a section that was off set by about one unit between tiles.
Not sure yet if this is a bug or a mistake I made converting the texture. The
converted JPG still reads fine in the other program and renders OK in an Open GL
environment.
I will post a picture in the binaries forum under the same thread heading.
Thanks
Dean
Parker wrote:
> On Tue, 25 Sep 2001 21:10:05 -0600, Dean wrote:
> >My question is: Will the final version accept the file extension JPG
> >and JPEG? This would simplify my conversion and greatly reduce my hard
> >disk space due to multiple copies of the same texture in various
> >formats.
>
> Are you saying it doesn't? I didn't think POV cared what the file
> extension was.
>
> --
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
> Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dean <dea### [at] twoalphanet> a écrit dans le message :
3BB### [at] twoalphanet...
> Not sure yet if this is a bug or a mistake I made converting the
>texture. The converted JPG still reads fine in the other program and
>renders OK in an Open GL > environment.
--
There's a problem reading some JPEGs (and TIFFs) that produces the effects
you describe (and more, as some JPEGs can't be read at all) but AFAIK no
solution has yet been found for it. The only known workaround is to try
another painting software to produce the file.
G.
**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dean <dea### [at] twoalphanet> wrote:
: You are correct, POV will recognize either extension.
It's not that povray recognizes the extension. It's just that povray doesn't
care what the extension is. It can be .jpg, .jpeg, .myfancyimage or whatever
you wish.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks to all,
I made the JPG file work without errors by saving it from a program called
LView Pro for Windows 95. I set the file settings to be integer accurate and
to load this way. I think the Adobe Photoshop JPG that it was originally, was
made to load 'fast' and not accurate. I will experiment with this later today
and report back with more certainty.
Dean
Gilles Tran wrote:
> Dean <dea### [at] twoalphanet> a écrit dans le message :
> 3BB### [at] twoalphanet...
> > Not sure yet if this is a bug or a mistake I made converting the
> >texture. The converted JPG still reads fine in the other program and
> >renders OK in an Open GL > environment.
> --
>
> There's a problem reading some JPEGs (and TIFFs) that produces the effects
> you describe (and more, as some JPEGs can't be read at all) but AFAIK no
> solution has yet been found for it. The only known workaround is to try
> another painting software to produce the file.
>
> G.
>
> **********************
> http://www.oyonale.com
> **********************
> Graphic experiments
> Pov-ray gallery
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3BB1D33F.2C19078A@twoalpha.net> , Dean <dea### [at] twoalphanet>
wrote:
> I think the Adobe Photoshop JPG that it was originally, was
> made to load 'fast' and not accurate.
Yes, it is very possible that the problem is the "load fast", which probably
implies it is the progressive encoding version (i.e. when you download a
picture you first would see a low quality version that gets better as the
download progresses).
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <tra### [at] inapginrafr> a écrit dans le message news:
>
> There's a problem reading some JPEGs (and TIFFs) that produces the effects
> you describe (and more, as some JPEGs can't be read at all) but AFAIK no
> solution has yet been found for it. The only known workaround is to try
> another painting software to produce the file.
Maybe, before a solution is found, we could establish (trough our various
experiences) a list of software that writes jpeg's suitable for POV-Ray ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 26 Sep 2001 10:17:56 -0400, Thorsten Froehlich wrote:
>In article <3BB1D33F.2C19078A@twoalpha.net> , Dean <dea### [at] twoalphanet>
>wrote:
>
>> I think the Adobe Photoshop JPG that it was originally, was
>> made to load 'fast' and not accurate.
>
>Yes, it is very possible that the problem is the "load fast", which probably
>implies it is the progressive encoding version (i.e. when you download a
>picture you first would see a low quality version that gets better as the
>download progresses).
Progressive encoding isn't marker type 0xDB, though. Here's what the JPEG
FAQ has to say about various Photoshop incompatibilities:
Old decoders that don't handle progressive JPEG will often give rather
cryptic error messages when fed a progressive JPEG. If you get a complaint
like "Unsupported marker type 0xC2", then you definitely have a progressive
JPEG file and a non-progressive-capable decoder. (See part 2 of this FAQ
for information about more up-to-date programs.) Or you may get a generic
error message that claims the file is corrupted or isn't JPEG at all.
Adobe Photoshop and some other prepress-oriented applications will produce
four-channel CMYK JPEG files when asked to save a JPEG from CMYK image mode.
Hardly anything that's not prepress-savvy will cope with CMYK JPEGs (or any
other CMYK format for that matter). When making JPEGs for Web use, be sure
to save from RGB or grayscale mode.
Photoshop also has a habit of stuffing a rather large thumbnail/preview
image into an application-private segment of JPEG files. Some other
applications (notably early releases of Sun's Java library) are known to
choke on this data. This is definitely a bug in those other applications,
but the best available workaround is still to tell Photoshop not to save
a thumbnail. If you're putting up an image on the Web, having a thumbnail
embedded in it is just a waste of download time anyway.
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
First thing to know is, are there many persons suffering from
this? Right now, from what Thorsten and Ron just wrote, it
seems more of a mis-configured Photoshop than anything else.
If lot of people have such problems, it could be time for a
new entry in the VFAQ (along the lines "there are lots of
ways to write jpeg files, please try all the settings your
application has").
--
Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
Mes propos n'engagent que moi et en aucun cas mes employeurs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3BB### [at] sycomorefr> , Adrien Beau
<adr### [at] sycomorefr> wrote:
> First thing to know is, are there many persons suffering from
> this? Right now, from what Thorsten and Ron just wrote, it
> seems more of a mis-configured Photoshop than anything else.
> If lot of people have such problems, it could be time for a
> new entry in the VFAQ (along the lines "there are lots of
> ways to write jpeg files, please try all the settings your
> application has").
No, we actually have reports from other people with different programs that
also cause problem. The main reason it is so hard to fix is that POV-Ray
actually uses the same JPEG library almost all other free programs use (the
Independent JPEG group's library). So in theory there should be no problem
at all, but for some odd reason there is. I have a copy of the JPEG
standard somewhere, and if/when my time permits I do plan to look into it,
but not this week...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
fabien <fab### [at] skynetbe> a écrit dans le message :
3bb1e7bc$1@news.povray.org...
>
> Maybe, before a solution is found, we could establish (trough our various
> experiences) a list of software that writes jpeg's suitable for POV-Ray ?
Microsoft Image Composer : OK
Picture Publisher 8 : not OK
Painter Classic : OK
Gimp for Windows : OK if native, but not-OK files can stay that way even
when resaved.
There may be also some big commercial application not working because every
JPEG map I tested from Poser or DAZ3D is refused by Povray.
G.
--
**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 26 Sep 2001 10:56:09 -0400, Thorsten Froehlich wrote:
>In article <3BB### [at] sycomorefr> , Adrien Beau
><adr### [at] sycomorefr> wrote:
>
>> First thing to know is, are there many persons suffering from
>> this? Right now, from what Thorsten and Ron just wrote, it
>> seems more of a mis-configured Photoshop than anything else.
>> If lot of people have such problems, it could be time for a
>> new entry in the VFAQ (along the lines "there are lots of
>> ways to write jpeg files, please try all the settings your
>> application has").
>
>No, we actually have reports from other people with different programs that
>also cause problem. The main reason it is so hard to fix is that POV-Ray
>actually uses the same JPEG library almost all other free programs use (the
>Independent JPEG group's library). So in theory there should be no problem
>at all, but for some odd reason there is. I have a copy of the JPEG
>standard somewhere, and if/when my time permits I do plan to look into it,
>but not this week...
It might really be our problem. An image Gilles provided that refuses to parse
at all under POV works okay with djpeg. Here's what djpeg says in the debug
output:
Independent JPEG Group's DJPEG, version 6a 7-Feb-96
Copyright (C) 1996, Thomas G. Lane
Start of Image
JFIF APP0 marker, density 72x72 1
Skipping marker 0xed, length 4490
Skipping marker 0xe2, length 3160
Adobe APP14 marker: version 100, flags 0x8000 0x0000, transform 1
Define Quantization Table 0 precision 0
Define Quantization Table 1 precision 0
Start Of Frame 0xc0: width=932, height=933, components=3
Component 1: 2hx2v q=0
Component 2: 1hx1v q=1
Component 3: 1hx1v q=1
Define Restart Interval 59
Define Huffman Table 0x00
Define Huffman Table 0x01
Define Huffman Table 0x10
Define Huffman Table 0x11
Start Of Scan: 3 components
Component 1: dc=0 ac=0
Component 2: dc=1 ac=1
Component 3: dc=1 ac=1
Ss=0, Se=63, Ah=0, Al=0
End Of Image
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" wrote :
> Microsoft Image Composer : OK
> Picture Publisher 8 : not OK
> Painter Classic : OK
> Gimp for Windows : OK if native, but not-OK files can stay that way even
> when resaved.
Let me add :
XnView : OK
Corel Photo Paint 8 : OK
CompuPic Pro : OK
Microsoft Photo Editor (W2K) : OK
(all I had at hand at work, I'll test others at home).
P.S. : I see you are using Painter Classic. Does it mean you are the
lucky owner of some graphic tablet ? (I just bought a Wacom Intuos A5
myself).
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26 Sep 2001 11:12:33 -0400, Ron Parker wrote:
>It might really be our problem. An image Gilles provided that refuses to parse
>at all under POV works okay with djpeg. Here's what djpeg says in the debug
>output:
AHA!
It turns out that the skip routine is supposed to skip in the buffer as well
as in the file. I've just made a change that should fix this once and for
all (next beta, you know the drill...)
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> a écrit dans le message :
> It turns out that the skip routine is supposed to skip in the buffer as
well
> as in the file. I've just made a change that should fix this once and for
> all (next beta, you know the drill...)
Aaah, BIG thanks...
Now, since you're at it, what about this little thingy about TIFF files
being inverted in uv-maps :-) I know it's not top priority bug but still...
G.
--
**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery
>
> --
> #macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_
z)R(-z _-z)
> R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro
S(_)9-(_1-
> _)*(_1-_)#end#macro Z(_1 _
__)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
> rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate
x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 27 Sep 2001 17:54:38 +0200, Gilles Tran wrote:
>Ron Parker <ron### [at] povrayorg> a écrit dans le message :
>> It turns out that the skip routine is supposed to skip in the buffer as
>well
>> as in the file. I've just made a change that should fix this once and for
>> all (next beta, you know the drill...)
>
>Aaah, BIG thanks...
>Now, since you're at it, what about this little thingy about TIFF files
>being inverted in uv-maps :-) I know it's not top priority bug but still...
Just UV-maps, or everywhere? It seems that we ignore what the TIFF library
tells us about the orientation of the image. Whether that's something that'll
be easy to fix is anybody's guess, but it seems like it should affect more
than just UV maps.
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> a écrit dans le message :
> Just UV-maps, or everywhere? It seems that we ignore what the TIFF
library
> tells us about the orientation of the image. Whether that's something
that'll
> be easy to fix is anybody's guess, but it seems like it should affect more
> than just UV maps.
>
Yes, you're right. Regular mapping has to be inverted as well to work
properly. There's more, in fact, as even with the scaling <1,-1,1> is
applied as a workaround, the uv still doesn't look right (it's a mirror
image). Or is it a mesh2 problem ???
I posted a test scene in beta-test.binaries.
G.
--
**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery
> --
> plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip
x}rotate
> z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red
1rotate 60
> *z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb
z}text{ttf"arial.ttf"
> "RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron
Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
