experimental file-type plugin: extended JPEG

[cr88192]

EDIT: newer version, as of 2012-12-01:

http://cr88192.dyndns.org:8080/2012-12-01_PDN_BTJ4.zip

Original Post:

an experimental plugin has been written and is available here:

http://cr88192.dyndn...11_PDN_BTJ0.zip

it comes with source-code as well...

(I will for now give permission for people to "do whatever with it").

the original codec code was written in plain C, I just sort of grabbed a big chunk of it and crudely reworked it into C# (I tried at first using C++/CLI, but couldn't get Paint.NET to recognize it). this was more quick-and-dirty, so the code admittedly kind-of sucks. it was mostly done between last-night and earlier today (as-of 2012-11-11).

basically, it is a currently very limited subset of the extensions described here:

http://cr88192.dyndn.../index.php/JPEG

the format support, as-available, is basically just JPEG but with alpha-channel support (as an additional embedded mono JPEG layer).

if/when I figure out how layers work in PDN, I could possibly also add features for supporting the extended layers.

currently, all options are hard-coded, and if/when a GUI is added, I may also add in more options (ability to choose lossy quality level, and/or be able to enable lossless encoding).

the main thing it can do is have alpha channels while being typically smaller than PNG (depends somewhat on the image though), and in my case is mostly a format intended for things like texture-maps and animated textures.

edit/add (clarification): the format is still basically compatible with existing JPEG decoders, they just won't see any of the additional layers. though there is a minor issue related to file-extensions, basically, if ".jpg" is used, PDN seems to use the default decoder regardless of which decoder is selected in the open box, so ".btj" is used instead. second note: an idea here is also that it is possible for the base-image to be used essentially as a "rendered down" version of the rest of the image-contents (a multi-layer image being able to show up as a flattened version of itself if fed into a standard decoder), whereas a simpler single-layer image would just use the base-image as its basic RGB layer. likewise, being an extension to the existing format, the preexisting images are still valid.

also, a lossless encoding is supported by the format, which is also "basically mostly compatible" with existing decoders. it is based on the SERMs RDCT and RCT, and basically is based on this paper:

http://www.eecs.qmul...CSP04-iJPEG.pdf

questions / comments?...

Edited December 1, 2012 by cr88192

[Zagna]

For layers, you could check how null54 did it for ORA plugin.

http://forums.getpaint.net/index.php?/topic/20984-openraster-filetype/page__st__20#entry348752

[cr88192]

yes, this looks helpful, I am working on this now...

admittedly, I am not entirely sure how much point other people will see in a JPEG variant with alpha and layers (and optional lossless encoding), but it is probably at least useful for what sorts of things I am doing.

also, I am probably going to make "::" be special in the layer names, partly because the format has two levels of layers: "tag layers" and "component layers". a tag-layer is a conceptual layer (or, a typical graphics-editing layer), whereas a component layer is more related to extended component graphics, mostly for things like normal-maps and luma-maps (mostly related to 3D rendering). partly this choice is because PDN seems to allow me to do this (and it probably isn't too likely to be ran into by accident).

for example, "My Layer::Norm" means "Normal-map for My Layer". a layer without any component-layer indication will be interpreted as an RGBA tag-layer (no suffix will be used for the RGBA components, and the RGBA-layer will essentially be required, probably with the list of RGBA layers being used to know which tag-layers exist).

I am thinking about whether or not the bump-map will be better put in its own layer in the editor (for editing, it makes more sense to have the bump-map as its own layer).

note: this is for a domain-specific format, after all...

not sure if there is any way to indicate additional information for layers or images (basically, like textual globs).

I will assume probably not (no big deal here).

[cr88192]

status update:

http://cr88192.dyndns.org:8080/2012-11-12_PDN_BJT1.zip

changes:

basically now handles layers (can save/restore images with multiple layers, in which case the base-image stores a down-rendered version);

flipped the images (the prior version was actually storing the images upside down it seems).

issues:

doesn't seem to work correctly on some images;

loading/saving images with lots of layers is slow;

doesn't currently remember layer settings (kind of annoying);

some issues with poor image quality and artifacts;

...

hopeful:

add an option (UI) for saving images losslessly (and choosing options);

have it remember layer settings (visibility, blending, ...);

something to crop away unused parts of the image;

...

I will have to look around some, as I am not currently sure how the save-options UIs are typically implemented.

[cr88192]

status update again:

http://cr88192.dyndn...13_PDN_BTJ2.zip

changes for today:

layer visibility preservation;

basic save-time settings UI;

lossless mode enabled, and a few image encoding settings;

some tweaks to lossy-mode quality handling (changes to the algo for generating quantization tables);

a few other bug fixes;

...

issues: I really don't know how to properly implement the cancel button, as-is, it just throws an exception.

I also would like to know if there is any way to distinguish Save from Save-As (so that I don't need to pop up the settings form again for plain Save).

the save-settings box currently looks very unprofessional IMO.

...

probably needed: code cleanups, more sensible project name, ...

tested: earlier, the lossless mode compresses a little worse than JPEG-XR, but at least generally produces smaller images than naive PNG. for the images I have tested, for lossless coding, optimized PNGs seem to compress smaller than either my format or JPEG-XR.

(well, yeah, I know, it all probably looks kind of like pointless to people, but oh well sometimes...).

(edited/corrected: something was written here which didn't make sense, spell-check botch?...).

Edited November 14, 2012 by cr88192

[cr88192]

new update again...

http://cr88192.dyndns.org:8080/2012-11-19_PDN_BTJ3.zip

status:

changed DLL and namespace names (to something hopefully a little more sensible);

some number of minor tweaks;

added a few "experimental" features, most of which had a problem of "not exactly working very well";

thing now has license terms (MIT);

...

experimental features:

basically, I was fiddling with ways to try to make the compression better, both via 64x64 "megablocks", and also experimenting with various alternate schemes for encoding the blocks (mostly for sake of supporting a larger value-range). neither led to favorable results (both resulted in larger output files).

[cr88192]

another new update:

http://cr88192.dyndns.org:8080/2012-12-01_PDN_BTJ4.zip

changes:

some various bug fixes (including an issue which caused notable artifacts at lower quality levels, ...);

layers may now be auto-cropped to omit transparent pixels;

switched to a purely fixed-point RDCT (improves performance and makes it more deterministic, may also be in prior version, I forget);

more experimental features;

minor tweaks to alternate-VLC format (added inline meta-tagging);

ability to blend transparent areas with cyan, such that the base image can have a transparent cyan background (also tested with magenta, but magenta resulted in larger output than cyan, hence why cyan was chosen), note that this process is not strictly lossless;

...

experimental features:

range coder (a variant of an "arithmetic coder"), which may reduce file sizes (vs Huffman), but does not yet work reliably;

support for alternate block-filters derived from PNG, which may help improve compression for certain types of image-data (particularly involving large flat-colored areas and sharp lines, edges, or text, which are handled poorly by the DCT transform), this is done per-block, so the codec may choose which filter does a better job on a block-by-block basis (in my tests, this has helped matters notably on a few test images).

incomplete experimental features:

more compact encodings for Huffman and Quantization tables (so the tables may be themselves entropy-coded, albeit with Rice-codes);

was working on incorporating a few of the video features from the C codec into the C# codec, granted PDN doesn't deal with video.