Hi everyone,
relative noob here :)

Just an observation I thought I'd share.

I have a TSU9600 with RFX9400 extender, controlling Samsung 46" LCD TV, Pioneer AVX2 receiver, Panasonic STB/PVR/DVD recorder and Windows MCE games machine.

I recently thought of having a go at the PoR (picture on remote). After hunting around my (seemingly) bottomless pit of odds-and-ends, I found an Hirschmann RVIP-T video IP tranmitter/receiver. oh, goody! that saves me a few $$. it also has a programmable 'transparent' RS-232 port that can be addressed from the IP end to send/receive code.

So I hooked it up to the network, used the serial cable to set the IP address, etc.

all good. Then I connected the browser (Netscape I still use is reliable), with the standard "http://RVIP.simonnet.net.au/snap.jpg" request, and I got a picture!!
too easy!, so I quickly cobbled together a PS to do the same thing, and it gave me a blank picture. So I frowned.

to cut a really long (3 weeks) story short, I grabbed an image in the browser, saved it to the hard drive, then manually inserted it into the PEPv2 xcf, and it worked fine.
Curiouser and curiouser I thought. In the end I determined that the RVIP-T was inserting an errant JPG header, with incorrect length tag.

I modified my PS to remove the bytes of the offending header. As the RVIP always gives the same header size, just the 6 bytes needed to be removed from each frame captured.

Now to the question - what does PEP do to an image when it is placed in the XCF, compared to retrieving the image directly from the IP source?

or

Is there a bug in the code of the Pronto firmware which fails to ignore "errant" JPG header codes? the JPg spec says it should be ignored, and browsers (and PEPv2) correctly ignore the bad header tag.

Thanks

Simon