libheif icon indicating copy to clipboard operation
libheif copied to clipboard

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

Open takafumimastushita opened this issue 4 years ago • 7 comments

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);

takafumimastushita avatar Apr 06 '21 11:04 takafumimastushita

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(): https://github.com/strukturag/libheif/blob/dd993f3d5465de5215e24cde36b18f92d7d6d0c6/libheif/heif_colorconversion.cc#L3134

farindk avatar Apr 19 '21 10:04 farindk

@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.

takafumimastushita avatar Apr 22 '21 01:04 takafumimastushita

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.

farindk avatar Apr 28 '21 22:04 farindk

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.

takafumimastushita avatar May 06 '21 02:05 takafumimastushita

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?

silverbacknet avatar May 08 '21 11:05 silverbacknet

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

takafumimastushita avatar Aug 18 '21 01:08 takafumimastushita

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.

vaifrax avatar Jul 11 '22 21:07 vaifrax