World: r3wp

If yes, then you could make a thumbnail algorithm in plain C and 
build your own dll. Calculating each pixel in the thumbnail as a 
mean value of a number of pixels in the original image should give 
a nice result, I think.

For Lanczos filter, I find it even slow with NConvert for bigger 
images (1MB+), but I guess that the CALL overhead is significant 
there.

I thought about it but don't have enough free time to implement it 
myself. Btw passing image! datatype through a routine! is quite tricky 
IIRC?

with proper thumbnailing in r2, you are good on the way to implement 
a photo album browser. as it is now, that's not possible.

Oh, I forgot that the server it's running on has a mono-core Atom 
as CPU! Speed should be ok starting from a mid-level CPU.

I haven't got experience with routine! calls, so I can't say. A way 
to get the data to the C code is to save it on disk as BMP from REBOL 
first. If you need really high speed, this might not do it for you 
though.

Or in stead of BMP, just save it as binary. (Which is about the same, 
I guess.)

Now I'm in doubt of the correct term. Is it still called bilinear 
filtering (which is bilinear interpolation), when scaling down? I 
mean, we're not doing interpolation then, but instead calculating 
mean values.

I think the correct term is 'filter with resampling'. If you add 
the resampling step then the image looks much beter. Then different 
filter algorithms can even improve the quality (usually the beter 
filter the slower the calcualtion is)

R2 Draw is currently using only 'resizing' not 'resampling' routine.

Doc - I am good at bugging anyone, so just confirm you want it :-)

Doc - nconvert is an exe, but xnview package has complete API to 
wrap. We even did some basic stuff in the past with Cyphre ...

but Image Magick is probably more popular, dunno ..

Thumbnailing is very marketable. With what REBOL has, and could have 
without too much effort, we could target the 5% most used ImageMagick 
functions and create an alternative.

the issue being that image magic does things incredibly fast.  its 
a library with its origins in very high-end visual effects, and is 
used massively by that industry.

but for stuff like web sites... an encaped and purposed-build view 
could be viable, if a few filters added a bit more quality/options 
to their mantle.

and a few other image formats too.  (image magic loads/saves more 
than 100)

Pekr: I would like to have that feature, but workarounds exists. 
If Carl has to spend time on R2, I prefer him working on fixes for 
long standing native bugs instead.

We could certainly use a save/jpg option.  That's gotta be a longstanding 
request by many.

Nick, IIRC, /jpg will make REBOL about 100kB larger, that's why it's 
not there. If you know about smaller JPEG saver, I think it may be 
included.

http://rebol.wik.is/Rebol3/Schemes/Imap4
Updated to version 0.0.2 
Logs into Imap server using cram-md5 if available
Switches to inbox
gets inbox status for unseen messages
Retrieves the first 3 messages

ooop ... wrong channel ...

now that we have ssl in view (woot) can we access gmail's api?

What api ?

Rebolek, like many other options, things like save/jpg may not need 
to be included in the default slim installation of REBOL, but I'm 
sure there are many users who would love to have the option of downloading 
a 100k+ library, function, plugin, etc. to easily enable this functionality. 
 I don't care if I have to download and do some code, that's trivial 
- just having the option available would be phenomenal.

I've seen some email stuff somewhere.. here's the google calendar 
api


http://code.google.com/apis/calendar/data/1.0/developers_guide_php.html

Here's a Gmail notifier app for Firefox, so it must be doable.

libgmail is a Python binding to gmail

http://libgmail.sourceforge.net/

and php script via imap

http://php.net/manual/en/function.imap-open.php


Works with Gmail's new IMAP function for personal and for Google 
Apps.


$mbox = imap_open ("{imap.gmail.com:993/imap/ssl}INBOX", "[username-:-gmail-:-com]", 
"password")
     or die("can't connect: " . imap_last_error());

That's not an API ...

That's just imap

like, whatever

now that we have ssl in view (woot) can we access gmail's via IMAP?

sure if you modify the r2 imap protocol to use ssl

hmm.. sounds like hooking up to another PHP as proxy

can use a ws socket or whatever, and skip opening port 993 on the 
client as well.

Nick, then you use things like ImageMagick, there's a script to support 
it on rebol.org and I have an improved version somewhere on my HDD,if 
you're interested.

I am actually.  :-)

Does 2.7.7.3.1 not have the /async argument for open?

Nevermind


The /async was removed a while ago. If you want to use async, you'll 
have to use Gabriele and others' async protocols

Rebolek, then we need 12 Megs insteac of 100k :(  ... but I am still 
interested in your improved version :)

insteac -> instead

when using the REQUEST-FILE function anyone know how to prevent rebol 
from adding its own filters?


I'm specifying one, and it adds REBOL, *.*, and images... but its 
a stupid setup since I can't manage JPG or GIF images in REBOL.

request-file/filter "*.jpg"

seems to work fine for me on WinXP, show folders and jpgs only.

yes it works, but if you look at the filter box, you will see that 
rebol adds 2 more filters  :-(

who cares about rebol files in an end-user application  >:-(

I don't remember any tricks to do that Max.

maybe we should make a wish for it in the next R2 release?

I see now what the problem is. Those REBOL types are hardcoded into 
view-request sources. 
But you can patch them away with

	remove find/only req-file/filter-list ["*.r" "*.reb" "*.rip"]

 remove skip find req-file/start-out/3 [fp: rty "Normal" "REBOL" "Text" 
 "Images"] 3

After that, request-file should come up without the REBOL types.

That at least seems to work on windows, I don't know what happens 
on other platforms.

Or just use local-request-file directly.