TEKYILDIZ, Ahmet

GUTIERREZ, CLEMENT

Krepa, Michal

JPEG Encoder

Excuse me ,I have some qustions about BUF_FIFO,the raster write controller how to generate ram_waddr for SUB_RAM?

8*8 image block

Hello, 
I'm going to use the core for some embedded project. I started with behavioral simulation, but the result in incorrect. I mean the "test_out.jpg" file is invalid. It means the core is not working properly.
Could someone help me fixing this issue?
Thanks in advance!

Problem in simulation

Hi, 

I've recently tested this project on a Kintex 7 -2 FPGA with VVD 2015.4.

It runs correctly and generated good jpeg image. The fmax is ~180MHz.

When I tried to improve fmax, I found that critical path is U_ROMR/datao to multiplier input, which is not registered at all. I tried to reg "romr_datao" and "a" and fmax improved to ~210MHz.

Don't forget to change U_quantizer/pipeline_reg width from 5 to 6, cause r_divider add a stage of pipeline.

Improved r_divider timing

Hi,
I compressed a completly blue image with the Jpeg Core and the resulting picture shows a vertical red line at the right side of the image. The line is round about 6 pixels from the image border and heavily depends on the choosen compression. 
If i use the table without any compression, there are no artifacts at the right boarder and with increasing compression, the artifacts get more and more. 
The blue screen was generated by a testpattern generator inside the fpga so i think the "original" image could not be cause these artifacts. 

Is it possible to post the image here?

There are any idea what part of the core can cause this behavior?

Artifacts at the right side of the Jpeg

I am finding JPEG Encoder supported the restart marker. Do you have a plan to support ? if No plan, please give me a advise to implement it.

restart marker

hi,
Could you please tell me how to simulate the JPEG Encoder core.
I'm going to use Synopsys for simulation. Can you send guidelines for simulating the code?

Thank you!!

Untitled bug

In the latest SVN revision, there is a potential to corrupt the header data stored in JFIFGen.  Specifically, the recommended initialization procedure is to write the image size, followed by the two quantization tables.  However, the JFIFGen state machine is busy for five clock cycles after updating the image size, while it stores the new size information.  If the first quantization table entry is written immediately afterward, then the state machine will still be busy when the new data arrives, and the update will be lost.  The result is an incorrect entry in the final JPEG header.

My proposed fix is to prioritize incoming quantization table data, and write the updated size information while the memory is otherwise idle.  See below:

Change #1: Shorten size_wr_cnt from 3 bits to 2 bits
  signal size_wr_cnt  : unsigned(1 downto 0);

Change #2: Prioritize updated size information
  p_host_wr : process(CLK, RST)
  begin
    if RST = '1' then
      size_wr_cnt <= (others => '0');
      size_wr     <= '0';
      hr_we       <= '0';
      hr_data     <= (others => '0');
      hr_waddr    <= (others => '0');
    elsif CLK'event and CLK = '1' then
      hr_we <= '0';
    
      -- Note the fact that size has updated.  Write the four bytes
      -- during idle periods, so we don't accidentally clobber changes
      -- to the quantization tables, etc.
      if image_size_reg_wr = '1' then
        size_wr_cnt <= (others => '0');
        size_wr     <= '1';
      end if;
      
      -- Write any quantization table updates immediately.
      if qwren = '1' then
        -- luminance table select
        if qwaddr(6) = '0' then
          hr_waddr <= std_logic_vector
                        ( resize(unsigned(qwaddr(5 downto 0)),hr_waddr'length) + 
                          to_unsigned(C_QLUM_BASE,hr_waddr'length));
        else
          -- chrominance table select
          hr_waddr <= std_logic_vector
                        ( resize(unsigned(qwaddr(5 downto 0)),hr_waddr'length) + 
                          to_unsigned(C_QCHR_BASE,hr_waddr'length));
        end if;
        hr_we   <= '1';
        hr_data <= qwdata;
      -- Write the new image size when otherwise idle.
      elsif size_wr = '1' then
        case size_wr_cnt is
          -- height H byte
          when "00" =>
            hr_data  <= image_size_reg(15 downto 8);
            hr_waddr <= std_logic_vector(to_unsigned(C_SIZE_Y_H,hr_waddr'length));
          -- height L byte
          when "01" =>
            hr_data <= image_size_reg(7 downto 0);
            hr_waddr <= std_logic_vector(to_unsigned(C_SIZE_Y_L,hr_waddr'length));
          -- width H byte
          when "10" =>
            hr_data <= image_size_reg(31 downto 24);
            hr_waddr <= std_logic_vector(to_unsigned(C_SIZE_X_H,hr_waddr'length));
          -- width L byte
          when "11" =>
            hr_data <= image_size_reg(23 downto 16);
            hr_waddr <= std_logic_vector(to_unsigned(C_SIZE_X_L,hr_waddr'length));
            size_wr  <= '0';  -- Last byte --> done.
          when others =>
            null;
        end case;
        size_wr_cnt <= size_wr_cnt + 1;
        hr_we <= '1';
      end if;
    end if;
  end process;


 This is just long enough that it can overlap with the first quantization table entry, and the updated table entry is lost.  If the new quantization table differs from the 

If This is enough time to receive the first entry in a new quantization table.  a new size i

If a quantization table entry is written immediately after the image size is changed, then the JFIFGen RAM may miss the first entry or tw

Quantization header missing update

Hi 

I would like to use the JPEG compressor using YCbCr as an input, 4:2:2 in 16 bit.  I have set the flag C_YUV_INPUT to ‘1’ to allow this input.

What is the correct byte ordering using the 24bit fifo to the FDTC module?

Steve

YCbCr input

hello!!!!
Could you please tell me how to test(simulate)the JPEG Encoder core:

1) which tool i should use ? ( xilinx or Modelsim or quartus)
2) steps to be followed ...

i have tried also read document but facing some problems.....

please help me out....

thanks in advance

simulation

Some parts of the design (/common/FIFO.vhd) use a synchronous reset while the rest of the design uses an asynchronous reset. It's not really a bug, but inconsistent design, and it caused a lot of trouble for me.

I think the whole design should use either synchronous or asynchronous reset

reset

signal "memswitchwr_s" in mdct.vhd needs to be delayed by two cycles, otherwise the last two outputs of DCT1D are written to the wrong memory because "memswitchwr_s" switches to early.

mdct - memory switching

This bug is reproducible in about 5% of resets.
To reproduce it, you need to reset encoder - if you are lucky enough, the bug will show up (~5% reproducible). The corrupted stream will continue to show up for each encoded frame (with those vertical lines) until you reset the encoder again. In most cases after reset it starts working fine. Then you can reset it again several times, and this bug can show up again.

Please help me to understand where might be the reason for it and how to fix it.

An example of corrupt frame is here: https://plus.google.com/photos/100915540970866628562/albums/5755521382198971601?authkey=CPau-p_7kbHynQE

Encoder corrupts - Vertical lines on encoded image

Hi,
Simulation of this project in Modelsim is OK in per-synthesize mode.
But post-layout simulation results aren't as good as per-synthesize mode:
When fdct_start signal activates, after 10 clks all output signals go to unspecified sates! The fdct_ready is the first signal that goes to unspecified state.
Thanks,
Mahdi.

Post Place & Route

Dear Michal,
Hello,
What changes have to do in mkjpeg for more compress ratios?
It will be done simply by changing some parameters in the code or it is more complicated. 
Thnaks

More compress ratio

-- The HeaderRam.v file has error
-- this vhdl file fixes the probloem
-- the error is in position of assignment of read_addr <= raddr;
-- HeaderRam.vhd Khaleghian 8 Nov 2010

library ieee;
library work;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use work.all;
entity HeaderRam is
port (
    d       : in STD_LOGIC_VECTOR(7 downto 0);
    waddr   : in STD_LOGIC_VECTOR(9 downto 0);
    raddr   : in STD_LOGIC_VECTOR(9 downto 0);
    we      : in STD_LOGIC;
    clk     : in STD_LOGIC;
    q       : out STD_LOGIC_VECTOR(7 downto 0)
);
end HeaderRam;

architecture syn of HeaderRam is
type    ram_type is array (1023 downto 0) of std_logic_vector (7 downto 0);
signal  RAM     : ram_type;
signal  read_addr: STD_LOGIC_VECTOR(9 downto 0);
begin
    q <= RAM(conv_integer(read_addr)) ;
    process (clk)
    begin
        if clk'event and clk = '1' 
        then
            if we='1' then
                RAM(conv_integer(waddr)) <= d;				
            end if;
	    read_addr <= raddr;
        end if;
    end process;
end syn;

Fixing the bug in HeaderRam.v

Hi,
It seems the latest REV, (REV 42, stall by output) is not accessible in SVN. Would you please check it again?

Regards

Browse

JPEG Encoder