1

I have a JPEG image (say of size 10*10) and i want to perform a color conversion of some part of this JPEG image.

For example I want to perform color conversion for the image width starting from column "1 to 10".

In this case after conversion the color is not the same as in original image rather it is destorted.

Though by default the .c implementation of color conversion of jpeg image is done per pixel wise so there is no issue in performing color conversion from 1-10 (instead of 0-10),

But when I take the assembly implementation of color conversion (it performs on 8 pixel at a time) and perform the same task the image get distorted... (maxm part of image looks green)

Assembly code of color conversion is as below:

add             Y,  Y, START_X
add             U,  U, START_X
add             V,  V, START_X

only the above code is my addition

asm_function jsimd_ycc_\colorid\()_convert_neon
/* Outer loop over scanlines */
cmp             NUM_ROWS, #1
blt             9f

0:
ldr             Y, [INPUT_BUF0, INPUT_ROW, lsl #2]
ldr             U, [INPUT_BUF1, INPUT_ROW, lsl #2]

mov             N, OUTPUT_WIDTH
ldr             V, [INPUT_BUF2, INPUT_ROW, lsl #2]

add             Y,  Y, START_X
add             U,  U, START_X
add             V,  V, START_X

add             INPUT_ROW, INPUT_ROW, #1
ldr             RGB, [OUTPUT_BUF], #4

/* Inner loop over pixels */
subs            N, N, #8

blt             3f
do_load         8
do_yuv_to_rgb_stage1
subs            N, N, #8
blt             2f
1:
do_yuv_to_rgb_stage2_store_load_stage1
subs            N, N, #8
bge             1b
2:
do_yuv_to_rgb_stage2
do_store        \bpp, 8
tst             N, #7
beq             8f
3:
tst             N, #4
beq             3f
do_load         4
3:
tst             N, #2
beq             4f
do_load         2
4:
tst             N, #1
beq                5f
do_load         1
.endfunc
Ross Ridge
  • 38,414
  • 7
  • 81
  • 112
user3483701
  • 11
  • 2
  • 3
    It sounds like your assembly implementation is buggy. As could be expected from assembly-implementations for high-level tasks. You should avoid writing assembler yourself. It's 2014, and compilers are pretty good at producing highly optimized code. Without seeing the code, there is no way to answer your question. – mic_e Apr 01 '14 at 05:34
  • 1
    Actually i am using libjpeg-turbo and there are assembly version of color conversion written over there (also the .c implementation is there but for better performance i am using assembly implementation). In assembly implementation i moved the index of input buffer from 0 to 1 so that it could perform color conversion from index 1 to 10 instead of 0 to 10....the sample code i am adding above... – user3483701 Apr 01 '14 at 08:20
  • YUV format might not be using the same number of bits for each component. You would typically need to halve the U and V offsets that you add, and depending on the code possibly also make sure you start with an even numbered column and process an even number of them. – Jester Apr 01 '14 at 10:48
  • so all you added is the `add` on Y, U and V? Why do you need to transform Y? – Theolodis Apr 02 '14 at 12:54
  • @Theolodis in original code for each loop it is processing data from Y, U, V. so, i thought if i want to process data from 2nd pixel to 10th pilex i need to add in Y, U, V all. so is my approach ok ?? – user3483701 Apr 03 '14 at 04:28
  • Sorry not able to attach output image...original image is a red color jpeg image of size 10x10. i am doing color conversion of pixel from 2nd to 10th leaving one pixel. so i have added 1 to Y U V so that when YUV to RGB conversion take place it should take YUV value from 1st 2nd pixel to convert into RGB. Though it skips one pixel for color conversion but the rest part of image is green. – user3483701 Apr 03 '14 at 04:42
  • @Jester yes YUV uses 4bits(in general) for each component of pixel while RGB uses 8bits(in general) for each component. So you mean to say that if i want to move YUV to 4th pixel i need to add 2 in YUV ?? Also is there any reason to start with an even numbered column and process and even number of them ?? – user3483701 Apr 03 '14 at 05:37
  • Generally, Y is 8 bit per pixel, but U and V are 8 bit per a 2x2 pixel block. – Jester Apr 03 '14 at 10:01
  • @Jester you mean to say if i have to skip 1 pixel then i should the following : add Y, Y, #2 add U, U, #1 add V, V, #1 but it didnot work.... – user3483701 Apr 03 '14 at 11:15
  • No you can't easily skip 1 pixel. If you want to skip 2 pixels, you should add 2 to Y, 1 to U and V. To skip `START_X` pixels, if it is even, add `START_X` to Y, and half of it to U and V. – Jester Apr 03 '14 at 11:50
  • @Jester yes i did the same...but no success...i am processing even number of pixels and doing the same what you told...Also i followed the follwing link to understand YUV data format.http://software.intel.com/sites/products/documentation/hpc/ipp/ippi/ippi_ch6/ch6_pixel_and_planar_image_formats.html#fig6-15. Also your approached is the "figure b". How to know if libjpeg-turbo follow the "figure b" approach... – user3483701 Apr 08 '14 at 05:59
  • @Jester Also i went through following link-> http://www.ptgrey.com/support/kb/index.asp?a=4&q=313. What i got to know is when i follow 4:2:2 data approach and if i add equal number in Y U and V (ex Y=Y+2, U=U+2, V=V+2), i should get even number pixels skip as result...but still destorted image with green color i get... – user3483701 Apr 08 '14 at 06:06

0 Answers0