next »

[inp o҉rtb]

Yeah, that was the first thing I tried for PNG. If you do that, or cat file1 file2 > file3 on *nix, you get a perfectly fine PNG.

The problem with that is that I have no idea how big the first file is. If I pass the file stream through the image reader API, I get the first image alright, but as usual, the reader over-reads and renders the second portion unreadable. One might have to use a buffered stream wrapper to fix this, unreading the over-read bytes. Then one would have to either rewrite the image reader API or hack it somehow, since there is no other way to tell where the first file ends. So I went for a slightly more troublesome, but more supported method. It produces an absolutely legal PNG, not just a bunch strung together.

One problem I ran into was that many image viewer programs (including the preview plugin in your favorite file manager) also extracts and displays the metadata. This would be fine if you were just saving a little bit of stuff like the author and the date. However, I totally bombed one of my test machines by trying to preview a 500 KB long text field. My fix? Simply put another text field after it with the same keyword/name. It effectively overwrites the first (since these nodes are read sequentially), so a much shorter string can be displayed. My program, though, recognizes the signature of the decoy and ignores it.

[unicauca]

Really Nice!
I keep with my Desktop Application but this is a great advance in Web-Apps...

[inp o҉rtb]

If a desktop application is what you're looking for, I'll be rolling one out soon =p

[antimatter15]

If a desktop application is what you're looking for, I'll be rolling one out soon =p

-yeah, why do you bother using jws (java web start, that's how i abbreviate things) can't you just send out a java binary?
jws is so um.... limited... sorta.... and it's not that fast either (especially startup) why not just make a desktop app?

And i think that person was confused and didn't know that it was in java now

I also think it's weird to have two status bars (well at least on windows... it probably is only there 'cause windows sux)

you also should update the front content (with pics of your wonderful app)

I like the app it is pretty cool-still not very advanced. and reverse engineering something like http://shop.tech4learning.com/index.php?main_page=popup_image&pID=27
is okay.... (it's a shareware fairly complete java based image editor)

[inp o҉rtb]

Java Web Start is just a wrapper for launching a Java app. It takes care of keeping your apps up to date, and making sure that the right JRE is installed. I think it makes deploying Java apps a lot easier. So Imagine is a full Java app, just deployed using Web Start.

[antimatter15]

Java Web Start is just a wrapper for launching a Java app. It takes care of keeping your apps up to date, and making sure that the right JRE is installed. I think it makes deploying Java apps a lot easier. So Imagine is a full Java app, just deployed using Web Start.

well then, start offering the app as a .jar.

ANY MORE PROGRESS???

[inp o҉rtb]

well then, start offering the app as a .jar.

... which would defeat the purpose of using Java Web Start in the first place -- easy deployment and updating of the app. What did you mean by "not that fast"? Did you try to run each revision more than once? And yes, the package is available in .jar form. Just look in the .jnlp file to scope out where they are.

As far as progress goes, I've just upgraded the framework to use swing layout 1.0.1. I've added a flexible dialog box framework modeled after Imagine-Javascript, as well as a couple of filters (accessible under the "Filter" menu). I might add more filters sometime, but embedding Rhino seems to be a good way to start allowing third-party pluggable filters.

On a related note... I really should implement scaling, resizing, rotating, cropping, trimming, and whatnot. However, cropping will have to wait until I find a nice selection display.
There is now internal support for cropping and trimming. All layers are now automatically padded to canvas size while working, and automatically trimmed when saving to save space. The current padding implementation allows negative padding, which crops the image. There will be a croptool soon, I promise!

[antimatter15]

well then, start offering the app as a .jar.

... which would defeat the purpose of using Java Web Start in the first place -- easy deployment and updating of the app. What did you mean by "not that fast"? Did you try to run each revision more than once? And yes, the package is available in .jar form. Just look in the .jnlp file to scope out where they are.

As far as progress goes, I've just upgraded the framework to use swing layout 1.0.1. I've added a flexible dialog box framework modeled after Imagine-Javascript, as well as a couple of filters (accessible under the "Filter" menu). I might add more filters sometime, but embedding Rhino seems to be a good way to start allowing third-party pluggable filters.

On a related note... I really should implement scaling, resizing, rotating, cropping, trimming, and whatnot. However, cropping will have to wait until I find a nice selection display.
There is now internal support for cropping and trimming. All layers are now automatically padded to canvas size while working, and automatically trimmed when saving to save space. The current padding implementation allows negative padding, which crops the image. There will be a croptool soon, I promise!

ok. well, being in java - i must admit this is sorta pointless. I mean it's a desktop application competing with lot's of things like gimp paint.net photoshop and lots of otehrs. And it's in java - the load times are'nt remarkable either. EVEN MS-PAINT HAS A CROPPING TOOL!!!!!! And for the third party plugins - unless something is well-known, nobody will create plugins for it (except maybe me)

[inp o҉rtb]

Paint has a cropping tool, sorta. It's not a real cropping tool, but you can achieve the crop effect using Paint. And who says anything about competing? This is more of a I-want-to-learn-Java-here's-a-nice-project deal. And I've actually learned quite a bit from it -- I'd known zero Java before I started.

Now, I won't implement cropping. I want to roll out an alternative to cropping. Basically, you clear some space around your layers and shrinkwrap the canvas around them, possibly leaving some space. Sure, it might have a function called "crop", but it'll just be a higher-order function built on these lower-order functions. So you'd be able to crop on a per-layer basis.

As for actually making the selections so that you can clear some space and do other stuff, I'm thinking about implementing the selection as a canvas-level mask. It'll mask drawing and filtering operations, and be invertible. But before I can implement canvas-level masking for operations, I'd have to implement layer-level masking for rendering, which calls for differentiation of layer types, which I shall start on now. The layer types that sound useful are --

Layer (abstract basis for all layers)
SimpleLayer (consisting of an image. can be used for masking.)
CompoundLayer (consisting of a SimpleLayer with a chain of SimpleLayers for masking.)
TypeLayer (consisting of unrasterized text, maskable.)
VectorLayer (consisting of unrasterized SVG, maskable.)
AdjustmentLayer (consisting of a filter, maskable.)

Each should have a serialization method, so as to make them storable in PNG using the previously-mentioned format.

[antimatter15]

Paint has a cropping tool, sorta. It's not a real cropping tool, but you can achieve the crop effect using Paint. And who says anything about competing? This is more of a I-want-to-learn-Java-here's-a-nice-project deal. And I've actually learned quite a bit from it -- I'd known zero Java before I started.

Now, I won't implement cropping. I want to roll out an alternative to cropping. Basically, you clear some space around your layers and shrinkwrap the canvas around them, possibly leaving some space. Sure, it might have a function called "crop", but it'll just be a higher-order function built on these lower-order functions. So you'd be able to crop on a per-layer basis.

As for actually making the selections so that you can clear some space and do other stuff, I'm thinking about implementing the selection as a canvas-level mask. It'll mask drawing and filtering operations, and be invertible. But before I can implement canvas-level masking for operations, I'd have to implement layer-level masking for rendering, which calls for differentiation of layer types, which I shall start on now. The layer types that sound useful are --

Layer (abstract basis for all layers)
SimpleLayer (consisting of an image. can be used for masking.)
CompoundLayer (consisting of a SimpleLayer with a chain of SimpleLayers for masking.)
TypeLayer (consisting of unrasterized text, maskable.)
VectorLayer (consisting of unrasterized SVG, maskable.)
AdjustmentLayer (consisting of a filter, maskable.)

Each should have a serialization method, so as to make them storable in PNG using the previously-mentioned format.

you could use apache batik for the rasterizing/serializing of images to svg.

[inp o҉rtb]

Indeed -- this is where these libraries come in handy. And I think Java does TTF natively. I'm not sure if Java would be fast enough to handle adjustment layers, though -- it's a filter operation for every render. The chained masking should be fast -- alpha compositing/clipping is a very simple operation.
Alright, Layer and SimpleLayer are done.

Layer is the interface that all layers have to implement, which includes rendering functions and whatnot. Then there's AbstractLayer, which implements most of the Layer methods. SimpleLayer just extends AbstractLayer.

[antimatter15]

Indeed -- this is where these libraries come in handy. And I think Java does TTF natively. I'm not sure if Java would be fast enough to handle adjustment layers, though -- it's a filter operation for every render. The chained masking should be fast -- alpha compositing/clipping is a very simple operation.
Alright, Layer and SimpleLayer are done.

Layer is the interface that all layers have to implement, which includes rendering functions and whatnot. Then there's AbstractLayer, which implements most of the Layer methods. SimpleLayer just extends AbstractLayer.

how would you mask a vector object with raster? will you render the svg and load an image onto it, or raster the vector and merge?

[inp o҉rtb]

The layer framework has been modified a bit -- CompoundLayer now refers to a generic collection of layers, regardless of type. They could be SimpleLayers, VectorLayers, TypeLayers, MaskLayers, and whatnot.

Hence, CompoundLayer now serves as base class to CanvasLayer, which now supercedes the Canvas class. This means that support for the older filetype is now broken, and a new format is available, which keeps track of an infinite number of levels of CompoundLayer. Each layer now also has its own writer and reader, thus simplifying the code necessary to keep track of the different layer types in a file. This major shift in code base was accomplished in less than 12 hours, and no major debugging was necessary. The next logical development would be a layer rendering tree, supplanting the previous Photoshop-style linear rendering path. I'll work on it as soon as I can come up with a good treetable implementation.

Currently implemented --
Layer: general layer interface
AbstractLayer: layer adapter class implementing most Layer methods
SimpleLayer: 32bpp bitmap layer
CompoundLayer: grouped objects of class Layer, to be composited together
CanvasLayer: CompoundLayer with translation to physical space, such as DPI

On the list --
TypeLayer: unrasterized text
VectorLayer: unrasterized SVG
MaskLayer: 8bpp layer mask

Not even being considered [yet] --
AdjustmentLayer: filter operation

how would you mask a vector object with raster? will you render the svg and load an image onto it, or raster the vector and merge?

How? Currently, the Layer interface allows each type of layer to have a different data model, but requires that each type of layer could rasterize itself. A layer's data model is simply how the layer gets its data. A SimpleLayer, for example, uses a bitmap, and it would be trivial to rasterize it. A CompoundImage, on the other hand, uses a list of Layer's, and the rasterization process involves blending all the Layer's together while rasterizing recursively. A number of optimizations are in place to help maintain rendering speed.

So a VectorLayer would have a SVG data model, but when it needs to be displayed, it would be rendered using its built-in renderer. The mask would be applied to the rendered image. When the layer is edited, it would be automatically re-rasterized on demand. Does SVG support text natively? If so, I can possibly ditch the TypeLayer...

A MaskLayer would use a 8bpp bitmap as its data model, but generate an alpha channel on demand. I've already got these extended compositing features going, but it's kind of difficult to show them off without a reliable treetable control. Oh, well... gotta keep working :-P

[antimatter15]

The layer framework has been modified a bit -- CompoundLayer now refers to a generic collection of layers, regardless of type. They could be SimpleLayers, VectorLayers, TypeLayers, MaskLayers, and whatnot.

Hence, CompoundLayer now serves as base class to CanvasLayer, which now supercedes the Canvas class. This means that support for the older filetype is now broken, and a new format is available, which keeps track of an infinite number of levels of CompoundLayer. Each layer now also has its own writer and reader, thus simplifying the code necessary to keep track of the different layer types in a file. This major shift in code base was accomplished in less than 12 hours, and no major debugging was necessary. The next logical development would be a layer rendering tree, supplanting the previous Photoshop-style linear rendering path. I'll work on it as soon as I can come up with a good treetable implementation.

Currently implemented --
Layer: general layer interface
AbstractLayer: layer adapter class implementing most Layer methods
SimpleLayer: 32bpp bitmap layer
CompoundLayer: grouped objects of class Layer, to be composited together
CanvasLayer: CompoundLayer with translation to physical space, such as DPI

On the list --
TypeLayer: unrasterized text
VectorLayer: unrasterized SVG
MaskLayer: 8bpp layer mask

Not even being considered [yet] --
AdjustmentLayer: filter operation

how would you mask a vector object with raster? will you render the svg and load an image onto it, or raster the vector and merge?

How? Currently, the Layer interface allows each type of layer to have a different data model, but requires that each type of layer could rasterize itself. A layer's data model is simply how the layer gets its data. A SimpleLayer, for example, uses a bitmap, and it would be trivial to rasterize it. A CompoundImage, on the other hand, uses a list of Layer's, and the rasterization process involves blending all the Layer's together while rasterizing recursively. A number of optimizations are in place to help maintain rendering speed.

So a VectorLayer would have a SVG data model, but when it needs to be displayed, it would be rendered using its built-in renderer. The mask would be applied to the rendered image. When the layer is edited, it would be automatically re-rasterized on demand. Does SVG support text natively? If so, I can possibly ditch the TypeLayer...

A MaskLayer would use a 8bpp bitmap as its data model, but generate an alpha channel on demand. I've already got these extended compositing features going, but it's kind of difficult to show them off without a reliable treetable control. Oh, well... gotta keep working :-P

Yes, svg supports text. and you could just embed the raster image in the svg like with the <img> object in html

[inp o҉rtb]

Naah, I won't embed images in SVG -- I don't think SVG has specifications for blend compositing; it's all alpha compositing. I can introduce new attributes, but making images separate layers results in more control.

I'll probably not use SVG for text either. Most people would probably not use SVG, but text would be more often used. I would imagine that it's more efficient to render text only, as opposed to SVG.

(also, uh... i don't understand why you have to quote me every time =p )

[antimatter15]

Naah, I won't embed images in SVG -- I don't think SVG has specifications for blend compositing; it's all alpha compositing. I can introduce new attributes, but making images separate layers results in more control.

I'll probably not use SVG for text either. Most people would probably not use SVG, but text would be more often used. I would imagine that it's more efficient to render text only, as opposed to SVG.

(also, uh... i don't understand why you have to quote me every time =p )

quoting lets me make my posts seem longer.
okay, so have you found a decent svg renderer yet? or is it native to java

[inp o҉rtb]

Native to Java? Ha! Nothing Java is ever "native," by definition =p

I haven't started looking for SVG renderers yet, but I would expect there to be some nice ones for Java. I think I'll end up doing type layers first, though, since it's a bit simpler.

Internal support for layer tree rendering is already pretty mature. There is now no trace of the original canvas format; making the main canvas a compound layer makes managing the code a lot easier, since the canvas is rendered the same way as any other compound layer. I spent an afternoon on the tree view, and now you can see your whole layer hierarchy (which currently is just all your layers under a canvas layer).

Plans:
-- add functions for managing the layer tree, preferably drag-n-drop
-- add a "mask" blending mode, for layer masking (which would be implemented based on the tree model; color masking would also be interesting)
-- define filter operations on compound layers, and add low quality mode for previews
-- implement channels support (possibly by turning a simple layer into a compound layer of channel layers; no, you can't do this to a compound layer, because it does not make sense)
-- somewhere along the way, allow scaling, resizing, cropping, and all that good stuff xD

*Then*
-- implement type and vector layers
-- carry out further optimization
-- UNDO! HISTORY!
-- embed Rhino (or use the version that comes with Java6)

Anyway -- check it out.
http://imagine.inportb.com/javaws/

[antimatter15]

Native to Java? Ha! Nothing Java is ever "native," by definition =p

I haven't started looking for SVG renderers yet, but I would expect there to be some nice ones for Java. I think I'll end up doing type layers first, though, since it's a bit simpler.

Internal support for layer tree rendering is already pretty mature. There is now no trace of the original canvas format; making the main canvas a compound layer makes managing the code a lot easier, since the canvas is rendered the same way as any other compound layer. I spent an afternoon on the tree view, and now you can see your whole layer hierarchy (which currently is just all your layers under a canvas layer).

Plans:
-- add functions for managing the layer tree, preferably drag-n-drop
-- add a "mask" blending mode, for layer masking (which would be implemented based on the tree model; color masking would also be interesting)
-- define filter operations on compound layers, and add low quality mode for previews
-- implement channels support (possibly by turning a simple layer into a compound layer of channel layers; no, you can't do this to a compound layer, because it does not make sense)
-- somewhere along the way, allow scaling, resizing, cropping, and all that good stuff xD

*Then*
-- implement type and vector layers
-- carry out further optimization
-- UNDO! HISTORY!
-- embed Rhino (or use the version that comes with Java6)

Anyway -- check it out.
http://imagine.inportb.com/javaws/

Yay! Quoting!

anyways, in your signature, i see it points to your javaws page, but it says "online" which I think is a typo.

it's weird how in windows, there are TWO statusbars.

I like what I'm seeing.

[inp o҉rtb]

A typo? Perhaps you are referring to the semantic mismatch of "Java" and "online". Actually, I _am_ planning the "online" part, which will be a platform/community utilizing the Imagine editor. And instead of using a Web browser, I envision Imagine also _being_ the browser. As a social utility, I don't see why a Java-based app cannot be considered "online".

There are two statusbars? Interesting. That must be the default Java statusbar and Imagine's, right? Actually, I don't think I'll need the custom statusbar if I could manipulate the default statusbar directly. This was just carried mindlessly over from Javascript-Imagine.

[antimatter15]

A typo? Perhaps you are referring to the semantic mismatch of "Java" and "online". Actually, I _am_ planning the "online" part, which will be a platform/community utilizing the Imagine editor. And instead of using a Web browser, I envision Imagine also _being_ the browser. As a social utility, I don't see why a Java-based app cannot be considered "online".

There are two statusbars? Interesting. That must be the default Java statusbar and Imagine's, right? Actually, I don't think I'll need the custom statusbar if I could manipulate the default statusbar directly. This was just carried mindlessly over from Javascript-Imagine.

okay. just like in javascript you can manupulate the status by window.status.

and it's just that it's not currently platform/community stuff. And you can use my code for the community login/register stuff (server php). My login system is more feasible for non-db single page ajax applications since it doesn't use cookies. and sends the password (encoded) every time an action is done (pretty secure still)