More & More Fun w/ Pics & MySQL

[Neo]

Hi,

Victor Subervi schrieb:
> Let me clarify. This prints out "all sorts of crap", which means an
> image string, the image as a string, to the screen:
>  
> print 'Content-type: image/jpeg'
> print 'Content-Encoding: base64'
> print
> print pic().encode('base64')
> print '</body></html>'
>  
> The following once upon a time printed images, but now it doesn't. Why
> would that be? I would refresh the screen, and it would print. I'd
> change a line and it wouldn't. I'd change it back to what it was and it
> would no longer the image to the screen. Why is that? The same happens
> with or without the base64 stuff. Commenting out a line seemed to make a
> difference!
>  
> print 'Content-type: text/plain'
> #print 'Content-type: image/jpeg'
> print
> print pic()
> print '</body></html>'
> 
> The above prints out a broken image of correct dimensions.

Only with a broken client (I assume Internetexplorer here?)
Any you don't know what it does in guessing and caching (Try
shift-reload when you test things)

You should work from a static page and a static image and look what
is transferred by the server (wireshark or tcpflow are of great help,
but nc | hexdump -C | more is probably more easy if you work out the
HTTP protocol (see rfc2616)

You script needs to do the same as a server would do serving a static
resource. Just look how it works and rebuild it.

You will quickly find out, that there is obviously no reason to have
</body> </html> at the end of a binary resource an Image is.
Also correct mime type is important unless you deal with broken clients.

There are a lot more HTTP-Headers you want to understand and use but the
simple usage above, provided pic() indeed returns the binary data of the
image unaltered, should work (w/o the html crap at the end).
You would not use print since it adds a linefeed at the end which is not
part of the data. sys.stdout.write() should work better (and can be used
incremental to avoid returning the whole image data from memory)

> Of course I try and figure out how things work once they get working.
> Sometimes, however, there is __no__ logic to it __at__all__. Sorry.
> After years of struggling with python I've come to realize that even
> though I may not be a good programmer, it isn't me. It may not be python
> itself. It may be the crappy hardware the server farms use. It may be
> the way they tweak their python interpreter. But it isn't just me.

Sorry to tell you that but its just you. There is no magic in that.
Ok, there is one thing: what makes you sure the data in the database
is really unaltered image data? I mean, you are using mysql...
for a first thing I'd write the output into a file and try to open it
in a graphic viewer.

> It would be nice if I could get this code printing images to the screen
> as it was before I had to put out another unnecessary fire when code

Images are not "printed to screen" the whole idea is just wrong.

> that previously uploaded the images in the first place inexplicably no
> longer worked. Then, lo and behold, when I came back to this code that I
> hadn't touched and was working fine earlier this week, it no longer
> works. Lovely. My "plug-and-play" program has devoured two weeks of my
> time and I'm still up the creek without a paddle. Sure would appreciate
> any help you can give.

I see "plug and play" and read cargo-cult. You need to read a bit about
the basics on the matter or you will constantly run uphill - and even if
it seems to work it has no value if you don't know _why_.

Regards
Tino