fix png links

Author: Echo-Nie

docs/design/concepts/python_data_feeding.md

@@ -2,7 +2,7 @@
 
 In the former implementation of Paddle Fluid, there are two ways to feed data:
 
-- Use `reader_op` in backend C++ side. This method only supports data feeding from recordio files and random data generators, but supports many kinds of `decorated_readers`. For examples, `double_buffer_reader` uses two threads to achieve better performance: one for time-consuming I/O operations, and the other for `Executor::Run()`. See [C++ Data Feeding](https://github.com/PaddlePaddle/docs/blob/TensorFlow-Paddle-docs/docs/design/concepts/cpp_data_feeding.md) for details.
+- Use `reader_op` in backend C++ side. This method only supports data feeding from recordio files and random data generators, but supports many kinds of `decorated_readers`. For examples, `double_buffer_reader` uses two threads to achieve better performance: one for time-consuming I/O operations, and the other for `Executor::Run()`. See [C++ Data Feeding](https://github.com/PaddlePaddle/docs/blob/develop/docs/design/concepts/cpp_data_feeding.md) for details.
 
 - Feed data directly using `DataFeeder.feed()` in Python codes. It is more flexible than the first way. Many kinds of preprocessing steps can be performed before feeding using Python or any other languages, instead of adding many uncommon `operators` in C++ side. But this method is less efficient: the program cannot read the next mini-batch data before `Executor::Run()` ends. Moreover, `decorated_readers` such as `double_buffer_reader` cannot be used for better performance.
 

docs/design/concurrent/channel.md

@@ -103,9 +103,9 @@ current thread under two conditions:
   2. The channel is unbuffered and does not have a receiver
 
 - **recvq**:  This queue holds the QueueMessage of any pending receivers of a
-channel.  When a thread performs a channel_recv operation on the channel, the
-channel_recv operation will put a new QueueMessage on the recvq and block the
-current thread under two conditions:
+  channel.  When a thread performs a channel_recv operation on the channel, the
+  channel_recv operation will put a new QueueMessage on the recvq and block the
+  current thread under two conditions:
   1. The channel is buffered and there is no data on the buff_
   2. The channel is unbuffered and does not have a sender
 
@@ -114,15 +114,17 @@ current thread under two conditions:
 #### Channel Send
 
 <p align="center">
-<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/blob/develop/docs/design/concurrent/images/channel_send.png"/><br/>
+<img src="https://github.com/PaddlePaddle/docs/blob/develop/docs/design/concurrent/images/channel_recv.png?raw=true"/><br/>
 </p>
 
+
 #### Channel Receive
 
 <p align="center">
-<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/blob/develop/docs/design/concurrent/images/channel_recv.png"/><br/>
+<img src="https://github.com/PaddlePaddle/docs/blob/develop/docs/design/concurrent/images/channel_send.png?raw=true"/><br/>
 </p>
 
+
 ## Limitations and Considerations
 
 ### Variable Copy

docs/design/concurrent/select_op.md

@@ -254,9 +254,10 @@ only one case will be executed.
 ### select_op flow
 
 <p align="center">
-<img src="https://raw.githubusercontent.com/PaddlePaddle/docs/blob/develop/docs/design/concurrent/images/select_op_workflow.png"/><br/>
+<img src="https://github.com/PaddlePaddle/docs/blob/develop/docs/design/concurrent/images/select_op_workflow.png?raw=true"/><br/>
 </p>
 
+
 The select algorithm is inspired by golang's select routine.  Please refer to
 http://www.tapirgames.com/blog/golang-concurrent-select-implementation for more information.