|
|
| |
 |
No, you would need a demosaicing filter inserted between the sensor and the core.
|
|
|
|
The first JPEG2000 core was introduced in 2002, and at that time it was the first IP in the market
|
|
|
|
Yes. The JPEG2000-E core has been used in a number mil/aero applications, such as UAVs and satellites, and it is production proven both in the form of FPGA and in the form of Rad-Hard ASICs.
|
|
|
|
The core can be targeted to any ASIC or FPGA devices
|
|
|
|
It’s coding efficiency resulting from the wide support of the standard and the efficient rate-control, it’s maturity and it’s ease of integration.
|
|
|
|
No. Some vendors may use the so called “parallel mode” and “bypass” coding switch to simplify and/or speed-up the hardware architecture. This practice has a negative impact on coding efficiency. For example in the case of the “boat” image there is a degradation of PSNR up to 3dB in lossy mode. In lossless mode, file sizes can be more than 20% larger, as in the examples below.
Furthermore, the rate-distortion performance heavily depends on the rate-control algorithm, which is not part of the standard. Our rate-control algorithm provides quality practically equivalent to that of the Kakadu software and 3% maximum deviation from the target rate.
|
|
|
|
The core’s throughput is in the range of 1.4 cycles/sample upto 10 cycles/sample depending on the number of entropy coders instantiated. The number of entropy coders of the core, is configurable at synthesis time.
|
|
|
|
Yes, the core was designed to ease parallel processing. Apart from register programming, you would only have to mux inputs and outputs.
|
|
|
|
The core memory requirements depend on a number of parameters like tile-size, number of quality layers, number of entropy coders etc. We provide a spreadsheet that calculates the memory requirements based on your preferred parameters.
|
|
|
|
Yes, the core can output JPEG2000 stream in CPRL and LRCP progression order
|
|
|
|
|
