Redray codec accuracy.

[Wayne Morellini]

I'm curious how 3D-5D wavelets turned out that they use in some security camera compression (post non authentic image (noise) correction.

Your comparison, if you can compare to modern redcode, you atr basically comparing to cineform technology anyway. Kineinfinity uses an official cineform, but at what depth and quality?

So, you are saying you are taking 165MB effectively lossless redcode down to 9MB, or taking a 16 bit, 4:4:4 demosiaced frame grab to 9MB. Those 4:4:4 grabs would be incredibly devoid of much detail, as two thirds is recreated after a low pass filter smuges a lot of difference out, in a simple compressible way. Devoid of noise, 4:4:4 (especially this stuff) becomes much more compressible, and 16 bits a lot more again. Jpeg HDR used to get incredible compression rates on frames, as you are describing something that is mainly difference in peaks that are described similarly in data producing huge savings.

So, I should clarify, the 2-4:1 maxing out in the old days was 8 bit video. So, what is it now for what you are dealing with I wouldn't know. 4:1+ might he the norm on Bayer, even more again with prefiltering. Everything is largely mappable except unexpected things like noise. In testing small cameras codec quality, I will furll the things around unpredictable and examine the data rate and quality. Another one was wavey water, used to tank out and macro block older codecs, but with h264 we got smudging as a solution. However, it is possible to make the codec nap the waves, something I pushed for. With extra datarate the wave thing became a lot less anyway. But strong flapping leaves and branches swirls of mists, making most of the picture, are the sorts of things to separate out lossy cameras.

Anyway, interesting conversation I've had with cineform, or SI, which ever engineer, they objected to my pushing for noise elimination to dramatically increase the compressibility, as removing authentic image, which I politely pointed out the noise was not in the scene and the recreated pixel was likely much more authentic. But it seems to be a potential factor. But it means interesting things for lossless, as the noise was probably a main factor limiting to 2:1-4:1 max normal compressibility ratios.

It also means, that your routine might go ahead more than on normal footage because of prefiltering.

 

[konrad grant]

Cineform can do lossless and I believe higher bit depths. David Newman created cineform raw, maybe it applies there. Although, it is not mathematical lossless, by increasing things it can get there. However, it is just much better technology than jpeg2k. Hence the boost to redcode when the changed their lossy from jpeg2k. My point is that jpeg2k is not a good wavelet implementation to compare to. Xr also may produce the same quality, but at a lot less processing.

I encourage you to also ad a few lines of code to Jp2k, and see what happens. I'm actually not too thrilled it turned out the way it did, wavelets were promising.

jpeg2000 is consistent losslessly speaking .. it compresses some hard to compress images well .. but loses at the easy gains ..
j2k in lossy mode it is pretty good .. i don't think the wavelet transform does anything for lossless encoding ratios though.. in fact , i'm pretty certain it hurts it ..

i have two desires for a codec

1) in camera/ during capture = lossy for motion (duration extending..but also lossy can be faster, allow higher fps..).. but lossless for stills/ timelapse/low fps/astronomy / long exposure shots etc
2) when preserving material for the future, and during editing .. i want lossless

lots of players working on 1), .. fewer working on 2)
my ideal camera could be swung around, and would encode using different encodings settings, in an alternating pattern, using several methods for a specified time.. it would not record any files, simply compute their size..and then would dial in appropriate settings for the scene
this could be done by simply panning the camera around slowly .. a forest is very different than a living room ..

the only problem i found with cineform, ..wasn't the codec , but the debayering .. red have always done a better job imo

my system is "dumb and simple/ non -adaptive" currently..which is why i find the results so odd.. there is nothing as complex as .. say ..a paeth filter going on..
i believe , as do the creators of the FLIF format.. that the future of lossless encoding will involve machine learning.. so the format i am devising has this in mind, and will eventually contain metadata ive not seen in other formats, and the ability to understand previously undefined filtering methods of high complexity, by understanding definitions of new filters..provided they follow the filter syntaxes provided .. quality will always remain the same .. but how long you wish to analyse the image before compression will be selectable ..and scalable.. it is not intended for hardware implementation , but a software / network soloution for film, and petapixel panoramas etc

..you've got me interested in seeing what is possible in the lossy realm .. but my system is not designed for playback ..encoding is done a byte at a time , decoding one bit at a time .. both are approx. symmetric in time required .. but some of the functionality i want to support does not make large LUT/fast decoding trivial to implement .. so that is not high on my agenda yet ..and openjpeg is slower at decoding to full images..

jpeg-xr makes smaller files than j2k .. i really need some 48bit jpeg-xr test files ..or a 48bit encoder
in the meanwhile .. ill make a 24bit version of my system to do a preliminary test .. the few jxr files i created came out larger than my files .. but i need to try that on 50,000 images to get better stats ..

i don't think j2k is a great wavelet format either.. but its "out there" .. and i cannot test against what is not ..

regarding compressing helium frame grabs. i render out an 8k helium r3d grab to 48bit tiff . it is debayered .. the interpolations often create new "leave values" .. speaking in Huffman terms .. they do not reduce
so the tiff is 165mb , the jpeg2000 file is 120mb, and my files are 47mb .. that's pretty clear hopefully..
if i drop the channel depth to 10bit per component.. that's when the file becomes a visually lossless, ..and true lossless .. 30bit file .. hopefuly that makes sense ..quality is 100% .. but 10bit components ..which could be in log space..
..and here is a bit you may be missing .. even though a 4:4:4 image may be interpolated (which can only result in equal or greater image complexity btw.. never less complexity..regardless of the interpolation method..the latter being the csse with my own debayering algorithms..).. if that 9mb file was a "raw" file ..the leaf count CAN ONLY DROP ..as "leaves created through high quality interpolation" are removed.. but even if no leaves disappear .. i definitely only need to write 1/3 as many codes out to disk .. so the file .. i can say with certainty .. could become 3mb in raw format ..

of course , with a lossless system .. there can be no data rate control

i would prefer to save the full sensor readout verbatim .. even if it contains transport noise and the likes .. as software noise reduction can be more complex than a fixed hardware solution, and can improve over time..so the image can be reinterpreted .. but the lossy wavelet transforms in j2k are in effect noise reduction filters anyway .. but that might make a deeper noise reduction algorithm less effective later on .. and pre compression filters can compensate / reduce noise , through good prediction .. which my system does not do.. yet ..

anyway, once a shit is recorded in camera.. i don't care .. my problem has always been ..where to put the finished D.I .. which normally means deleteing something else !

 

[Wayne Morellini]

Yes, they found many years back, that wavelet produced much better results at high compression against newer codecs (back then) than at lower rations. But we are at least a generation past that now in non wavelet technology. The thing about cineform, is that they handcraft for speed and results. At some point, it effectively become lossless as you drop the ratio too. Even mpeg2 would do that. At some point it pats to switch how you comp esss (and not just once, hint). Even jpeg basically models one wat, and tries to compress the bits that font conform to the model. Now, magine if you could examine the data and compress hundreds of different ways according to which worked vest against others in different parts of the image. Of course, I'm encouraging the industry to keep going down a wastefull path here, where maybe millions of sets of analysis has to he done before you determine the best set (unless they have a mind to short cut this).

For my universal file compression ideas, I determined you could make a compression scheme that resulted in optimal compression for each data types, maybe plus some overhead. All without you figuring it out. You know why I know thus, to us the answer is obvious, to others it seems non obvious, obscured. They are probably scrambling to figure out what I mean and how to do it. We are talking many many billions of GDP per year with some of these technologies. Of course I'm being obscure again, as I often am, usually just painting part of the solution, and lesser solutions.

Lol, I just read the rest past the first paragraph of your post. We are on the same mind as I thought. So, yes, you should be able to get lossless for playback, however according to my calculations human imaging can go into terabytes per second datatates (or was that terabits, I forget). That still means a big need for lossless, unless I can get my high end lossless out. That would be one of the biggest achievements of computational design. But I don't usually stop until I have the ideal (perfect) answer in these sorts of things. Where as in physical design we see so little, beyond the logical aspects, it is hard to know how good the solution is compared to the unkown ideal solution. Even if you know the ideal solution, it may well involve things of such intricacies, it is hard to understand, like things of the plsnk scale, or smaller to get the best possible solution. But in logic, it is possible to determine an ideal path. Except with this, it is applying the logical to the real world, which we don't fully understand. But as we are not recording much below 2400dpi, the rest does not matter too much in exact detail, and if I can get within 1% of the ideal result (1% measured against the 100% of the ideal result) , I would be happy. If I had to compress the plank space, or just subatomic, on the other hand, it might he extremely inefficient, because we don't undrestsnd that space. Too much for neurotypicals.

 

[Elsie N]

Guys, instead of inventing a new wheel, why not just use this one that google just released?

 

[Wayne Morellini]

.........., some of that is like what I was suggesting in the elphel cinema camera projects before I gave up on them, that was one of the things that caused me to give up. I wasn't well enough to get into it, and one of the guys gave it a try but couldn't get it to work. Thank you Mr Google, and others that proved me right. It wasn't it was going to be best compression, but lower processing easier compression.

I had a dispute with a top engineer I went to university with in the day. I claimed I could get better compression than some law limiting compression he was quoting (like a follower). It was through prediction in a certain way.

We are talking about a lot bigger differences Elsie, even compression to less than 0.1%. I actually am one of the people that did reinvent the wheel, so don't go throwing that one around me too liberally.

I will review this as an off the shelf solution for software recorder (as it with take considerable time to write and tune codec designs, usually.

 

[Wayne Morellini]

What Google and web standards have been interested in is free open standards with no licensing. This is likely another attempt at a codec using free IP to do what an existing one does.

Now, Jpeg has jumped in quality, at lossless I don't know, but it wasn't a top lossless performer anyway, so this may not be a great thing to compare to. Only 26% smaller is NIR as good as 74% smaller, that would he great.

I'm happy to shift product with a competent codec, rather than shift with one of mine without protection. Thanks for the heads up.

 

[konrad grant]

Guys, instead of inventing a new wheel, why not just use this one that google just released?

elsie .. its just not a good wheel . i intended to spent 6 months creating something with better compression ratios .. as i had bit of space ..but my initial prototype did that after 3days working on it..to my enormous surprise..using "very old algorithms" .. (improvements have been small since then.. but i'm collecting statistics..getting ready to test some more advanced/complex ideas..)

.. the openjpeg2000 encoder project is now one of the few reference jpeg2000 encoders .. its taken years , and two google summer of code pushes to get it there (ie, massive support)

..but my files compress 56% smaller on average .. without the complexity.. so i'm personally happy to leave google to design the next generation of internet bloating formats .. whilst i help you make bit-for-bit backups of material that's important to you , that takes up less space

check out the free lossless image format elsie .. that is currently the cutting edge of lossless encoding imo..but is slow..as it uses machine learning. it is built into imagemagick already, but may not be finalised yet.. one of the designers of that, jon sneyers emailed me the other day after i sent him a linkedin message .. not had time to quiz him about its status yet . my compression system uses imagemagick to grab images , and it can also encode into any format imagemagick supports. in the meanwhile you can try the format by executing . its very impressive on large images in terms of compression ratios

<imagemagick from command line>: convert <yourimage.tif etc> <yourimage.FLIF>

@wayne : the recent improvements to jpeg are just changes to the DCT coefficients from what ive read . jpeg lossless uses a completely different encoding system, so if my assumptions are correct..that won't affect jpeg lossless ..which is the compression system used by DNG .. right there is the problem .. new formats using old compression routines from 1992 .. when machines had 128kb of ram ..

 

[Wayne Morellini]

Sorry, I forgot to specify. Yeah, JPEG 1 for lossless is not that good By recent I meant going back 14 years. Actually jpeg lossless was like something I was proposing that was dismissed, but there you have it, somebody else proved it in an industry standard no less. You think some of these people that supposed tp know this stuff must be clean rooming for decades to miss that one. I basically work from the ground up pretty clean room except for free stuff with any patent expired. I did this with my is design, I got texts from University of South Australia that were rather old and read and reinvented and invented new, and did uni by the end I started uni (but still with old text and tech). I got the department of defense published standards paper on security management to read up on some auditing managed systems process but never got to read it, and had done my own process anyway. This whole mantle/metal api thing, is like I was designing the OS from the beginning. Java/Oak Toas and my simple VOS all virtually started the same year. Only one wasn't close to funding markets and didn't receive funding. Java was the least efficient design, and Toas undoubtedly the second most efficient, but blew Java away. In matter of fact, the leading PC Java/JavaScript (a blur now) engine was a Taos derived product from them, one which other's tried to be like to get more performance.

 

[konrad grant]

Sorry, I forgot to specify. Yeah, JPEG 1 for lossless is not that good By recent I meant going back 14 years. Actually jpeg lossless was like something I was proposing that was dismissed, but there you have it, somebody else proved it in an industry standard no less. You think some of these people that supposed tp know this stuff must be clean rooming for decades to miss that one. I basically work from the ground up pretty clean room except for free stuff with any patent expired. I did this with my is design, I got texts from University of South Australia that were rather old and read and reinvented and invented new, and did uni by the end I started uni (but still with old text and tech). I got the department of defense published standards paper on security management to read up on some auditing managed systems process but never got to read it, and had done my own process anyway. This whole mantle/metal api thing, is like I was designing the OS from the beginning. Java/Oak Toas and my simple VOS all virtually started the same year. Only one wasn't close to funding markets and didn't receive funding. Java was the least efficient design, and Toas undoubtedly the second most efficient, but blew Java away. In matter of fact, the leading PC Java/JavaScript (a blur now) engine was a Taos derived product from them, one which other's tried to be like to get more performance.

I'm confused by java/javascript .. they are not connected in any way , other than being programming languages .. but they share no common ancestor , or development, and are not similar in any way ..other than the misleading name ..

from oracle:

How is JavaScript different from Java?
The JavaScript programming language, developed by Netscape, Inc., is not part of the Java platform.
JavaScript does not create applets or stand-alone applications. In its most common form, JavaScript resides inside HTML documents, and can provide levels of interactivity to web pages that are not achievable with simple HTML.
Key differences between Java and JavaScript:
Java is an OOP programming language while Java Script is an OOP scripting language.
Java creates applications that run in a virtual machine or browser while JavaScript code is run on a browser only.
Java code needs to be compiled while JavaScript code are all in text.
They require different plug-ins.

 

[Wayne Morellini]

That is old times. It is not right to say they are not connected. Originally JavaScript, used Java, in the sense that they used some Java API's. JavaScript could be compiled to java byte code and run. Things have diverged (and the web people hate plugins now. Which is a pity). It is correct to say the language itself is not the same. Anyway, you are not interested in web services, so it may not matter for your purposes. (I'm also need to look this all up to make sure my memory is not failing me).

However, things have changed as desktop libraries were released for independent Javascript desktop applications. Now, Javavscript is to receive its own virtual binary code. It is no longer that Java and Javascript are separate, it is that most platforms support JavaScript, that Javascript has won in my opinion for desktop and wen purposes. You can develop to Javascript API (even in c) and get a portable application to future host environments as JavaScript support is ported to them. Of course the world is more messy than that, but it is a good sentiment.

I am delighted, I was getting ready to learn JavaScript and make my own virtual binary code on it that used the JavaScript api. Then I find out the community was preparing to do it, bonus, I can just use a subset of the javascript api with that binary for portability in an engine written for whatever mobile phone chipset for low powered gadgets. That cuts out a lot of initial work. I can doy own binary some other time.

I was planning to propose to the Linux community to write the majority of applications to the javascript platform in the binary, for portability between OS's, so any OS has an instant library by porting javascript. Except for applications that require extra performance, that are dine natively as much as needed. Most applications don't require the most performance. So, except games, 80%+ of applications could just use javascript. This would remove do.e of the biggest obstacles in computing.

 

[konrad grant]

That is old times. It is not right to say they are not connected. Originally JavaScript, used Java, in the sense that they used some Java API's. JavaScript could be compiled to java byte code and run. Things have diverged (and the web people hate plugins now. Which is a pity). It is correct to say the language itself is not the same. Anyway, you are not interested in web services, so it may not matter for your purposes. (I'm also need to look this all up to make sure my memory is not failing me).

However, things have changed as desktop libraries were released for independent Javascript desktop applications. Now, Javavscript is to receive its own virtual binary code. It is no longer that Java and Javascript are separate, it is that most platforms support JavaScript, that Javascript has won in my opinion for desktop and wen purposes. You can develop to Javascript API (even in c) and get a portable application to future host environments as JavaScript support is ported to them. Of course the world is more messy than that, but it is a good sentiment.

I am delighted, I was getting ready to learn JavaScript and make my own virtual binary code on it that used the JavaScript api. Then I find out the community was preparing to do it, bonus, I can just use a subset of the javascript api with that binary for portability in an engine written for whatever mobile phone chipset for low powered gadgets. That cuts out a lot of initial work. I can doy own binary some other time.

I was planning to propose to the Linux community to write the majority of applications to the javascript platform in the binary, for portability between OS's, so any OS has an instant library by porting javascript. Except for applications that require extra performance, that are dine natively as much as needed. Most applications don't require the most performance. So, except games, 80%+ of applications could just use javascript. This would remove do.e of the biggest obstacles in computing.

according to my friend who gets paid a "LOT" of money to write/maintain code for a large bank from home.. but only actually has to write / fix someone elses code about once every 3months by the sounds of it.. repeated : java is to javascript , what cars are to carpets ..absolutely no connection according to him.. nil..zero .. but as you say, javascript may have been implemented through java/plugins etc .. yes, i dislike java..except for its arbitrary precision maths library..and javascript ..wtf is that?..hangon..don't tell me!!.. i'm happy to be wrong .. as ive not formed my own opinion

i created my own version of basic when i was 17.. and it was .. back when screens were green ..nowadays i collect books on compiler design.. just in case ..
..i also invented multithreading .. before the days of windows/protected mode .. i believe the old dos timer interrupt i used to hook into was $1C .. pc plus magazine paid me £75 in 1989//those were the days .. when porn was dithered and only viewable by standing 15ft from your monitor and squinting.. before computer video formats existed ..and came as an executable .. and was watched and enjoyed only because it was a technical achievement ..

ps, i'm finding j2k and jpeg-xr are quite closely matched .. but j2k is still winning in my 24bit compression tests .. really need to find a 48bit xr encoder .. found some source code ..might need to actually try and compile one myself .. with a c compiler ..urrr!!

 

[Wayne Morellini]

He gets paid how often. Again, there is Java the language and have the system and api. I could make language whatever 'based' on a specification of subset of the Java system, it might be based on Java, but not the Java language.

As he is a code maintainer, he might like to research the JavaScript developments of the last 5-10 years, where a lot of the action was. I wasn't up to posting links on it late last night, or at the moment. But a lot if the older developments were rolled into firefox OS. Javascript was knockrd together well by somebody that knocked together languages quickly in those days. It didn't have java in the name, that was added to popularise it. They worked out something with the old Java owner to use the name. Best to think of it as a old script for java system rather than the language. Personally, I think they should have tried to make it a syntax subset and true subset of Java language to, so that people could write code in subset between the two, and Stoll retainrdva simple implementation, would have resolved a number of things. But they didn't. Anyway, forget about the Java thing, the game is now more javascript as far as cross platform support.

Lol, the Tandy color model . I guess you mean CPM, IBM PC xt, Hercules card,or Amstrad PCW (one of my favorite computers. Can learn a lot about design from gnat thing, the edition of two more shades made a good difference to the abstraction of the graphics. Versus the mac).

Oh good, an old timer around here with normalised function. No wonder you are easy to talk with. All these new found kids with the attitudes and twitter. I mean what is that, you practically ate calling yourself a twit. In pur day s you actually had to keep computers near a power point, and not one of those new found Microsoft things....

Neither one of us invented mutual threading I am afraid, probably been going since before we were born.. When I did my revolutionary os technology, when I got to find out about mainframes and mini computers, I found my design had broad elements of them. No surprise, as I was gravely influenced by the notion of the commodore serial bus having independently run hardware attached to it (where normally on the PC drives were heavily dependent of the system. IDE followed this trend. The commodore serial bus was based on a HP serial bus, which would have been affected by previous mainframe/mini design philosophies. So, it is inevitable that we both come to optimal design solutions that are somewhat similar (except there was only one of me, not like 10k to 1m people working towards the mainframe/minis.

No, I'm impressed. Not like many around here that run/use/maintain somebody else's ideas and think they know it all without much independent thought past input.

 

[Wayne Morellini]

From Wikipedia JavaScript page (or what I now called "Doctor Google"of Google university). Thankfully I didn't have to spend time lookung around the web for this.

https://en.m.wikipedia.org/wiki/JavaScript

Although there are strong outward similarities between JavaScript and Java, including language name, syntax, and respective standard libraries, the two are distinct languages and differ greatly in their design. JavaScript was influenced by programming languages such as Self and Scheme.

JavaScript is also used in environments that are not Web-based, such as PDF documents, site-specific browsers, and desktop widgets. Newer and faster JavaScript virtual machines (VMs) and platforms built upon them have also increased the popularity of JavaScript for server-side Web applications. On the client side, developers have traditionally implemented JavaScript as an interpreted language, but more recent browsers perform just-in-time compilation. Programmers also use JavaScript in video-game development, in crafting desktop and mobile applications, and in server-side network programming with run-time environments such as Node.js

Netscape Communications realized that the Web needed to become more dynamic. Marc Andreessen, the founder of the company believed that HTML needed a "glue language" that was easy to use by Web designers and part-time programmers to assemble components such as images and plugins, where the code could be written directly in the Web page markup. In 1995, the company recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator. Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language Java, in order to compete with Microsoft for user adoption of Web technologies and platforms.[11] Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995.

Although it was developed under the name Mocha, the language was officially called LiveScript when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but it was renamed JavaScript[2] when it was deployed in the Netscape Navigator 2.0 beta 3 in December.[12] The final choice of name caused confusion, giving the impression that the language was a spin-off of the Java programming language, and the choice has been characterized as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new Web programming language.

A common misconception is that JavaScript is similar or closely related to Java. It is true that both have a C-like syntax (the C language being their most immediate common ancestor language). They also are both typically sandboxed (when used inside a browser), and JavaScript was designed with Java's syntax and standard library in mind. In particular, all Java keywords were reserved in original JavaScript, JavaScript's standard library follows Java's naming conventions, and JavaScript's Math and Date objects are based on classes from Java 1.0,[117] but the similarities end there.

In January 2009, the CommonJS project was founded with the goal of specifying a common standard library mainly for JavaScript development outside the browser.[26]

Java introduced the javax.script package in version 6 that includes a JavaScript implementation based on Mozilla Rhino. Thus, Java applications can host scripts that access the application's variables and objects, much like Web browsers host scripts that access a webpage's Document Object Model (DOM).[86][87]

Firefoxos, now officially discontinued at Mozilla, but continued development at Panasonic and supposedly at another private company by former developer of it at Mozilla, but I have not seen a current reference there for a while. This is the biggest shame. Mozilla though has been behind on something's.

https://en.m.wikipedia.org/wiki/Firefox_OS

https://en.m.wikipedia.org/wiki/Google_Native_Client

https://en.m.wikipedia.org/wiki/WebAssembly

https://en.m.wikipedia.org/wiki/Asm.js

Note, I don't agree with their use of syntax, I am using the notion of deeper usage than this.

I think I read commonjs is now being demoted.

Eich apparently readily put together languages, so had experience, and I would think a code tool set (not likely to be written from scratch but put together and confirmed to the present JavaScript syntax, which is still a big feat in 10 days (and perhaps some previous complementation, planning and pre work. I was so sick and tied years ago of a certain long running project, I was thinking of doing something like my own simple os system over 6 months and codec, and then with some research and pre planning likely, do the camera in 6 weeks (even 2 weeks, as most of the work is done in the os and codec, and the camera becomes little more than setting up a rudimentary program and GUI controls) and watch the look on their faces. If you have a good fast (unlike me) programmer experienced in the area or at least maybe realtime embedded etc etc programming, that knows his stuff, they should be able to do those simple camera recorder like app using api's in 2-6 weeks, not 18 months+ I think using an existing camera recording code base (hard to remember, there were a few projects floating around, with a professional programmer, while not recognising publicaly advice on real time embedded programming and setting up windows for this (I had been advised by a machine vision company that set their cameras up for use in cinematic filming that it was simple "trick" to achieve reliable recording (and not knowing the details on setting up a realtime embedded environments on windows (which had a history), this was my estimation too). I knew people setup windows realtime, and even replaced the core with a realtime nuclease. Anyway, windows advanced. They actually adopted the TRON realtime nuclease. Tron was a Japanese wiindows challenger project that saw widespread use in consumer electronics and other embedded spaces, and was very superior. Home edition didn't see so much success over the years. Unfortunately things like Java, Dos, Windows, JavaScript, c, suck the air out of the room, away from better solutions.

As you can see, the Oracle statement doesn't fully cover everything, it is making it more clearly separated for people to understand.

For me it is simple business economics, JavaScript is simply the most wide spread common target to develop for, and if it became more standardise for standalone across embedded and desktop spaces, it could be a good thing.

Frankly, if they had compatibly sub-setted Java in the first place it would have been much better for the web and the industry. I think JavaScript came off of embedded java specification, but can't remember. They simply could have cored out Java, and added a functional mode (Java 8 received functionality) preserving binary with scripting, as in latter web assembly, it would have been great. Hopefully web assembly pushes things in a better direction than standard java bytecode though. It's interesting that after all the stuff about the original android virtual code, it proved worse than bytecode instead in various tests. The new ART environment did better, and now follows what I wanted, to compile the virtual code to real local binary code once, and use that. They also allow use of native binary code segments to be in the package so it can be used for the specific processor type of the target, which allows for efficient handcrafted machine code, thus removing most of the penalty of android for high performance applications (obviously not all) like games. If only I could run webassembly binary version of resolve.

Something like JavaScript webassembly opens up the adoption of new better technologies and systems, as they only need to support its codebase to have wide spread userability from the start.

Anyway, nothing you need anyway, as you only have to target PC, Linux and Mac OS, and sell code picture archival companies.

 

[Nick Timmons]

Conrad, just...wow

 

[konrad grant]

Conrad, just...wow

which bit is confusing you ? ..jpeg being computationally crap .. or javascript being systematically sh*t ? ..or my research into image compression , that's has made me think wow nearly everyday this week.. give us a clue .. wow is so vague ..and doesn't really contribute much ..

 

[Wayne Morellini]

Yes, Nick, your post is about the only confusing thing here at the moment?