Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(libjpeg_turbo): add JPEG image EXIF data parsing #5263

Merged
merged 1 commit into from
Mar 10, 2024

Conversation

liujp-arch
Copy link
Contributor

Parse the rotation information of a JPEG image

Help us review this PR! Anyone can approve it or request changes.

Description of the feature or fix

A clear and concise description of what the bug or new feature is.

Checkpoints

src/draw/lv_image_buf.h Outdated Show resolved Hide resolved
src/draw/lv_image_buf.h Outdated Show resolved Hide resolved
src/widgets/image/lv_image.c Outdated Show resolved Hide resolved
Copy link
Collaborator

@PGNetHun PGNetHun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not store the rotation EXIF data in LVGL image object, instead the decoder should decode the image in the correct angle.

@kisvegabor
Copy link
Member

Please do not store the rotation EXIF data in LVGL image object, instead the decoder should decode the image in the correct angle.

I agree.

@XuNeo
Copy link
Collaborator

XuNeo commented Jan 11, 2024

Interesting.
What API should we use for decoder to rotate an image(lv_draw_buf_t * decoded)?

@PGNetHun
Copy link
Collaborator

PGNetHun commented Jan 11, 2024

Interesting. What API should we use for decoder to rotate an image(lv_draw_buf_t * decoded)?

Well, I think we should not use LVGL to rotate an image (if it's stored for example in portrait mode / 90 degree rotation), instead the image should be decoded in the correct angle/rotation based on the rotation info in source image meta/EXIF data.
So, the decoder is responsible to decode in the correct angle.

@liujp-arch liujp-arch force-pushed the liujp_img branch 6 times, most recently from e44bad4 to d14fbff Compare January 12, 2024 13:33
Copy link
Collaborator

@PGNetHun PGNetHun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To test the code changes, could you please add a small test JPEG file (and the reference PNG file to compare)?
The JPEG file should have that specific EXIF data for which you have created this PR.

tests/ref_imgs/libs/freetype_1.lp64.png Outdated Show resolved Hide resolved
tests/ref_imgs/libs/jpg_2.png Outdated Show resolved Hide resolved
@liujp-arch liujp-arch force-pushed the liujp_img branch 4 times, most recently from f8fac45 to 9fa845a Compare January 14, 2024 08:41
@kisvegabor kisvegabor requested review from PGNetHun and FASTSHIFT and removed request for PGNetHun January 14, 2024 09:52
tests/ref_imgs/libs/jpg_2.png Outdated Show resolved Hide resolved
src/libs/libjpeg_turbo/lv_libjpeg_turbo.c Show resolved Hide resolved
src/libs/libjpeg_turbo/lv_libjpeg_turbo.c Outdated Show resolved Hide resolved
tests/src/test_assets/test_img_lvgl_logo_with_exif.jpg Outdated Show resolved Hide resolved
@@ -369,8 +393,10 @@ static lv_draw_buf_t * decode_jpeg_file(const char * filename)
jpeg_read_scanlines(&cinfo, buffer, 1);

/* Assume put_scanline_someplace wants a pointer and sample count. */
lv_memcpy(cur_pos, buffer[0], stride);
cur_pos += decoded->header.stride;
dispose_buffer(cur_pos, buffer[0], line_index, cinfo.output_width, cinfo.output_height, decoded->header.stride,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please rename function to rotate_buffer()?

Dispose means to me releasing a resource, cleaning up, for example in .NET we use for that purpose.
But there is also a dispose pattern for releasing resources, so dispose is not the best name for rotating image parts.

@@ -37,16 +38,27 @@ static lv_result_t decoder_open(lv_image_decoder_t * decoder, lv_image_decoder_d
const lv_image_decoder_args_t * args);
static void decoder_close(lv_image_decoder_t * decoder, lv_image_decoder_dsc_t * dsc);
static lv_draw_buf_t * decode_jpeg_file(const char * filename);
static bool get_jpeg_size(const char * filename, uint32_t * width, uint32_t * height);
static uint8_t * alloc_file(const char * filename, uint32_t * size);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because you are already editing this file, could you please rename alloc_file() to read_file() ?
This name describes better what the function does: reads the file content into memory.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the feedback, I'll update them later.

@liujp-arch liujp-arch force-pushed the liujp_img branch 4 times, most recently from 1173a4a to 2b86afd Compare January 18, 2024 06:24
Copy link
Collaborator

@PGNetHun PGNetHun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only 2 CI builds fail on this libjpeg changes.

Copy link
Collaborator

@PGNetHun PGNetHun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix CI build errors -> libjpeg test fails.
It seems there is a memory leak somehow.

@liujp-arch
Copy link
Contributor Author

looks like need more memory actually.

@kisvegabor
Copy link
Member

kisvegabor commented Jan 18, 2024

I've checked the test image, found 2 non rotated images, and thought something is not working. And them saw this comment.

I think showing the 180° rotated image as normal is less intuitive.

@XuNeo
Copy link
Collaborator

XuNeo commented Jan 18, 2024

If I understand correctly, this PR introduces capability to rotate JPEG image as instructed.
So the better test case would be a 180 rotated logo . Seeing the image is rotated means it works.

@PGNetHun
Copy link
Collaborator

PGNetHun commented Jan 18, 2024

If I understand correctly, this PR introduces capability to rotate JPEG image as instructed. So the better test case would be a 180 rotated logo . Seeing the image is rotated means it works.

I assume the intention was to show a rotated image correct:
for example a portrait image, which is stored 90 degree rotated in JPEG.

In this PR maybe a label could be added below the 2 images (that show correct, without upside-down):

  • Not rotated
  • 180 degree rotated

PS:
just to test it, maybe a 90 degree rotated test image could be shown, too.... for bonus points :)

@kisvegabor
Copy link
Member

Ah,it seems I'm really misunderstanding something. Let's say I take a portrait picture with my camera. I guess the EXIF rotation will be 90°. But if we ignore the EXIF data, what image will be shown? A portrait or a landscape?

@liujp-arch
Copy link
Contributor Author

liujp-arch commented Jan 19, 2024

it‘s actually like this,
20240119-105105
when we take a picture with camera(i mean really camera), we may not always hold the camera in such a position that the camera top corresponds to top of the scene, if we hold the camera with orientation flag '6' in above image, the Exif rotation will be 90°. it's equivalent to take a portrait picture with a phone camera. if we ignore the EXIF data, the encoded jpeg will be landscape.

@kisvegabor
Copy link
Member

All clear, thank you!

If by processing the EXIF data we get exactly the same output as with a normal image, I suggest using this the original reference image for all 4 EXIF options.

@lvgl-bot
Copy link

lvgl-bot commented Feb 3, 2024

We need some feedback on this pull request.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

@lvgl-bot lvgl-bot added the stale label Feb 3, 2024
@terry0012
Copy link
Contributor

@liujp-arch @kisvegabor
Are there any other points of concern regarding this feature? Can we merge it?

My personal suggestion is to build a set of basic function APIs for image processing in future, such as rotation and scaling, similar to the draw API. This will unify their usage in image decoding and other parts, and also make it easier to accelerate them using SIMD in the future.

@FASTSHIFT FASTSHIFT removed the stale label Feb 4, 2024
@PGNetHun
Copy link
Collaborator

PGNetHun commented Feb 4, 2024

The actual code is OK (for me), there was only 1 suggestion:
have different input JPEG files with different rotations, but only 1 reference image.
See: #5263 (comment)

But I think we can do it also later, after merging this PR.

@terry0012
Copy link
Contributor

All clear, thank you!

If by processing the EXIF data we get exactly the same output as with a normal image, I suggest using this the original reference image for all 4 EXIF options.

image

@kisvegabor you mean all the 4 EXIF options images should be decoded to the left image in the last line ?

@kisvegabor
Copy link
Member

@kisvegabor you mean all the 4 EXIF options images should be decoded to the left image in the last line ?

Yes, we can have only a single reference image like this:
image

and all 4 variants can be compared to that.

@lvgl-bot
Copy link

We need some feedback on this pull request.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

@lvgl-bot lvgl-bot added the stale label Feb 25, 2024
@kisvegabor
Copy link
Member

I think it's a useful feature and only a little is missing. Did not give up now! 🙂

@FASTSHIFT FASTSHIFT removed the stale label Feb 26, 2024
@liujp-arch
Copy link
Contributor Author

I need to do more testing on the rotation of the image. I will update once it's finished.

Parse the rotation information of a JPEG image
tests/ref_imgs/libs/jpg_2.png Show resolved Hide resolved
@FASTSHIFT FASTSHIFT changed the title feat: Add JPEG image EXIF data parsing feat(libjpeg_turbo): add JPEG image EXIF data parsing Mar 10, 2024
@FASTSHIFT FASTSHIFT merged commit 30793d7 into lvgl:master Mar 10, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants