FYI...

This is still an active project, though I don't post much here at this time.

Basically if you are interested in this technology contact me and we can arrange for some testing to see if it works for your application.

Thanks
Todd

Another JLYT Project...

I am working something new with this.

A project involving manuscripts...  I have found some issues related to how I was handling cycles within the JLYT file which I am fixing...

New blogging link...

I have created The "Lone Wolf" Graphic Arts Technologist to talk about the larger picture related to this project.

Some of this technology will be included in future Lexigraph products such as APX Raster Pro.

My work on this project is not finished - just temporarily abandoned in favor of something likely to produce more immediate revenue.

Eliot...

Here is a link to an Australian blog and an Australian blogger about VDP and variable data printing.

We've been discussing these topics along with this project.

Getting Real Close...

After another week of hard work I have significantly improved the output of JayLight.

For those with FTP access please take a look at the file "JayLight_021909.pdf" in the test_output folder - this is the latest output for the current test file "Visio-JobTracking.pdf.jlt".

I have found the best way to see what's changing and for comparing files is to open them in Acrobat and zoom in to full magnification. The upper imager on the right is taken from the new version. The top part of the image is a "Grab" from Acrobat. The lower portion of the image is a "Grab" from the JayLight output. If you compare this area of the new file to the previous "JayLight_021309.pdf" you will see a significant improvement in the details around the heads of the "blue people". The area of improvement relates to how edges are handled. The SHORT_GB operator mentioned in a previous post has a variety of special cases which I have now figured out.

In particular, when an edge is drawn across a pixel and the bottom or top of the pixel is connected to the previous or next pixel (by the fact that all sub-pixels on the top or bottom of the scan line are "on") special color handling occurs (see the little 4x4 square). On the top the edge would be connected to the previous pixel because all four pixels across the top are "on".

There are various special cases across the top and bottom for the marking color and the what I call the "under color" which is represented by the pixels that are not marked.

There may also be some special considerations for the K color plane but I am still working in this area.

The improvement is also seen in the second image from the 0219 upload seen here on the right.

If you compare this area of the previous (0213) upload you will see a significant improvement. There is still room for improvement around the bottom of the box and along the edges of the large box into which the smaller box is being placed.

There is a second file uploaded with this version call "JayLight_021909A.pdf". This is an example of a converted file from a commercial application (Walgreens.com). (Note: This output is produced in a plant which I believe to be (or was) the largest Indigo installation in the world with 24 HP 5000's in a single room.) This file is the "Kristen & Mike" file. There are may images and also calendar areas in this file. There are still issues in the area of the reverse text on the calendar pages as well as in Kristen's hair where she is pictured next to Mike (as on the thumbnail on the first page). This file is quite large and only represents the first part of the calendar (pages 1-12). The production calendars are 28 pages.

If anyone is motivated please down load this and take a look. I have also placed the original JLT file on the site as well - "50-012775-616.prj_58_0711_1340.pdf.jlt". On page 6 you will see artifacts in the color images (see what I presume to be "Kristen and Mike" on the left and someone else on the right). The artifacts appear only on the CMY planes.

As far as the commerical application of all of this. First off, some of you are interested in this as it is now - which is an "extract" program for accessing the final press-ready JLT data as a PDF. I believe that this version is probably one cycle away from being ready for general commercial release. The basic functionality is currently to extract the image data and, after optional scaling, place it in a PDF. I plan to extend this to include directly generating a JPG or TIFF as well as a PDF - which will be more practical for web applications.

Second, some of you are interested in converting data to JLT. In order to do this I need a perfect understanding of the file format which the current exercise is providing me. Once this is done I will add two more features to the application. First, you will be able to load an image (JPG or TIFF) into JayLight. The second is you will be able to save the output as JLT. I also plan to allow sub-images to be imported. The first real test will be to import a sub image of an address block (say just the K color) and place it on an existing JLT - that way it will be easy to create a simple VDP-type proof of concept.

On another note - this technology was fully developed by me without access to any HP or Indigo technology an a "clean room" style of software development. Someone provided me the file "50-012775-616.prj_58_0711_1340.pdf.jlt" and asked if I could arrange it so that it could be produced on an iGen. JayLight is the result of that effort. I have a complete "process history" of how I decoded the JLT format which I hope to post here at some point in the future. I mention this because everyone interested in this project has raised concern that their "tech" will be unhappy (which unknown complications) if this program somehow "interferes" with their press.

Update to Image Resolution and More...

I have significantly improved the processing of the JLT file. This image on the right is the improved processing of the curves I described in the previous post. The processing of the details related to the masking operations works much better.

There is still work to do.

I have uploaded a file called "JayLight_021309.pdf" to the FTP area. I ask any one following this blog that also owns an Indigo to print this file and post detailed comments on the difference between what the Indigo produces on paper for the original file "Visio-JobTracking.pdf.jlt" and what the uploaded file produceds on paper.

The over all intesity of the color is something that I am unsure about. I would like to know if the image is more or less intense than the original. I believe that a compressed range of color is used in the JLT file which the press expands. What you will see with these two examples is a simple eye-ball comparison on the Mac screen.

Another area where I would like to you to looks is at the black text. I think that in terms of resolution this is as good as a low-resolution JLT gets using this specific JLT operator (I call the operator SHORT_GB). I am particularly interested in seeing how this acutally looks when printed.

The image is at the highest bit-density available for this JLT file type. I hope that the strokes look OK when imaged.

Also - anyone with multiple output devices, say an iGen or Xeikon, please feel free to image this file on that device as well. I am curious how the different RIPs handle the image.

I have some more complex test files which I am starting to work on that use an additional JLT operator. These currently have some issues and I have to integrate the current changes into this additional operator.

Image Resolution Issues

So here is the current issue. The orginal PDF has a simple curve with two colors. It looks like the image at the left.

Notice how nice and smooth the curves are?

I copied this with Grab (Mac OS X) from the original PDF file right off of the screen.

The point here is that the smoothness of the curve is based on 1) the bezier function in PDF and 2) the hi-res Mac screen. This makes it all looks very nice.

The next image is taken from the Indigo extraction program that lets you export a RIPed file to a PDF.
In this case the file is being interpreted at the basic low JLT resolution of the file (about 2500 x 3500 pixels).

The export software does a bad job of this (you can speculate as to why) so the output is very "chunky". Also there are artifacts on the inside of the curve (the "chunky" light blue area).

There is also very poor conversion of the stroke to pixels.

The actual JLT file contains another level of detail (at four times the resolution). There are special JLT operators that, when interpreted, provide a much better output.

The bottom image is my output accounting for these special operators. Due to my buggy software you can see both the "chunky" form and the "hi-res" form overlaid. The hi-res is on the outside of the curve (where I interpret it correctly). The low res is on the inside of the curve (where I do not).

If you zoom in you will see my current issue - both the low and high res are overlayed - but I suspect this is incorrect. What I think I should see is the same smooth curve inside and outside. There is also a color issue which may be interacting with this process as well - note the washed out area.