CN111447219B - 图像显示方法及装置、存储介质、计算机设备 - Google Patents

图像显示方法及装置、存储介质、计算机设备 Download PDF

Info

Publication number
CN111447219B
CN111447219B CN202010222032.1A CN202010222032A CN111447219B CN 111447219 B CN111447219 B CN 111447219B CN 202010222032 A CN202010222032 A CN 202010222032A CN 111447219 B CN111447219 B CN 111447219B
Authority
CN
China
Prior art keywords
image
image file
format
thread
compression
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010222032.1A
Other languages
English (en)
Other versions
CN111447219A (zh
Inventor
丁有剑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Ping An Medical Health Technology Service Co Ltd
Original Assignee
Shenzhen Ping An Medical Health Technology Service Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Ping An Medical Health Technology Service Co Ltd filed Critical Shenzhen Ping An Medical Health Technology Service Co Ltd
Priority to CN202010222032.1A priority Critical patent/CN111447219B/zh
Publication of CN111447219A publication Critical patent/CN111447219A/zh
Application granted granted Critical
Publication of CN111447219B publication Critical patent/CN111447219B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/11File system administration, e.g. details of archiving or snapshots
    • G06F16/116Details of conversion of file system types or formats
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/957Browsing optimisation, e.g. caching or content distillation
    • G06F16/9577Optimising the visualization of content, e.g. distillation of HTML documents
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/565Conversion or adaptation of application format or content
    • H04L67/5651Reducing the amount or size of exchanged application data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC

Abstract

本申请公开了图像显示方法及装置、存储介质、计算机设备,涉及图像处理技术领域。其中方法包括:根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程;通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程;根据接收到的压缩图像文件生成base64格式的图像文件;根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件,本申请适用于提升图像显示的流畅性。

Description

图像显示方法及装置、存储介质、计算机设备
技术领域
本申请涉及图像处理技术领域,尤其是涉及到图像显示方法及装置、存储介质及计算机设备。
背景技术
随着互联网技术及移动通信技术的发展,在客户端侧各种各样的应用程序中,为了客户端显示图像文件通常需要先上传图像文件,以及对图像文件进行压缩。目前,现有的图像文件压缩方法是对上传的每一份图像文件进行参数获取,然后以参数list文件的形式进行转换,创建媒体标签,以便等待加载。
当用户通过客户端访问、获取图像文件时,客户端根据用户的图像浏览指令加载当前页面上的所有图像文件并对其进行显示。但是,现有技术存在的不足为,当图像文件数量较大时,例如,十几兆或者二十几兆,图像文件的压缩速度会降低且占用时间较长,导致在图像文件浏览的过程中,浏览页面卡顿,用户体验较差。
发明内容
有鉴于此,本申请提供了图像显示方法及装置、存储介质、计算机设备,主要目的在于解决现有图像文件压缩方法中图像文件数量较大导致图像文件的压缩速度降低且占用时间较长,以及在图像文件浏览的过程中,浏览页面卡顿,用户体验较差的技术问题。
根据本申请的一个方面,提供了一种图像显示方法,该方法包括:
根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程;
通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程;
根据接收到的压缩图像文件生成base64格式的图像文件;
根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件。
根据本申请的另一方面,提供了一种图像显示装置,该装置包括:
发送模块,用于根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程;
压缩模块,用于通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程;
格式转换模块,用于根据接收到的压缩图像文件生成base64格式的图像文件;
显示模块,用于根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件。
依据本申请又一个方面,提供了一种存储介质,其上存储有计算机程序,所述程序被处理器执行时实现上述图像显示方法。
依据本申请再一个方面,提供了一种计算机设备,包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上述图像显示方法。
借由上述技术方案,本申请提供的图像显示方法及装置、存储介质、计算机设备,与现有利用主线程实现图像显示的技术方案相比,本申请根据接收到的图像上传请求,将对应图像上传请求的初始图像文件发送给用于压缩图像的子线程,通过子线程并利用离屏canvas压缩初始图像文件,得到压缩图像文件并发送给主线程,以便主线程根据接收到的压缩图像文件生成base64格式的图像文件,并在接收到图像浏览请求后,根据图像浏览请求中的图像文件标识显示与图像文件标识对应的base64格式的图像文件。可见,通过子线程对初始图像文件进行离屏canvas压缩后发送给主线程,由主线程根据接收到的压缩图像文件生成base64格式的图像文件并链接到web前端完成图像显示,能够在上传的图像文件数量较大时,有效提升图像文件的压缩速度且缩短占用时间,保证在图像文件浏览的过程中,浏览页面不卡顿,满足用户的体验需求。
上述说明仅是本申请技术方案的概述,为了能够更清楚了解本申请的技术手段,而可依照说明书的内容予以实施,并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂,以下特举本申请的具体实施方式。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1示出了本申请实施例提供的一种图像显示方法的流程示意图;
图2示出了本申请实施例提供的另一种图像显示方法的流程示意图;
图3示出了本申请实施例提供的一种图像显示装置的结构示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本申请。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
针对现有图像文件压缩方法中图像文件数量较大导致图像文件的压缩速度降低且占用时间较长,以及在图像文件浏览的过程中,浏览页面卡顿,用户体验较差的技术问题。本实施例提供了一种图像显示方法,能够在上传的图像文件数量较大时,有效提升图像文件的压缩速度且缩短占用时间,保证在图像文件浏览的过程中,浏览页面不卡顿,满足用户的体验需求。如图1所示,该方法包括:
步骤101、根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程。
在本实施例中,当监测到图像上传请求时,根据监测到的图像上传请求获取与图像上传请求对应的初始图像文件(例如,cell文件),并利用应用程序接口Windows API中的postmessage函数将包含初始图像文件的压缩请求发送给由webworker创建的用于压缩该初始图像文件的子线程compress.js。
步骤102、通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程。
在本实施例中,当webworker子线程compress.js监测到来自主线程的包含初始图像文件的压缩请求时,根据监测到的压缩请求中的初始图像文件进行图像格式转换处理,得到imageBitmap格式的图像文件后,利用离屏canvas对该imageBitmap格式的图像文件进行图像格式转换和压缩,得到压缩图像文件并发送给主线程。
步骤103、根据接收到的压缩图像文件生成base64格式的图像文件。
步骤104、根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件。
在本实施例中,主线程通过实例化FileReader标签,生成对应压缩图像文件的base64格式的图像文件,当监测到图像浏览请求时,根据监测到的图像浏览请求获取图像浏览请求中携带的图像文件标识,利用图像文件标识与base64格式的图像文件的对应关系,将对应的base64格式的图像文件链接到web前端完成图像显示。
对于本实施例可以按照上述方案,根据接收到的图像上传请求,将对应图像上传请求的初始图像文件发送给用于压缩图像的子线程,通过子线程并利用离屏canvas压缩初始图像文件,得到压缩图像文件并发送给主线程,以便主线程根据接收到的压缩图像文件生成base64格式的图像文件,并在接收到图像浏览请求后,根据图像浏览请求中的图像文件标识显示与图像文件标识对应的base64格式的图像文件。与现有利用主线程实现图像显示的技术方案相比,本实施例通过子线程对初始图像文件进行离屏canvas压缩后发送给主线程,由主线程根据接收到的压缩图像文件生成base64格式的图像文件并链接到web前端完成图像显示,能够在上传的图像文件数量较大时,有效提升图像文件的压缩速度且缩短占用时间,保证在图像文件浏览的过程中,浏览页面不卡顿,满足用户的体验需求。
进一步的,作为上述实施例具体实施方式的细化和扩展,为了完整说明本实施例的具体实施过程,提供了另一种图像显示方法,如图2所示,该方法包括:
步骤201、当接收到图像上传请求时,判断多线程对象是否存在。
在本实施例中,在当接收到图像上传请求时,判断多线程对象是否存在的步骤之前,还包括:监测输入标签input是否有onChange事件更新,表示为,onchange(e){var file=e.files[0];}。具体为,监测输入标签input是否有onChange事件更新,当有onChange事件更新时,获取与onChange事件对应的cell文件(即,图像上传请求)。
步骤202、若多线程对象存在,则根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程。
步骤203、若多线程对象不存在,则根据接收到的图像上传请求中的初始图像文件,利用实例化canvas压缩得到base64格式的图像文件并当接收到图像浏览请求时显示与所述图像浏览请求中的图像文件标识对应的base64格式的图像文件。
在本实施例中,当监测到图像上传请求时,根据监测到的图像上传请求判断多线程对象是否存在,若返回值为1,则多线程对象存在,根据接收到的图像上传请求,将对应图像上传请求的初始图像文件发送给用于压缩图像的子线程;若返回值为0或者空集,则多线程对象不存在,根据接收到的图像上传请求中的初始图像文件,利用实例化canvas直接压缩得到base64格式的图像文件并显示,即传统的图像文件压缩方法,此处不对传统的图像文件压缩方法进行具体描述。
在本实施例中,判断多线程对象是否存在是指:判断与该图像上传请求对应的浏览器是否支持多线程。
步骤204、根据接收到的图像上传请求中的初始图像文件,生成包含所述初始图像文件的压缩请求。
步骤205、利用应用程序接口中的postmessage函数将所述压缩请求发送给由webworker创建的用于压缩所述初始图像文件的子线程。
在本实施例中,当确定web前端存在多线程对象后,创建webworker子线程,表示为,Var worker=new Worker(“compressImage.js”),并根据接收到的图像上传请求中的初始图像文件,生成包含初始图像文件的压缩请求,以便利用postmessage函数将包含图像文件的压缩请求发送给webworker子线程,表示为,worker.postMessage({File:file,//初始图像文件name:file.name,//图像文件名称type:file.type,//图像文件类型quality:0.5//图像压缩质量ratio:0.8//图像压缩比例Size:2000//压缩后需要限制的图像文件大小})。
其中,压缩请求包括初始图像文件和预置图像压缩参数,预置图像压缩参数包括图像文件标识信息(例如,图像文件名称)、图像文件类型信息、图像压缩质量信息、图像压缩比例信息、压缩后需要限制的图像文件大小信息。
步骤206、根据来自主线程的所述压缩请求中的初始图像文件进行图像格式转换,得到imageBitmap格式的图像文件。
在本实施例中,在根据来自主线程的所述压缩请求中的初始图像文件进行图像格式转换,得到imageBitmap格式的图像文件的步骤之前,还包括:创建用于webworker子线程接收包含初始图像文件的压缩请求的接收标签,以便接收来自主线程的包含初始图像文件的压缩请求。其中,用于webworker子线程接收压缩请求的接收标签可以在接收到图像上传请求时进行创建,也可以在创建webworker子线程的同时进行创建,此处不对创建时间进行具体限定。
步骤207、通过实例化离屏canvas对所述imageBitmap格式的图像文件进行图像格式转换和压缩,并将得到的blob格式的多个二进制图像文件作为压缩图像文件发送给主线程。
在本实施例中,webworker子线程监测massage是否接收到来自主线程的包含初始图像文件的压缩请求,当监测到压缩请求时,利用window.createImageBitmap方法,对压缩请求中初始图像文件的图像格式进行格式转换处理,得到imageBitmap格式的图像文件,并实例化离屏canvas(即,创建离屏canvas)。
进一步地,根据canvas.getContext(“2d”)获取imageBitmap格式的图像文件的上下文环境ctx(ctx:Context),完成背景渲染,以便利用ctx.drawImage将imageBitmap格式的图像文件绘制到离屏canvas中,以及利用canvas.convertToBlob方法,将绘制到离屏canvas中的imageBitmap格式的图像文件转换为blob格式的多个二进制图像文件,并按照一定的压缩质量(0-1)得到压缩后的图像文件,以便webworker子线程利用postmessage函数将包含blob格式的多个二进制图像文件的压缩图像文件发送给主线程。其中,压缩质量根据压缩请求中的图像压缩比例信息确定。
具体为,webworker子线程监测massage是否接收到来自主线程的包含初始图像文件的压缩请求,表示为,self.addEventListener("message",function(e){compressImageSize(e.data);//e.data为子线程收到压缩请求},false)。
利用window.createImageBitmap方法将压缩请求中的初始图像文件转换为ImageBitmap格式的图像文件,表示为,function compressImageSize(option){createImageBitmap(option.file).then(e=>{Let imageData=e});}。
在实际的应用场景中,由于webworker子线程环境中无法使用img标签,因此本实施例利用window.createImageBitmap方法,将初始图像文件的图像格式类型转换为可以被渲染到离屏canvas中的imagebitmap图像格式类型,以便在webworker子线程中实现初始图像文件的压缩,该压缩过程也可以在主线程中完成,此处不对图像格式类型转换的操作顺序进行具体限定。
对应地,通过调用离屏canvas,webworker子线程对imageBitmap格式的图像文件进行图像格式转换以及压缩操作,表示为,let h=option.imageData.height;let w=option.imageData.width;let canvas=new OffscreenCanvas(w,h)let ctx=canvas.getContext(“2d”)ctx.drawImage(option.imageData,0,0);canvas.convertToBlob({type:option.type,quality:option.quality}).then(function(blob))}。
为了说明步骤207的具体实施方式,作为一种优选实施例,所述实例化离屏canvas,具体可以包括:
步骤2071、根据所述imageBitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息,计算出离屏canvas的窗口尺寸信息。
步骤2072、根据计算出的离屏canvas的窗口尺寸信息,创建离屏canvas。
在本实施例中,根据imageBitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息计算出压缩后的图像尺寸信息(例如,图像宽高),根据计算出的图像尺寸信息(例如,图像宽高)确定待创建的离屏canvas的窗口宽高,从而创建指定窗口宽高的离屏canvas。其中,imageBitmap格式的图像文件的预置图像压缩参数为压缩请求中的预置图像压缩参数。
为了说明步骤207的具体实施方式,作为一种优选实施例,所述将得到的blob格式的多个二进制图像文件作为压缩图像文件发送给主线程,具体还可以包括:
步骤2073、判断得到的blob格式的多个二进制图像文件的图像压缩参数是否在预置图像压缩参数范围内。
步骤2074、若得到的blob格式的多个二进制图像文件的图像压缩参数超出预置图像压缩参数范围,则根据image Bitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息再次压缩所述blob格式的多个二进制图像文件。
步骤2075、若得到的blob格式的多个二进制图像文件的图像压缩参数在预置图像压缩参数范围内,则将得到的blob格式的多个二进制图像文件发送给主线程。
在本实施例中,对得到的blob格式的多个二进制图像文件进行图像压缩参数判断,判断blob格式的多个二进制图像文件是否符合预置图像压缩参数的要求,若不符合,则重新根据imageBitmap格式的图像文件的预置压缩参数中的图像压缩比例信息再次压缩该blob格式的多个二进制图像文件,直至压缩后的blob格式的多个二进制图像文件符合预置图像压缩参数的要求。
在实际的应用场景中,由于现有webworker子线程中的离屏canvas不支持主线程中的toDataURL方法,因此本实施例在利用convertToBlob方法获取imageBitmap格式的图像文件的预置图像压缩参数前,需要先获取imageBitmap格式的图像文件对应的blob格式的二进制对象;以及,由于blob格式的二进制图像文件在子线程与主线程之间的数据传输速度比字符串的数据传输速度快,因此在子线程中将imageBitmap格式的图像文件图像格式转换并压缩为blob格式的多个二进制图像文件。
对应地,对得到的blob格式的多个二进制图像文件进行图像压缩参数判断,判断blob格式的多个二进制图像文件是否符合预置图像压缩参数的要求,表示为,If(blob.size>option.size){compressImageSize({File:blob,//初始图像文件name:option.name,//图像文件名称type:option.type,//图像文件类型quality:option.quality//图像压缩质量ratio:option.ratio//图像压缩比例Size:option.size//压缩后需要限制的图像文件大小})}else{postMessage(blob)}。
步骤208、利用实例化FileReader标签对接收到的blob格式的多个二进制图像文件进行图像格式转换,得到base64格式的图像文件。
步骤209、根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件。
在本实施例中,当主线程监测到worker.onmessage事件更新后,根据监测到的来自webworker子线程的压缩图像文件,获取压缩图像文件中的blob格式的多个二进制图像文件;实例化FileReader标签(即,创建FileReader标签),并利用Reader.readAsDataURL对blob格式的多个二进制图像文件进行图像格式转换,得到base64格式的图像文件,以便在接收到对应该base64格式的图像文件的图像浏览请求时,直接解析得到该base64格式的图像文件,并将其链接到HTML页面上,实现当前页面的图像浏览。
其中,利用Reader.readAsDataURL对blob格式的多个二进制图像文件进行图像格式转换,得到base64格式的图像文件,表示为,worker.onmessage=(blob)=>{Let reader=new FileReader()Reader.readAsDataURL(blob)Reader.onload=base64=>base64}。
在实际的应用场景中,由于blob格式的多个二进制图像文件在子线程与主线程之间的数据传输速度比字符串的数据传输速度快,因此在主线程监测到来自子线程的压缩图像文件后,创建FileReader标签。
通过应用本实施例的技术方案,根据接收到的图像上传请求,将对应图像上传请求的初始图像文件发送给用于压缩图像的子线程,通过子线程并利用离屏canvas压缩初始图像文件,得到压缩图像文件并发送给主线程,以便主线程根据接收到的压缩图像文件生成base64格式的图像文件,并在接收到图像浏览请求后,根据图像浏览请求中的图像文件标识显示与图像文件标识对应的base64格式的图像文件。与现有利用主线程实现图像显示的技术方案相比,本实施例通过子线程对初始图像文件进行离屏canvas压缩后发送给主线程,由主线程根据接收到的压缩图像文件生成base64格式的图像文件并链接到web前端完成图像显示,能够在上传的图像文件数量较大时,有效提升图像文件的压缩速度且缩短占用时间,保证在图像文件浏览的过程中,浏览页面不卡顿,满足用户的体验需求。
进一步的,作为图1方法的具体实现,本申请实施例提供了一种图像显示装置,如图3所示,该装置包括:发送模块32、压缩模块33、格式转换模块34、显示模块35。
发送模块32,可以用于根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程。
压缩模块33,可以用于通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程。
格式转换模块34,用于根据接收到的压缩图像文件生成base64格式的图像文件。
显示模块35,可以用于根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件。
在具体的应用场景中,还包括判断模块31。
判断模块31,可以用于当接收到图像上传请求时,判断多线程对象是否存在;若多线程对象存在,则根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程;以及,若多线程对象不存在,则根据接收到的图像上传请求中的初始图像文件,利用实例化canvas压缩得到base64格式的图像文件并显示。
在具体的应用场景中,发送模块32,具体包括:根据接收到的图像上传请求中的初始图像文件,生成包含所述初始图像文件的压缩请求;以及,利用应用程序接口中的postmessage函数将所述压缩请求发送给由webworker创建的用于压缩所述初始图像文件的子线程。
在具体的应用场景中,压缩模块33,具体包括:根据来自主线程的所述压缩请求中的初始图像文件进行图像格式转换,得到image Bitmap格式的图像文件;以及,通过实例化离屏canvas对所述image Bitmap格式的图像文件进行图像格式转换和压缩,并将得到的blob格式的多个二进制图像文件作为压缩图像文件发送给主线程。
在具体的应用场景中,所述实例化离屏canvas,具体包括:根据所述image Bitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息,计算出离屏canvas的窗口尺寸信息;以及,根据计算出的离屏canvas的窗口尺寸信息,创建离屏canvas。
在具体的应用场景中,所述将得到的blob格式的多个二进制图像文件作为压缩图像文件发送给主线程,还包括:判断得到的blob格式的多个二进制图像文件的图像压缩参数是否在预置图像压缩参数范围内;若得到的blob格式的多个二进制图像文件的图像压缩参数超出预置图像压缩参数范围,则根据imageBitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息再次压缩所述blob格式的多个二进制图像文件;若得到的blob格式的多个二进制图像文件的图像压缩参数在预置图像压缩参数范围内,则将得到的blob格式的多个二进制图像文件发送给主线程。
在具体的应用场景中,格式转换模块34,具体包括:利用实例化File Reader标签对接收到的blob格式的多个二进制图像文件进行图像格式转换,得到base64格式的图像文件。
需要说明的是,本申请实施例提供的一种图像显示装置所涉及各功能单元的其他相应描述,可以参考图1和图2中的对应描述,在此不再赘述。
基于上述如图1和图2所示方法,相应的,本申请实施例还提供了一种存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述如图1和图2所示的图像显示方法。
基于这样的理解,本申请的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施场景所述的方法。
基于上述如图1、图2所示的方法,以及图3所示的虚拟装置实施例,为了实现上述目的,本申请实施例还提供了一种计算机设备,具体可以为个人计算机、服务器、网络设备等,该实体设备包括存储介质和处理器;存储介质,用于存储计算机程序;处理器,用于执行计算机程序以实现上述如图1和图2所示的图像显示方法。
可选的,该计算机设备还可以包括用户接口、网络接口、摄像头、射频(RadioFrequency,RF)电路,传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等,可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如蓝牙接口、WI-FI接口)等。
本领域技术人员可以理解,本实施例提供的一种计算机设备结构并不构成对该实体设备的限定,可以包括更多或更少的部件,或者组合某些部件,或者不同的部件布置。
存储介质中还可以包括操作系统、网络通信模块。操作系统是管理计算机设备硬件和软件资源的程序,支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信,以及与该实体设备中其它硬件和软件之间通信。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现,也可以通过硬件实现。通过应用本申请的技术方案,与现有利用主线程实现图像显示的技术方案相比,本实施例通过子线程对初始图像文件进行离屏canvas压缩后发送给主线程,由主线程根据接收到的压缩图像文件生成base64格式的图像文件并链接到web前端完成图像显示,能够在上传的图像文件数量较大时,有效提升图像文件的压缩速度且缩短占用时间,保证在图像文件浏览的过程中,浏览页面不卡顿,满足用户的体验需求。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本申请序号仅仅为了描述,不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景,但是,本申请并非局限于此,任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (9)

1.一种图像显示方法,其特征在于,包括:
根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程;
通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程;
根据接收到的压缩图像文件生成base64格式的图像文件;
根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件;
所述压缩图像文件为blob格式的多个二进制图像文件,所述得到压缩图像文件并发送给主线程,还包括:
判断得到的blob格式的多个二进制图像文件的图像压缩参数是否在预置图像压缩参数范围内;
若得到的blob格式的多个二进制图像文件的图像压缩参数超出预置图像压缩参数范围,则根据imageBitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息再次压缩所述blob格式的多个二进制图像文件;
若得到的blob格式的多个二进制图像文件的图像压缩参数在预置图像压缩参数范围内,则将得到的blob格式的多个二进制图像文件发送给主线程。
2.根据权利要求1所述的方法,其特征在于,所述根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程之前,还包括:
当接收到图像上传请求时,判断多线程对象是否存在;
若多线程对象存在,则根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程;
若多线程对象不存在,则根据接收到的图像上传请求中的初始图像文件,利用实例化canvas压缩得到base64格式的图像文件并当接收到图像浏览请求时显示与所述图像浏览请求中的图像文件标识对应的base64格式的图像文件。
3.根据权利要求1或2所述的方法,其特征在于,所述根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程,具体包括:
根据接收到的图像上传请求中的初始图像文件,生成包含所述初始图像文件的压缩请求;
利用应用程序接口中的postmessage函数将所述压缩请求发送给由webworker创建的用于压缩所述初始图像文件的子线程。
4.根据权利要求1所述的方法,其特征在于,所述通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程,具体包括:
根据来自主线程的所述压缩请求中的初始图像文件进行图像格式转换,得到imageBitmap格式的图像文件;
通过实例化离屏canvas对所述imageBitmap格式的图像文件进行图像格式转换和压缩,并将得到的blob格式的多个二进制图像文件作为压缩图像文件发送给主线程。
5.根据权利要求4所述的方法,其特征在于,所述实例化离屏canvas,具体包括:
根据所述imageBitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息,计算出离屏canvas的窗口尺寸信息;
根据计算出的离屏canvas的窗口尺寸信息,创建离屏canvas。
6.根据权利要求4所述的方法,其特征在于,所述根据接收到的压缩图像文件生成base64格式的图像文件,具体包括:
利用实例化FileReader标签对接收到的blob格式的多个二进制图像文件进行图像格式转换,得到base64格式的图像文件。
7.一种图像显示装置,其特征在于,包括:
发送模块,用于根据接收到的图像上传请求,将对应所述图像上传请求的初始图像文件发送给用于压缩图像的子线程;
压缩模块,用于通过所述子线程并利用离屏canvas压缩所述初始图像文件,得到压缩图像文件并发送给主线程;
格式转换模块,用于根据接收到的压缩图像文件生成base64格式的图像文件;
显示模块,用于根据接收到的图像浏览请求中的图像文件标识,显示与所述图像文件标识对应的base64格式的图像文件;
其中,所述压缩图像文件为blob格式的多个二进制图像文件,所述压缩模块,还包括:
判断得到的blob格式的多个二进制图像文件的图像压缩参数是否在预置图像压缩参数范围内;
若得到的blob格式的多个二进制图像文件的图像压缩参数超出预置图像压缩参数范围,则根据imageBitmap格式的图像文件的预置图像压缩参数中的图像压缩比例信息再次压缩所述blob格式的多个二进制图像文件;
若得到的blob格式的多个二进制图像文件的图像压缩参数在预置图像压缩参数范围内,则将得到的blob格式的多个二进制图像文件发送给主线程。
8.一种存储介质,其上存储有计算机程序,其特征在于,所述程序被处理器执行时实现权利要求1至6中任一项所述的图像显示方法。
9.一种计算机设备,包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现权利要求1至6中任一项所述的图像显示方法。
CN202010222032.1A 2020-03-26 2020-03-26 图像显示方法及装置、存储介质、计算机设备 Active CN111447219B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010222032.1A CN111447219B (zh) 2020-03-26 2020-03-26 图像显示方法及装置、存储介质、计算机设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010222032.1A CN111447219B (zh) 2020-03-26 2020-03-26 图像显示方法及装置、存储介质、计算机设备

Publications (2)

Publication Number Publication Date
CN111447219A CN111447219A (zh) 2020-07-24
CN111447219B true CN111447219B (zh) 2023-02-03

Family

ID=71648976

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010222032.1A Active CN111447219B (zh) 2020-03-26 2020-03-26 图像显示方法及装置、存储介质、计算机设备

Country Status (1)

Country Link
CN (1) CN111447219B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115658350A (zh) * 2022-12-13 2023-01-31 北京尽微致广信息技术有限公司 图像调用方法及相关装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327042A (zh) * 2012-03-21 2013-09-25 腾讯科技(深圳)有限公司 一种将批量图片上传到网络相册的方法以及一种客户端
CN105162863A (zh) * 2015-09-01 2015-12-16 北京皮尔布莱尼软件有限公司 一种图片上传装置、方法和计算设备
CN107870816A (zh) * 2016-09-27 2018-04-03 苏宁云商集团股份有限公司 一种用于图像处理和存储的方法及装置
CN109918427A (zh) * 2019-01-16 2019-06-21 平安普惠企业管理有限公司 图片上传控制方法、装置、计算机设备及存储介质
CN110647703A (zh) * 2019-09-18 2020-01-03 平安科技(深圳)有限公司 动画播放方法、装置、计算机设备和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327042A (zh) * 2012-03-21 2013-09-25 腾讯科技(深圳)有限公司 一种将批量图片上传到网络相册的方法以及一种客户端
CN105162863A (zh) * 2015-09-01 2015-12-16 北京皮尔布莱尼软件有限公司 一种图片上传装置、方法和计算设备
CN107870816A (zh) * 2016-09-27 2018-04-03 苏宁云商集团股份有限公司 一种用于图像处理和存储的方法及装置
CN109918427A (zh) * 2019-01-16 2019-06-21 平安普惠企业管理有限公司 图片上传控制方法、装置、计算机设备及存储介质
CN110647703A (zh) * 2019-09-18 2020-01-03 平安科技(深圳)有限公司 动画播放方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN111447219A (zh) 2020-07-24

Similar Documents

Publication Publication Date Title
US8549395B2 (en) Method and system for transforming an integrated webpage
CN109309842B (zh) 直播数据处理方法和装置、计算机设备和存储介质
JP2015529878A (ja) ウェブクライアントを介したリモートアプリケーションへのアクセスの提供
CN109377554B (zh) 大型三维模型绘制方法、设备、系统及存储介质
CN105205174A (zh) 用于分布式系统的文件处理方法和装置
CN113808231B (zh) 信息处理方法及装置、图像渲染方法及装置、电子设备
CN112306793A (zh) 用于监控网页的方法和装置
CN111951356B (zh) 基于json数据格式的动画渲染方法
CN110675465A (zh) 用于生成图像的方法和装置
CN109545333A (zh) Dicom影像显示、处理的方法及装置
CN109168012B (zh) 用于终端设备的信息处理方法和装置
US11481927B2 (en) Method and apparatus for determining text color
CN113190152A (zh) 切换应用程序主题的方法和装置
CN111447219B (zh) 图像显示方法及装置、存储介质、计算机设备
CN112926009A (zh) 图片资源的处理方法、装置、电子设备和介质
CN110442806B (zh) 用于识别图像的方法和装置
CN110012003B (zh) 一种云应用抓屏方法和装置
CN107918643A (zh) 一种网页显示方法及终端
CN112423024A (zh) 一种视频转码方法、装置、计算机设备和存储介质
CN114222185B (zh) 视频播放方法、终端设备及存储介质
CN106933449B (zh) 图标处理方法和装置
CN115643468A (zh) 海报生成方法、装置、电子设备及存储介质
WO2014024255A1 (ja) 端末および動画再生プログラム
JP2015179350A (ja) コンテンツ変換装置及び方法、並びに、通信システム
CN113467807A (zh) 游戏更新方法及系统、服务器、电子设备、存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20220525

Address after: 518000 China Aviation Center 2901, No. 1018, Huafu Road, Huahang community, Huaqiang North Street, Futian District, Shenzhen, Guangdong Province

Applicant after: Shenzhen Ping An medical and Health Technology Service Co.,Ltd.

Address before: Room 12G, Area H, 666 Beijing East Road, Huangpu District, Shanghai 200001

Applicant before: PING AN MEDICAL AND HEALTHCARE MANAGEMENT Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant