Description: Png pictures appears greyed inside LibreOffice Base form Actual Results: The png pictures are greyed. Expected Results: The png pictures should be in full color. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 153174 [details] The form The form
Created attachment 153175 [details] The png file The png file
@britfox42 : does the PNG also have a grey area when inserted into a Writer document, or just when in your database form. Without a sample db with which to test, it might be difficult to reproduce this bug (as it depends potentially on several different possible actions). Please provide a sample DB and detailed steps on how to reproduce. Setting to NEEDINFO
@britfox24 : does it make any difference to the end result if you activate/deactivate openGL support within the LO user profile ?
No repro for me with test DB (hsqldb) that I created myself. Screenshot enclosed. Windows specific ? Version: 6.2.5.2 Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 Threads CPU : 4; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded
Created attachment 153192 [details] Screenshot Form with PNG image in control created on macOS LO6252
For comparison's sake, I also inserted the provided image into a blank Writer document - no grey shading of the coloured box area.
After further tests: - It happens with every types of picture (jpeg too) - They appear greyed only when the "Read-only" parameter in the "General" tab of the "Image Control" form is set to "No".
Created attachment 153195 [details] Here is a zipped sample db.
(In reply to britfox42 from comment #8) > After further tests: > > - It happens with every types of picture (jpeg too) > > - They appear greyed only when the "Read-only" parameter in the "General" > tab of the "Image Control" form is set to "No". By default, that property is set to "No", at least in the test db I created using the wizard to create the form.
@britfox24 : thanks for the sample DB file. However, the problem with the JPG appears to be different to the one you experienced with the PNG ? In the JPG file, I see a grey border around the image in the form. Is their some kind of alpha channel issue involved here ?
Adapted summary to reflect further findings. Confirming.
Note that there have been issues before with rendering images containing transparent layers in certain parts of LO (cf. bug 96532)
For me, it's the exact same problem. They both appear greyed. And the png file is in 24 bits with no alpha channel.
Sorry, should've checked the JPG first, I see that it already has a grey border around each image, so still no repro for me I'm afraid, even with your test file.
This will need to be tested by a QA member with a Windows setup.
OK, I do see the grey representation of the JPG image in your test file, I didn't immediately spot the difference (temporary colour blindness, sorry) in the eye colour. Confirming once again, amending summary etc. I notice that this appears to be particular to using a CSV as your datasource.
For comparison, using a test embedded hsqldb as the datasource, both the PNG and JPG supplied display in colour in the form.
I could reproduce the same buggy behaviour with a Calc sheet used as the datasource and your test JPG image
Hmm, I have a slight suspicion that this might be linked to API changes in the way graphics are loaded from a URL...
If I load your test ODB into LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 I see the colour in the JPG image in the form. ==>> regression
Hmm, seems the problem goes way back before those API changes occurred...
The image was still displaying correctly in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Incorrect display in Version 3.6.3.2 (Build ID: 58f22d5) Bibisect range between 3.5.7.2 and 3.6.3.2 (probably after 3.6 branchoff)
I used bibisect-43all to arrive at the range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=05a0b08606ac77cf7d3e294998138610b53b1b6d..bf12ddb08f60aa261f83e1688c5d589a69eea0dd A very suspicious looking commit is: author Caolán McNamara on 2012-03-05 09:19:04 +0000 commit 159b5088ee303f7adf6a4c0e5e72b32c37f9f910 Resolves: fdo#31306 some icons don't get grayed when disabled some of our menu icons are not RGBA, but our fade-out code only handled images with an alpha channel, so we need to extend it for bitmaps with alpha channel icons https://cgit.freedesktop.org/libreoffice/core/commit/?id=159b5088ee303f7adf6a4c0e5e72b32c37f9f910 However, EVERYTHING about this code has changed in the last 8 years. The code got split out into vcl/source/outdev/ and function names have changed etc. So the code pointers are not very helpful (at least not to me). In my debugging build, I see the colour for a split second, and then it gets painted over with gray.
Some possible additional clues -if you save a copy, export, or make PDF, then the gray-screening is removed after the save has completed. -it is in colour when you "edit" the form (as opposed to opening it).
Perhaps this isn't really a bug after all. If you double-click on the image, you are not prompted to browse for a replacement image. However, after the document is saved/exported, then you can replace the image. Thus the image really is disabled on form open, and thus should have some indication of that. The form locks the image already in LO 3.5 - as far back as I can test. OK - it has already been established that this is a read-only database. Although the form is set to allow additional records etc, none of the controls are active, and no part of the record is editable. So all data-entry parts of the form are disabled, including the image. (In reply to britfox42 from comment #8) > - They appear greyed only when the "Read-only" parameter in the "General" > tab of the "Image Control" form is set to "No". (Nice bit of investigation.) That seems counter-intuitive doesn't it? Yet that makes sense to me. If the picture is marked as read-only, then it has no need of being disabled when the database does not allow editing. So in summary: -this only affects read-only databases or fields - since editing is disabled -it only affects images that are marked as editable - while editing is disabled. It seems more and more clear to me that this is NOTABUG. And there is a logical (if somewhat unintuitive) solution for the database designer. P.S. The bibisect range was in LO 3.6. P.P.S. Perhaps someone could complain that exporting as PDF shouldn't remove the disable-highlighting, but who cares?