next »

[Timothy Jacobs]

I can't say much but AMAZING!  It's absolutely amazing.  I love it, great work!

20/10!!

[inp o҉rtb]

SCROLL TO THE BOTTOM OF THIS POST FOR LATEST EDIT

Hm, it just occurred to me that it would be a good idea to let people type stuff on their pictures... it's going to look ugly without TTF, though...

do you really need the

*: These work partially.
~: These don't work yet.

?

I guess not I don't have any half-baked functions now anyway. Besides, people might be able to guess that they should not try these specially labeled functions

You should add an option for how many pixels to blur on the Gaussian Blur.

I've been thinking about that since the beginning. PHP's GD does not give the user very much control over the blur -- it's just blur. However, I'm thinking about taking two copies of the image, one normal and one blurred, and blend them with varying levels of transparency. This should give some extra control over the function. In addition, the function can be applied many times in succession... and I intend to calibrate the composite function against Photoshop. I'll also do this for selective blur.

It's mainly just filters right now, maybe you should add a brush tool or a pencil tool? If it's a photo manipulator, it should have more options.

Indeed. What I have done so far is accomplished using straight PHP GD. I think brush and pencil tools are a great idea! It would involve pixel-level editing, something that I want to do a bit more thinking about. I've already mentioned my intention to implement custom filters. Those would also involve pixel-by-pixel editing. Another thing that would be useful is to be able to apply a filter to a restricted section of the image... or something like a filter-brush (simulated in Photoshop using layers). These functions will undoubtedly run up resource usage, so I'm looking for ways to optimize the procedure. The brush and pencil would also run up clientside resource usage. I might need to consider using canvas or svg graphics instead, which would further restrict browser support. Anyhow, I'm going to think a bit more about this one =D

Thanks so much for the input!

I can't say much but AMAZING!  It's absolutely amazing.  I love it, great work!

20/10!!

Thanks, man. I try my best Heh, making browsers and servers do what they were never meant to do...

### EDIT ###
Okay, the program now stores resource handles to your work. This means that every file you work with (passed as URL or file) in a browser session is available to you even after you unload the workspace. It allows you to easily continue your work without having to upload your work again, saving time and bandwidth. This should also allow for easier implementation of layers -- just load a different image in a new window/tab and make a layer out of the generated resource handle in the current window/tab. Also, check out the new accordion-folding menu =D

### EDIT ###
I have implemented a basic WHATWG <canvas> drawing manager. While it currently does nothing but leave a mouse trail when you drag on the picture, it will be developed further. It has been tested to work in *fox, Safari, and MSIE7. If you want to check it out, click the button labeled "*canvas" in the "File" section.

### EDIT ###
This revision of Imagine brings you tremendous improvement -- arbitrary 3x3 convolution filters! If you haven't heard of these before, they let you make custom filters such as sharpen, blur, edge enhance, emboss, and all that good stuff. If you want to try your hand at custom filters, check out the functions in the "Convolute" menu. The generic convolution function lets you define your own filters. There are presets to help you if you get lost. There are functions that let you control how much to sharpen or blur your image. Finally, you can emboss your images at arbitrary angles! Check it out!

Now, I've been comparing Imagine to resize.it, and here's my conclusion. resize.it can resize, crop, rotate, and flip images. So can Imagine, which uses a slicker AJAX interface, and Imagine can rotate arbitrary angles. resize.it can sharpen, blur, desaturate. Guess what? So can Imagine; and now you can control the level of sharpening and blurring! resize.it can convert your image into a sketch. While Imagine can't exactly do that, it _can_ do motion blur, which can be modified to produce a similar effect. This is all resize.it can do. Imagine also adjusts brightness, contrast, and color, provides a whole host of filters, and does convolution. In the future, it will be able to generate different file formats, making image conversion a breeze. So Imagine gives you more functionality, more control, and more flexibility than most (if not all) other online photo manipulators out there.

[NoelF1]

awesome online app mate!

[inp o҉rtb]

I'm glad you like this program. Now that it can do convolution filters, I suppose now's the time to continue working on mouse-interactive functions and layering... back to work!

### EDIT ###
I've implemented a new distortion filter framework that lets me plug in any mathematical function I want. I now have random, sine, and spherize distortions. Time to start turning out more interesting distortion filters!

[Mop (Gb)]

Wow, that is quite an amazing piece of work!

[inp o҉rtb]

Thanks for your compliment, Gb

And now, it's time for an announcement :AHEM:

Public Beta 5 of Imagine introduces a cleaner, more streamlined layout engine. The completion of numerous single-layer functions marked the transition from Beta 4 to Beta 5. Now that Imagine is capable of the essential functions (or at least easily extensible to cover them), we can ask ourselves: Can we do more? Can we set ourselves apart from the other simple photomanipulators? And the answer is: Yes, we can implement layers and make Imagine something more than just simple. Allow people to layer images on top of each other, work on each layer independently, and then merge them using innovative blending styles. Extend the single-layer paradigm by expanding into another dimension.

What will be the outcome of this endeavor? Dare we say "Photoshop alternative?" Of course, this program still requires resonably high downstream bandwidth (and asks for a decent upstream connection). These connections are becoming more and more common. The program also requires a modern Web browser, which is, by definition, very common. For those who can fulfill the requirements, and for those who do not wish to pay a premium for Adobe Photoshop, and for those who prefer the comfort of the Web browser to learning how to set up and use the GIMP, we recommend Imagine for daily photomanipulation needs.

Think you've got what it takes? Try us; you won't be disappointed.

http://imagine.inportb.com/

[jakejus1]

All owrking fine, it's cool and I have made a avatar for me! Thanks for this great work. Just one bug in IE7.

The bar to change the pixels of the things come out of the browser and the layot. Need a little fix

[inp o҉rtb]

I am so glad that you found this tool useful.

I think you mean the sliders. I just checked it out in IE and, by gosh, you're right! I'd overlooked this for weeks. I'm going to work on the fix now. Thank you for pointing this out. BUG FIXED

The history was a little buggy, especially in IE; but it should be more stable now, even in IE. So IE7 is not as standards-compliant as I'd thought. Oh, well. I'm working on getting full multi-layer capabilities built in, so hang on tight!

(please, keep using this script; I'm going to be developing using a working copy, so usage should not be affected.)

[Piotr GRD]

Great tool. I'm impressed.

I know something like this - url: resize.it - but I think your will be better.

(...)

But most of all:
Congratulations.

And I was right. At the moment your Imagine is already much better!
And I know that it's not the end of your work. Well - keep it up.

Greetings.

[inp o҉rtb]

@ Piotr GRD: Thanks for the overwhelmingly positive comment and strong encouragement!
(and thanks for the report. I'll see what I can do about that one... but I'm not sure the admins and other members would be too happy about it if I ask for more resources. hahaha... as you would understand, image processing is rather resource-intensive, especially for those larger images. so instead of asking for more resources, I'm going to optimize my script first.)
I fixed a major bug with IE -- apparently, you cannot modify the DOM while it is still being loaded. Even though I put the startup code at the bottom of the page, IE still complained. So now startup code is called in window.onload. I also fixed cross-browser font-size uniformity issues, and made the upload process just a bit smoother.
I just implemented Photoshop-style history. Before, you can see all states of your work. Now it automatically prunes the action list, maintaining a linear timeline from start to finish. Check it out.
Currently, I have not been actively adding new features; most of the work has been going into tidying up the code and making it ready for layer blending (but if I see a convenient feature implementation, I would just do it). For example, before, the loaded image was stored in a global variable. Now it's stored in an array, which in turn is managed by a singleton display handler object. The new display handler is able to load more than one image into the array, and display them with arbitrary z-index. I haven't actually added the functionality, but the system is now internally capable of handling layers.

The same goes for the history module. When your work was only one image, it was trivial to keep track of each revision. Now, it has to keep track of all the layers in each revision. I spent an afternoon wrapping the history module into a singleton object, then making it work with the display manager to save and restore states. Before, when you hover your mouse over a history item, a preview would be be shown in the workspace. With layers, I have decided against showing all the layers, as that would very likely hog client-side resources and make your browser perform at a sub-par level. Instead, it would display a single layer that best represents the change done to the work. To compensate for this, I will implement Photoshop-style history management -- instead of logging every restore operation and keeping everything on the list, I will make it so that when you work on a historic copy, all downstream history in the alternative timeline is removed. This should give a more linear, less confusing view of the history while saving memory, but this also means that you can no longer access every state of the work. IMPLEMENTED.

You may also be aware of the session-recall feature that lets you continue working on something you've worked on previously. I intend to put this to work in my layers implementation, allowing users to load layers from session. So to add a layer, you would first load the image into a separate instance of Imagine, then recall it into your working instance. This may seem a bit clumsy now, but it's the most straightforward way as far as implementation goes. I will, of course, keep finding ways to improve it. But now you might wonder... what happens when you want to recall a whole project from your session? Well... this requires that the session variable be extended, so that it stores snapshots of entire projects instead of just layers. And it may be nice if I make use of a simple database to store user accounts, allowing projects to persist across sessions.

Wow. What a mouthful. The bottom line is -- thanks for using Imagine, thanks for sending me your reports, and look out for great new features in the near future! And boy, do I see a need for a blog...

[cyberdevil]

That was some awesome work..

[inp o҉rtb]

Thank you!

Now, I haven't been pushing out many new features lately, but that doesn't mean I haven't been busy. I've been working on layers support, which seems to be coming along nicely. You can currently load another layer (or more) into your workspace, from your session. The layer is loaded on top, and becomes the currently active layer. What I need to do now is display a "Layers" box in the palette and let the user select the active layer. The user should be able to make each layer visible or invisible (easily done using CSS). The user should also be able to change layer order. I think you can remove layers now, but it's pretty useless because you cannot actually select the active layer. So the one on top goes away. What do you think of the proposed features?

Again, here are the links:
STABLE: http://imagine.inportb.com/
TESTING: http://imagine.inportb.com/dev/

While I welcome you to try the testing version, please keep in mind that it can be a hairy experience.

[antimatter15]

Thank you!

Now, I haven't been pushing out many new features lately, but that doesn't mean I haven't been busy. I've been working on layers support, which seems to be coming along nicely. You can currently load another layer (or more) into your workspace, from your session. The layer is loaded on top, and becomes the currently active layer. What I need to do now is display a "Layers" box in the palette and let the user select the active layer. The user should be able to make each layer visible or invisible (easily done using CSS). The user should also be able to change layer order. I think you can remove layers now, but it's pretty useless because you cannot actually select the active layer. So the one on top goes away. What do you think of the proposed features?

Again, here are the links:
STABLE: http://imagine.inportb.com/
TESTING: http://imagine.inportb.com/dev/

While I welcome you to try the testing version, please keep in mind that it can be a hairy experience.

That's nice. don't think you should add drawing features as then you would be competing against stuff like: http://fauxto.com

[inp o҉rtb]

Actually, I think that's what I'm going to do, because I do intend to compete against Fauxto =p

Thank you very much for the link; Fauxto looks like a fairly complete Photoshop alternative in Flash. Well, I'm going to show that Javascript, CSS, and PHP are not inferior to the proprietary Flash :-P

[antimatter15]

Actually, I think that's what I'm going to do, because I do intend to compete against Fauxto =p

Thank you very much for the link; Fauxto looks like a fairly complete Photoshop alternative in Flash. Well, I'm going to show that Javascript, CSS, and PHP are not inferior to the proprietary Flash :-P

Inferring by your "proprietary Flash" comment, Are you going to open source it?

And I am very interested by your undo history system and your system does it nicely.

And suprisingly enough, it looks as if your app has more lines of javascript than mine! (i think) (I think I have just over 1000 lines of js code in my animator) (and in imagine.js there are 1064 lines of js)

[inp o҉rtb]

Opensource Flash? It's already available in Gnash... But rather, I was referring to the technology itself. It would be kind of pointless to clone Adobe Photoshop using Adobe Flash...

Hm, I think the undo system is one of the most important, and it's been hindering development. If I change anything, I would have to make a corresponding change in the history module. But I'm glad that it's working smoothly now. In the testing version, though, the history is still under heavy development.

More lines? Oh, haha, I think that's because most of the interface is hand-coded. I use prototype for some convenience functions, and scriptaculous for the sliders. I use moo.fx for the accordion menu, and a bunch of other libraries. What bugs me is that while each library is capable of much more, I only use it for one purpose. I intend to code these things myself in the future, to cut down on the use of these oversized libraries. imagine.js contains a lot of stuff that makes up the interface, as I'm sure you've found. The rest of it takes care of showing the dialog boxes. imagine.php is also pretty monolithic; everything is on the page, but not everything is displayed at once.

[antimatter15]

Opensource Flash? It's already available in Gnash... But rather, I was referring to the technology itself. It would be kind of pointless to clone Adobe Photoshop using Adobe Flash...

Hm, I think the undo system is one of the most important, and it's been hindering development. If I change anything, I would have to make a corresponding change in the history module. But I'm glad that it's working smoothly now. In the testing version, though, the history is still under heavy development.

More lines? Oh, haha, I think that's because most of the interface is hand-coded. I use prototype for some convenience functions, and scriptaculous for the sliders. I use moo.fx for the accordion menu, and a bunch of other libraries. What bugs me is that while each library is capable of much more, I only use it for one purpose. I intend to code these things myself in the future, to cut down on the use of these oversized libraries. imagine.js contains a lot of stuff that makes up the interface, as I'm sure you've found. The rest of it takes care of showing the dialog boxes. imagine.php is also pretty monolithic; everything is on the page, but not everything is displayed at once.

Gnash Sucks No I mean't were you going to make your application open source (or is it already and i'm just a idiot)

Well My interface used to be hard-coded too and that was pretty small. Alot of my code is handling the ui too. (stuff like positioning animations, cycling through frames, making timeline look pretty, block adblock, warning people about the horrors of ie)

[inp o҉rtb]

I don't plan on hiding the source from the user. Because it's AJAX, most of the client-side code is already visible. And I've made it even easier to download by putting all the CSS in one file, all the JS in one file, and all the XHTML in one file. On the server, the only thing that takes place is manipulation using GD. I've just been too lazy to package everything up

Well, my layout does not support IE6 and below, because of a known issue. I'm thinking about coding for compliance first, then using Javascript to fix it up for IE6. Now, I'm experimenting a bit with Java. I think it would be better for the client and the server -- the client does all the work and sends image data occasionally to the server, and the server just takes care of accepting and organizing images. This should reduce network traffic and server load, even though it's definitely not as cool as doing it with AJAX. I guess making this decision has the potential to turn off lots of people, but also stimulate some others :-P

[antimatter15]

I don't plan on hiding the source from the user. Because it's AJAX, most of the client-side code is already visible. And I've made it even easier to download by putting all the CSS in one file, all the JS in one file, and all the XHTML in one file. On the server, the only thing that takes place is manipulation using GD. I've just been too lazy to package everything up

Well, my layout does not support IE6 and below, because of a known issue. I'm thinking about coding for compliance first, then using Javascript to fix it up for IE6. Now, I'm experimenting a bit with Java. I think it would be better for the client and the server -- the client does all the work and sends image data occasionally to the server, and the server just takes care of accepting and organizing images. This should reduce network traffic and server load, even though it's definitely not as cool as doing it with AJAX. I guess making this decision has the potential to turn off lots of people, but also stimulate some others :-P

That's how my ajax animator was designed to work. I wanted to use java to do everything swf related but It just doesn't seem right.

Java doesn't really go well with web applications because of how slow it is (on load) and how you (as far as i know) can't have an html element directly above it.

What about the imagine.php sources?

[inp o҉rtb]

Java doesn't really go well with web applications because of how slow it is (on load) and how you (as far as i know) can't have an html element directly above it.

Well, I meant a standalone Java app that starts using JavaWS. It would be cached and the whole interface would be done in Java. The website would then have a different purpose -- to advertise and do other things that websites are supposed to do, _not_ image manipulation

What about the imagine.php sources?

imagine.php accepts a file upload, and prints out all that other stuff; it's mostly static. It's a monolithic thing of hidden divs, which imagine.js turns into a user interface. It's imagine.server.php that people should be concerned with -- it does all the heavy lifting.