Posted by
cal, 16:03, 7th March 2002:
The iamcal network presents
Color Vision
Posted by
ell, 00:39, 8th March 2002:
*racks brains* - didn't you once tell me you had some form of colourblindness, or something?
And "color"? I don't care if they're considering changing the English, I'm afraid you've been American-i(z?)ed, Cal. :P
Posted by
cal, 12:22, 8th March 2002:
Programming forces me to drop to 'u'. it's just built in habbit now
Posted by
Q42Lon, 13:46, 11th March 2002:
Hi Cal,
I really liked your color vision thing.
We (Q42) have build one too, being inspired by yours.
Please check it out:
www.q42.nl/demos/colorblindnesssimulator
This one transforms entire pages. Including all images!
You need IE5 on Windows though...
Hope you like it.
greetings Lon Boonen, Q42
Posted by
Sul, 14:20, 11th March 2002:
Who's Carl?
Posted by
cal, 08:31, 12th March 2002:
yes - it would be nice if you spelt my name right. it's CAL not CARL.
but i like your tool. a better way to do it would be to perhaps grab a copy of the page using a server side language, then modify the stylesheet on the fly with javascript/dom
Posted by
mikhail, 03:08, 13th March 2002:
jeez, did they say Carl enough? and I would watch who i say, 'i like your tool' to. might get messy. =)
Posted by
Q42Lon, 23:43, 13th March 2002:
my since'est apologies. I have 'emoved all supe'fluous r's f'om our website.
About grabbing a copy and modifying the stylesheets on the fly:
we first started modifying stylesheets and HTML by searching the HTMLDOM (on the client side of course). But doing this you're not able to change (background)images. So, in order to do complete pages (including images) we just used DirectX filters. It's easier and almost guaranteed.
Posted by
cal, 08:28, 14th March 2002:
hmm. you can still do it the style sheet way. just iterate through the background-image properties and the <limg> tags, replacing "path/to/myimage.gif" with "http://www.iamcal.com/process_image.php?source=http://www.whateversite.com/path/to/myimage.gif", so all images can be passed through a filtering process.
Posted by
Q42Lon, 01:08, 16th March 2002:
Why always on the server? This will not do.
First of all: you will have to run as a bookmarklet in order to be able to search the page for images to replace.
The current version can also work as a link, without the added functionality you get when running as a bookmarklet.
Second: does your server also process BMP? GIF? transparency? Filters applied to images by the HTML? PNG? JPG? progressive JPG? Flash? Shockwave? SVG?
The server just isn't a browser. So it will never be able to render a page as true to nature as the browser itself.
Third: performance and scalability. The stuff is already at the client, why let some server download it as well, process it and upload it to the browser again? This server would be a major pain in the bottleneck. And the client would probably have to load everything twice.
Fourth: why?! It works on the client. My first attempt also was to try and do it the HTMLDOM-scan-way. But it just isn't as good as what Sjoerd did.
Unless, I have to admit, you want to see DHTML in action! The filter we have build now will not let you animate the page and see the results.
Forgive me. I am quite fanatical about the client/server issue. And I am quite wrong on this issue. My strong conviction is that EVERYTHING MUST BE DONE ON THE CLIENT. Servers are only good for storing and serving. I know this isn't true, but it helps me strive towards better client-side interfaces.
Your turn again...
Posted by
cal, 09:12, 20th March 2002:
i'll address your points individually:
1. yes, you do have to run it as a bookmarklet.
2. you don't understand. the server doesn't "render" anything. it's used as a proprocessor for images, before they are pushed to the client.
3. time mine against yours and you'll see where the bottle neck is. remove unessacery processing from the client. thin client, thick server.
4. it doesn't work. colored filters do not have the same effect as shift hue mappings. it's only a very vauge approximation to the problem. and it only work in ie. on the pc. and it's very slow.
everything should NOT be done on the server. things which make sense on the client should be done on the client, but stuff like color filtering of images is a server-side job, where processing power is available. put it this way - do you ensure that a million clients have directx and ie on windows, or do you only worry about support on your server. think thin.
Posted by
Gary, 21:41, 1st April 2002:
Whilst most of this stuff is way, way over my head, I agree with Cal on the client/server thingy. You can't expect (however probable it is) that a million clients will have DirectX and Internet Explorer on Windows but if you know you have that support on your server then you don't need to worry about the clients.
It is most likely that a server will have much, much more processing power than your average home PC, so it makes sense to do the processor intensive stuff on the server and then push the results back to the client. Doing things on the client, that would take minutes to perform, would take seconds to perform on the server. Which one would your user prefer? Seconds or minutes? I know which one I'd prefer.
Posted by
cal, 12:37, 2nd April 2002:
indeedy