This Community site is new! Please help us build a community around the JNIOR.
Sign up, and help share your knowledge. Please sign-up even if you do not plan to post as a sign of support.
If there is evidence of a demand we will continue to develop the content here.

Image Support

You got ideas? Let's hear 'em. Here we can talk about your experiences programming on the JNIOR or items that you may wish to have INTEG assist you with.
Post Reply
bscloutier
Posts: 401
Joined: Thu Sep 14, 2017 12:55 pm

Image Support

Post by bscloutier » Tue Dec 26, 2017 12:11 pm

It is said that an image is worth a thousand words.

There are many applications for the JNIOR in a wide variety of fields including control and monitoring. In the case of monitoring that could involve many different requirements such as event detection and data collection. Data can be collected for logging purposes and might never be reviewed but when we do look at the data we often like to see it graphically.

Presently JANOS does not provide a graphics facility. The accepted way to approach it is to create the required graphics on the client-side. Typically raw data is collected and transferred to the browser which executes supplied scripts designed to refine the supplied raw data into graphical form. While this works the user experience can be impacted in so far as the raw data will take time to transfer and it will take time to create the graphics. Client-side graphics package versions do vary and there could be differences in the end presentations. It is also not generally efficient in that every view of an application's web page will require recreation of the graphics. The latter can be mediated with the careful use of caching which requires some clever programming.

The alternative is to create graphics on the server-side. Most forms of server-side scripting are capable of creating an image and graphing data. These can also impact the user experience if not carefully implemented. You can argue that the client PC's processor is much more powerful than the JNIOR and so on that basis alone it makes sense to do the graphical processing on the client machine. In many cases that may be true.

Right now JANOS cannot generate a graphics file. Since applications written in Java can create binary files of any content they are certainly capable of constructing a valid graphics file but that, short of a small blocks of uniform color, would be programming insanity. If it were to be done it certainly needs to occur at the operating system level.

I can make that happen. I suspect that given the embedded nature of the product that we should implement only one graphics standard. I would select PNG. The tools too should be data oriented and not photo oriented. I can envision the usefulness here in graphing monitored data such temperature plots and newspaper counts.

bscloutier
Posts: 401
Joined: Thu Sep 14, 2017 12:55 pm

Re: Image Support

Post by bscloutier » Fri Dec 29, 2017 9:28 am

Originally (over 25 years ago) a graphics format for images GIF was devised which utilized LZW data compression. This is a highly efficient and easily implemented form of data compression which made for a very small and efficient means for image storage and transfer. This became the standard for images to be delivered by Web servers. However, the compression technique had been patented (US 4558302) eventually encumbering the implementation of the GIF format. To avoid the issue new and openly available graphic image formats were developed.

Presently the PNG format seems to be universally accepted. This also uses a version of data compression algorithm (LZ77) developed along with LZW but that has not been patented. We know this as DEFLATE and it is used in compressed file collections such as ZIP and JAR. See Portable Network Graphics (PNG) Specification (Second Edition).

JANOS decompresses DEFLATE data routinely. Application programs are contained in JAR files and the JANOS Web Server can deliver files directly from ZIP archives. The JAR command and its alias ZIP can be used to examine and extract data from JAR or ZIP files (the two are essentially the same format). There has been no need to this point for JANOS to compress data using the DEFLATE algorithm as we have not supported the creation of such libraries. It has been on the suggestion list.

Given this, JANOS today should be easily modified to open and then access PNG image content. This by itself is of limited usefulness as the JNIOR does not render images on any display nor is there sufficient processing power to attempt to process complex images for AI or any other purpose. There is value though in being able to create images to portray collected data in graphical form either linearly, as a histogram or other format. To do this we need a DEFLATE compressor.

An added benefit will be the ability for JANOS to create or modify JAR and ZIP files. This may be of great interest in archiving log files or other data. So that is where we start. I need to write the compressor to sit alongside the existing decompressor.

Post Reply