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

Heif decoding processing speed is degraded in V1.7.0 or later version. #472

Open
takafumimastushita opened this issue Apr 6, 2021 · 7 comments

Comments

@takafumimastushita
Copy link

I'm currently using the v1.6.2 version, but upgrading to v1.10.0 slowed down the heif decoding process by about 2.8 times.
I think the cause is that the internal processing was changed from YCbCr processing to RGB processing in the correction of v1.7.0.
I would like to use the latest version.
Is it possible to improve the processing speed to the same level as v1.6.2.

  • The measurement conditions are as follows.
    Images: 8 million pixels to 24 million pixels (100 images)
    Processing time: 742msec(v1.6.2) -> 2080msec(v1.10.0)  (Average of 100 images. Only the call part of heif_decode_image() )
    Environment: Windows10 Enterprise 64bit, CPU Intel (R) Core ™ i7-4790 3.6GHz, RAM 32GB

  • Implementation of the calling part of the decoding process(Exclude error handling)

	ctx = heif_context_alloc();
	struct heif_error err;

	// read file
	err = heif_context_read_from_file(ctx, inputHeifFilePathChar, nullptr);

	// get number of image
	int num_images = heif_context_get_number_of_top_level_images(ctx);

	// get image ids
	std::vector<heif_item_id> image_IDs(num_images);
	int ret_num = heif_context_get_list_of_top_level_image_IDs(ctx, &image_IDs[0], num_images);

	// decode
	// convert only the 0th image
	int idx = 0;
	err = heif_context_get_image_handle(ctx, &image_IDs[0], &handle);

	int has_alpha = heif_image_handle_has_alpha_channel(handle);

	decode_options = heif_decoding_options_alloc();
	encoder->UpdateDecodingOptions(handle, decode_options);

	err = heif_decode_image(
		handle,
		&image,
		encoder->colorspace(has_alpha),
		encoder->chroma(has_alpha),
		decode_options);

	// encode
	bool written = encoder->Encode(handle, image, outputJpegFilePathChar);
@farindk
Copy link
Contributor

farindk commented Apr 19, 2021

Could you please time the color conversion part, so that we can see whether it is really the color conversion that is slowing this down?
You find the color conversion in heif_colorconversion.cc in function heif::convert_colorspace():

return pipeline.convert_image(input);

@takafumimastushita
Copy link
Author

@farindk
The processing time of heif :: convert_colorspace(), HeifContext :: decode_image(), HeifContext :: decode_image_planar() was measured. Heif :: convert_colorspace () is not executed in v1.6.2, but it is executed in v1.10.0.
*Since the calling method and input conditions of heif_decode_image() have not changed at all, the decoding processing time will be different.

Version decode_image(decode_image_planar) convert_colorspace
v1.6.2 0.39 sec 0.0 sec
v1.10.0 1.30 sec 0.40 sec

*The measurement image is the same set of 100 images as last time.
Please confirm.

@farindk
Copy link
Contributor

farindk commented Apr 28, 2021

I'll have to think about this a bit more.

Our color-conversions are not optimized. Either we speed up the color conversions or we find a way to avoid them. It might be possible to pass-thru images that do not need RGB processing (MIAF compatible images), but then, it would be the burden of the user to handle the color profiles.

@takafumimastushita
Copy link
Author

Our color-conversions are not optimized. Either we speed up the color conversions or we find a way to avoid them.

Please consider speeding up color conversion.
When can you fix it?

It might be possible to pass-thru images that do not need RGB processing (MIAF compatible images), but then, it would be the burden of the user to handle the color profiles.

Please tell me specifically what the user has to do with the color profiles process.

@silverbacknet
Copy link

A separate function for raw access to any low-level single image and a bit of metadata about it might be the way to go, with no transformations or even alpha-blending. The more I use the library, the more I'm grateful for how it transparently deals with so many of the incredibly nitpicky things that most apps get wrong or aren't prepared for, and I don't know if there's a good balance between raw access and end-to-end conversion.

Since it's LGPL, would adding already-optimized conversions from ffmpeg be acceptable?

@takafumimastushita
Copy link
Author

@farindk
Please tell us about the status of consideration for speeding up the decoding process.

@vaifrax
Copy link

vaifrax commented Jul 11, 2022

I'm also wondering if decoding and/or color conversion speed can be improved. As I have 4k input images but only need a 1k resolution afterwards, it would be great if there was a way to open at half or quarter resolution and potentially speeding up decoding and color conversion significantly.

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

No branches or pull requests

4 participants