Unix vs. Windows…

I do not try to start a debate on which is better or not, I am just trying to understand why using same formulas to convert from YUV to RGB, capturing the same frame, under same light conditions, same piece of hardware, same lens, etc the colours on Mac OS (Unix) looks more natural then on Windows (7) running on same computer, same time, using Vmware. Any idea?

MacOS vs Windows7 in images


Image captured in YUV211 format and converted to RGB using the formula from here on Windows/VB (centre top) and on Mac OS/Processing (centre) .


17 thoughts on “Unix vs. Windows…

  1. I have followed your project with interest. I am working to develop a similar project with the OV7725, but I am having trouble reading the image out of the AL422B. I must be misreading the timing diagrams, which I do find confusing. I have tried and tried to get it right, but so far nothing works. I seem to be somehow skipping pixels. Also it looks like I am not reading at the correct times, since I get what looks like noise. It is very, very frustrating. If you could explain how you are doing it, and share that part of your code, that would be great! Also, as a general request about your blog, is it possible to allow replies without forcing readers to go through facebook, wordpress, or twitter? None of these options are real possibilities for me, so I had to use the account of a friend. Thanks so much for any help you can provide about reading from the AL422B.

    • Hi there, I’ll check on the reply part, I did not know need an account to post a reply, will check on it.
      Regarding AL422B issue, can you advise on the connectivity? Are you setting the /WRST to low for at least 2 XCLK cycles when you initiate the capture? If you are using VSYNC for this, do remember that VSYNC is LOW during the frame and HIGH outside the frame, so you will need to “negate it” using Bit1 in COM10 register, see OV7725 manual. If you are getting the noise is usually caused by wrong timing on your signals driving the writing on AL422B and not the reading part. Check page 9 in AL422B data sheet and page 9 in OV7725 data sheet for timing. Can you provide a schematic on how you connect your OV7725 to AL422B? Maybe that will help…

  2. Thanks for the quick reply. I write to the FIFO this way. The camera VSYNC interrupts my controller (AVR UC3A) at the rising edge. In the interrupt routine, I reset the write pointer in the FIFO to 0 by pulling /WRST low for a couple of cycles and then setting it high again. I set a pin on a NAND and exit the routine. The inputs to the NAND are this user pin and HREF. The output is /WE. When /WE is low (when both the user pin and HREF are high) the output from the camera is written to the FIFO. The clock into the camera is running at 24MHz. The camera’s pixel clock is running at 48MHz. The pixel clock outputs to the write clock of the FIFO, which is supposed to operate up to 50Mhz. I am hoping I got all this stuff right. It never occurred to me that the problem could be on the write side. Unfortunately I don’t have a scope, so can’t check things. I am not sure how to provide a schematic, since I don’t see a way to attach anything to my reply. I will check on posting mechanism to see if I can reply with only a name/email address. Thanks again for any help.

    • Hi, not sure where you got the 48 Mhz from, but the pixel clock should be based on resolution.
      Your schematic should be something like this I guess:
      AL422B control

      And the logic is, correct me if I’m wrong: VSYNC rise -> interrupt -> /WRST LOW -> /WRST HIGH -> WE HIGH.
      I will do a small change: inside of VSYNC interrupt add a counter, when counter is 0 then WRST HIGH and WE HIGH, else WRST LOW and WE LOW, reset the counter after you read/process/stream/etc your frame. In this case you do capture a frame and hold it in FIFO till you end the reading, same like a picture.

      The read cycle, page 9 in AL422B datasheet, is then simple: RCK HIGH -> RRST LOW -> RCK LOW -> RCK HIGH -> RCK LOW -> RCK HIGH -> RRST HIGH -> RCK LOW then read your data, 2 bytes for each pixel. Remember that you do need to generate the RRST at the start of each frame read.

      Hope it helps!

  3. Yes, that schematic describes my setup. (Your schematic looks much nicer than mine!) I am not sure what you mean when you say the pixel clock should be based on the resolution. Maybe that is my problem. The default for COM4 sets the PLL 4x. The default for CLKRC sets the prescale to 0. The formula in CLKRC is

    internal clk = (input clk x PLL)/ ((prescale+1)x2.

    My input clock is 24MHz, what table 5 of the data sheet says is “typical,” so the internal pixel clock is 48MHz. I have set the resolution to QVGA (in COM7) to limit the number of bytes per frame. I send them out an ethernet jack to an app something like your CTS client, so didn’t want their to be too many bytes. Is this my problem? Is there something wrong with 48MHz pixel clock and QVGA resolution?

    As for your “small change,” I do something similar. I capture two frames and then disable to the interrupt. In this way, I stop writing to the FIFO until I finishing reading. I capture two frames because I want to make sure the write pointer is far enough ahead of the read pointer. The FIFO datasheet seems to warn that the write pointer must be ahead of the read pointer by 128 cycles. I am not sure I understand this, but I thought if I read from 0 to the end of the first of the two frames, I would be okay. Maybe I am confused about this.

    Thanks for your instructions for read reset, but I am not sure I understand them. If you could explain it in more detail, that would be great. I am running the read clock at 1MHz, so that reading is slow enough for my microcontroller to cope. I wait for the RCK to go high. At that point, I pull RRST low. I wait for RCK to go low, high, and low. At that point, I set RRST high. During this operation, RE is set high. RRST is fetched at the rising edge of RCK when RE is low. So now I wait for RCK to go high. At this point, I pull RE low. I wait for RCK to go low, high, low, and high. At that point, I read the first byte. Am I doing this right?

    Thanks again for taking the time to help me out.

    • Hi, I thought you are referring to PCLK, else not sure how does it relate with your problem. So, in this case PCLK is related to resolution as PCLK is the “pixel clock” or Write Clock in your schema.

      Now going back to your other question: all signals are generated by you, not sure what do you mean by “i wait for RCK to go…”. Also, if you look on the AL422B data sheet, you will not really need to control /RE and /OE, you can just keep them always to LOW unless you share the data bus with some other device, which is already explained in data sheet at page 9, “AL422-07 Read Cycle Timing (Read Reset)” diagram. so as long you do follow the timings there you should be safe. Do not forget: your WCK is never stopped as is connected at PCLK…

      For the “128 cycles”: as long you start reading after you start writing you are pretty safe, so if you look at my previous post, you will start reading after capturing a frame, right?

      Not sure if you saw this diagram already, but may help you understand better how things are working:
      ov7670 fifo timing

      If you do not have access to a logic analyser, you may want to try going through your code and put on a linear timeline how the signals are changing through your code, may help you see where the problem is. Btw, I guess you did initialise your OV7670 for QVGA mode, the data format you are looking for and whatever you may need, right?

      • Thanks, that is helpful. I feel like I am understanding more.

        Do you have a recommendation for a logic analyzer? Looks like I could use one. What about a scope? I probably would benefit from that too. I do this stuff for fun. For a living I work in an unrelated field, so I don’t have all the tools for electronics yet.

        The PCLK output from the OV7725 is input to the WCK of the AL422B. In the data sheet for the OV7725, the PCLK is what is called the “internal clock” in CLKRC. Right? My PCLK runs at 48MHz (given 24MHz input and default settings in COM4 and CLKRC. There is no problem with this pixel clock and QVGA mode (in COM7). Right? I do set the other registers needed for QVGA. My color format is RGB555, since that is native to Quartz 2D. My app on the other end runs on OSX.

        I use RE because I send out packets via UDP (with LwIP), so I have to start and stop reading. I reassemble the packets into an image on the other side.

        I worry that I don’t yet understand how you read data from the AL422B. I run the RCK continuously at 1MHz, the minimum, according to the data sheet. Do you stop and start RCK? I thought the data sheet recommended against starting and stop the RCK. Since my RCK is running continuously, I have to wait for it to go high so that I can set RRST and RE according to the timing diagrams. I am relying on AL422-14. For read reset, with RE high, the logic is the following:

        1. Wait for RCK to go high. Pull RRST low.
        2. Wait for RCK to go low, high, and then low.
        3. Pull RRST high.

        Now the read pointer should be at 0. For read enable,

        1. Wait for RCK to go high. Pull RE low.
        2. Wait for RCK to go low.

        Now, when RCK goes high, I should be able to read the first byte. Right? I read a packet of bytes. When I read the last byte in the packet, I pull RE high when RCK is low. Now the read pointer does not advance, even though RCK is still running. I send out the packet via UDP. I then pulse RE and read another packet. Does this make sense?

      • Hi Tom, Checking on my side PCLK for QVGA @ 30 FPS looks like 12 Mhz:
        PCLK QVGA
        PCLK for QQVGA @ 30 FPS looks like 6+ Mhz:
        PCLK QQVGA
        Unless you go VGA @ 60 FPS not sure how you go 48 Mhz.

        Your logic looks fine, using RE this way should work. You may need to check your OV7725 configuration, you have several registries to change for QVGA not only COM7.
        Hope this will help.

      • Hi Tom, forgot to mention: i am using the logic analyser form Ideofy and while not perfect does a great job, especially because of large memory buffer and high sampling rate. Unfortunately works only on Windows and I am using Mac… Another (cheap) option is the “logic sniffer”, not bad but memory is quite low…
        Try to do a research and see which one you can afford and you need. Good luck!

  4. I think I must be very confused about the clocks (input clock and internal clock), different possible resolutions, and FPS. How did you set the camera for QVGA@30FPS? I see no registers for setting FPS. The timing for VGA and QVGA frames is different. I understand that. The timing diagrams in figures 7 and 8 on the data sheet show the differences. It seems to me that the FPS for VGA and QVGA will be a function of the input clock frequency (and the settings in registers COM4 and CLKRC). But why do I need to worry about picking a particular input clock frequency and hence about selecting a particular FPS for a given resolution? I have a feeling this is where my confusion is. Thanks so much for helping me.

    • For setting the FPS you may want to look at CLKRC register in OV7725. For VGA or QVGA, just check the manual, is mentioned there (e.g.: HSTART, HSIZE, VSTRT, VSIZE, etc). However, if you will just capture 1 frame in FIFO then read it, is no need to worry about FPS since you read it from FIFO not from the camera.

      • Thanks for taking the time to reply. I still have something going wrong somewhere, but I will keep working.

  5. You did not specify that you used the same data to display the image even if lighting is the same if anything is set to automatic the sensor can still pick a different setting.

    • Actually I did, if you read the post I did mention same conditions. Further more: using same (artificial) light and displaying EXACTLY same stream of data. Even tried saving the data to a file and process it on UNIX and Windows…

      • Did you try processing it on UNIX and viewing the output on windows. It may be that the version of UNIX that you are using has a different gamma setting or a different color setting.

      • Is possible, i thought the same, however, i am using same machine (macbook pro retina) running mac os as native OS and Windows in a virtual machine when experiencing this. Also, normal pictures don’t have this issue. Mind you that this is raw YUV data stream coming from a camera over serial port…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s