HELP::IMAGE VIEWER::BASE64 IMAGE::REDRAW LINKED TO APP WINDOW RESIZE

[Element115]

CONTEXT:

PBI Desktop Version: 2.128.952.0 64-bit (April 2024)

2 year old report that has all tables in Import mode is migrated to a new report.  All visuals remain the same. The only difference is that the new report has all tables in DirectQuery with the source being a lakehouse.

Both reports use a table that stores JPEG images base64 encoded and split into chunks, each chunk is one row. I got a DAX measure that reconstitutes the image, works perfectly in the old report.

Because of the issue I will describe below, I changed the connection mode for 3 tables from DirectQuery to Import; the issue remained.  So whether DirectQuery or Import mode, it seems to make no difference. 

ISSUE:

This is a weird one. In the old report, there are no issues.  In the new report, I have a 100% Stacked column chart and a Image Viewer visual that displays the JPEG depending on date selection.  The former filters the latter.

Now:  When I click on one of the bars in the 100% Stacked column chart, nothing happens in the image visual.  Normally, the image should load.  But get this:  As soon as I resize the PBI Desktop window along either x or y axis, the image starts displaying but never in full, it always gets cut off at 25% of its total size, give or take.

This is what it looks like after you click on one column--notice the large white emtpy rectangle at bottom left where the image should appear:

And this is what it looks like after you resize the window a little bit--note only about 25% of the pictures is drawn:

Did anyone else ever encounter this phenomenon? And if so, what was the solution?  Or is it some weird bug in the April 2024 codebase of PBI Desktop (but then why is the old report not affected when opened with the same version of the app?)

[Element115]

And it works fine with a semantic model derived from the LH tables and a report created in the Service using DirectLake.  

However, since there is no feature parity between PBI Desktop and PBI Service, namely field paramaters are still not available in the Service, and the Formatting pane has still not been update either, this holds you back from creating reports in the Service as opposed to PBI Desktop, so not always an option to use DirectLake.

And the biggest problem is when you have a use case that requires complex transformations made with Power Query but you don't persist the output of this DFg2 to the LH because the underlying data is basically the same as the raw data table already stored in the LH, so why duplicate?   But Power Query is required because the shape of the data needs to change because of the particular contrainsts that a Power BI visual puts on it.

So, now you got a final data ouptut in the form of a table from a DFg2, and a semantic model derived from the LH, but there is no way to include this DFg2 into the semantic model as a table, just like you can in PBI Dekstop, for example.  You are back to using PBI Desktop and still no way to display the images.  

[Element115]

And another problem I just discovered, when doing everything in Fabric, so you are working on the semantic model in DirectLake mode, there is no way to add calculated columns to the tables.  Measures you can add. But not calculated cols, and we have a bunch of them for this use case, so again we are back to PBI Desktop and DirectQuery which it doesn't work with base64 encoded image data stored in a lakehouse.  

Some you can do in M, but some which requires model relations, you can ony do in DAX. 

Going round and round in circles here.

[v-yilong-msft]

Hi @Element115 ,

First of all I think you should check if the image viewer visual object you are using is fully compatible with the latest Power BI Desktop version, because in some cases even though Power BI Desktop is updated, some visual objects are still not updated in time, so I think you can use the previous Desktop to see if it can be displayed properly. You can also try to use the new report in the new report.

You can also try to create the Image Viewer visual object in a new report. Sometimes there may be properties or settings that have not been migrated correctly or are not fully compatible with the new data source configuration.

Also I noticed that your issue still exists in both DirectQuery and Import modes, so check the DAX metric used to reconstruct the base64 encoded image.

Best Regards

Yilong Zhou

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[Element115]

@v-nikhilan-msft   @v-yilong-msft  So further tests confirmed that everything works fine both in DirectQuery or Import mode when the source is the on-prem DB.

Can you or someone therefore tell me why it doesn't work fine when the source is the lakehouse in DirectQuery mode?

[Element115]

@v-nikhilan-msft @v-yilong-msft  

What is the maximum number of bytes that can be sent over the wire in DirectQuery mode from a column of type varchar(MAX) before the connection is dropper or stopped?

The original column is of type varbinary(MAX) in the on-prem SQL Server.  It is then converted on-prem to varchar(MAX) using a VIEW. Then it is copied to the lakehouse in a pipeline using Copy data.  

1__Could there be an issue with the Copy date activity?

2__Could there be an issue with the total size of data stored in each column row (varchar(MAX)) when sending the data to a report in DirectQuery mode?

[Element115]

To address your first point: the old report, which uses the Image Viewer visual, runs just fine with the latest PBI Desktop version, so that eliminates version as the issue.

As to your 2nd point, what do you mean by 'the new data source configuration'?  The new data source is a lakehouse table.  I switched from DQ to Import mode with this LH table source.  Issue remains. Are you saying that because the source is a LH, even import mode can be affected?

As to your 3rd point:  the DAX measure to rebuild the image (remember the image is chunked and each chunk is stored as a table row) has not changed one iota.  It works in the original report, therefore it should also work in the new report, the only difference being the data source, ie instead on an on-prem SQL Server DB, now it is a Fabric LH.